From hang.vo at oracle.com Mon Jul 2 06:03:36 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Jul 2012 13:03:36 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-22747, RT-22749: marked additional SB dependencies. Message-ID: <20120702130341.6F2B247C3C@hg.openjdk.java.net> Changeset: 40d9b78ba945 Author: Pavel Safrata Date: 2012-07-02 14:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/40d9b78ba945 RT-22747, RT-22749: marked additional SB dependencies. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.java From hang.vo at oracle.com Mon Jul 2 06:18:20 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Jul 2012 13:18:20 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-21828 Canvas Screen Lock Message-ID: <20120702131825.209D947C3D@hg.openjdk.java.net> Changeset: b27852b420e2 Author: "Joseph Andresen" Date: 2012-07-02 06:08 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b27852b420e2 RT-21828 Canvas Screen Lock ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java From richard.bair at oracle.com Mon Jul 2 07:47:22 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 2 Jul 2012 07:47:22 -0700 Subject: Image loading error reporting / handling In-Reply-To: <4FEB2BDF.50009@oracle.com> References: <4FE9D2B0.90609@oracle.com> <4FE9F207.6050006@geomatys.fr> <411E73D23DEC4C46BA48F2B6D8BF3D2215FCA51236@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <4FEB2BDF.50009@oracle.com> Message-ID: <2D915C8A-7F4A-49FC-94E0-A46E5D1F63E7@oracle.com> I was also wondering if we shouldn't reuse the Worker API for this. However I have another question as well, which is how does ImageLoader work in a declarative environment, such as FXML? It seems like having Image have a getLoadWorker() would be better in that it would (a) be consistent with web engine, (b) present a consistent API with the other places where we do background monitoring / loading work and (c) could be used declaratively. Which is not to say that having an ImageLoader wouldn't be nice (especially if it means we can make what is now a private implementation public rather than adding a new class), but I don't think it is sufficient since it would require procedural programming. Richard On Jun 27, 2012, at 8:50 AM, Lubomir Nerad wrote: > Hi John, > > good question, but I don't think it will be useful in this case. Worker interface is more suitable to track loading of a single Image and most of the information available through that interface is already provided by the Image class. Or we can try to define ImageLoader as a javafx.concurrent.Service, but in that case we would inherit some unwanted methods and loose the possibility to attach some additional information to the reported events. > > Thanks, > Lubo > > On 6/27/2012 2:19 AM, John Smith wrote: >> Could (or should) a Worker interface be used as the API to monitor and control Image loading - similar to how webEngine.getLoadWorker() can be used to monitor and control web page loading? >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Martin Desruisseaux >> Sent: Tuesday, June 26, 2012 10:32 AM >> To: openjfx-dev at openjdk.java.net >> Subject: Re: Image loading error reporting / handling >> >> One advantage that I see with the proposed ImageLoader class would be >> its similarity with javax.imageio.ImageWriter, which may make easier to >> write adapters for interoperability between the two frameworks. >> >> Martin >> >> >> Le 26/06/12 17:18, Lubomir Nerad a ?crit : >>> Hi all, >>> >>> I have two feature requests which ask for better error reporting / >>> handling of image loading. >>> >>> The issues are: >>> >>> Make Image class support exceptions for both asynchronous and >>> synchronous loading >>> (http://javafx-jira.kenai.com/browse/RT-17645) >>> Image/Media need consistent error reporting >>> (http://javafx-jira.kenai.com/browse/RT-976) >>> >>> Currently my idea of fixing them is through a new ImageLoader class. >>> >>> This class will have two sets of instance methods for image loading: >>> >>> Image load(...) - Used for foreground image loading. The difference >>> between them and the Image constructors would be that by default (!) >>> they will throw an exception if image loading fails [RT-17645] >>> (instead of returning an Image with error set to true). >>> >>> Image loadAsync(...) - Used for background image loading. Will throw >>> only when input arguments are null or invalid. >>> >>> Then there will be methods for registering image loading event >>> handlers [RT-976]. I can think of the following basic set of events: >>> >>> loading started (setOnLoadingStarted) >>> loading progress (setOnLoadingProgress) >>> loading finished >>> loading succeeded (setOnLoadingSucceeded) >>> loading failed (setOnLoadingFailed) >>> >>> They will use a new ImageLoadingEvent and possibly >>> ImageLoadingFailedEvent (with an added exception field). The >>> ImageLoadingEvent will report the image for which the event has been >>> generated (null for foreground images?). >>> >>> Image loading errors will be reported as runtime (!) >>> ImageLoadingException-s. >>> >>> ImageLoader instances will be created through constructor(s) with >>> possibility to pass some configuration parameters (for example the >>> maximum number of images being loaded at the same time). >>> >>> For "logging only" image loaders we might want to allow to configure >>> (constructor parameter? loadingFailedEvent.consume()?) whether the >>> load methods will throw ImageLoadingException or merely create Images >>> with error flags set (as is the case of Image constructors). >>> >>> This is just a basic outline of my proposal. We can focus on details >>> when/if this approach is accepted. Alternatively the issues could be >>> fixed by additional properties / methods on Image class. I didn't like >>> it, because the added properties would be useful only during short >>> period of the whole image lifetime and absolutely unusable for some >>> images (images created from scratch). I also think that the >>> ImageLoader approach makes uniform error handling of image loading >>> easier (one handler for several images instead of one handler per image). >>> >>> What is your preference / opinion about this? >>> >>> Thanks, >>> Lubo >>> >> From richard.bair at oracle.com Mon Jul 2 07:52:52 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 2 Jul 2012 07:52:52 -0700 Subject: JavaFX Form Validation In-Reply-To: References: Message-ID: <5F4E6150-645B-471E-ABE6-050B9F794CA1@oracle.com> Gunnar, Thanks for the information I will be catching up on this. I am in complete agreement, to the greatest extent possible JavaFX should leverage the technology that already is used throughout the Java world such that it is part of a cohesive story rather than a silo'd technology. Reusing Bean Validation seems like a logical thing to pursue. Thanks Richard On Jun 27, 2012, at 1:59 PM, Gunnar Morling wrote: > Hi all, > > first off, sorry for arriving that late to the party, I just stumbled > upon this thread by a post in the Bean Validation feedback forum [1]. > > I'm member of the JSR 349 (BV 1.1) expert group and also committing to > the BV reference implementation, Hibernate Validator. Therefore I'm > very interested in the topic of integrating JavaFX with BV and just > wanted to add some thoughts from my side :) > > Reading through this thread, I saw the question whether BV might be > somehow dead or inactive. Please rest assured that this is absolutely > not the case. BV 1.0 is part of JEE 6 and as such is widely used in > enterprise applications. Currently we're working on BV 1.1 which is > intended to be part of JEE 7. See [2] for the roadmap. One general > theme is the integration with other specs (CDI, JAX-RS etc.), and I > feel Bean Validation would also be very valuable to be used together > with JavaFX. > > As someone already pointed out, BV is explicitly not targeting a > single application layer but is intended to be used in all places > where validation is required (persistence, service, frontend layer > etc.). It is also not restricted to the server side or Java EE, it > runs perfectly on the client and Java SE (and in fact is used in GUI > technologies such as JSF or GWT etc). So personally, I'd be a strong > proponent for making use of BV for validation purposes in JavaFX. IMO > using the same validation facility throughout all application layers > makes developer life easier, avoids redundancies and inconsistencies > etc. > > That said, I've actually played around a bit with integrating JavaFX > and BV a while ago, the result can be found at [3] (have a look at the > readme and the contained example application [4]). Back then, I didn't > pursue the idea any further, but the project shows that BV can easily > be used for validation with JavaFX. > > In case there are any questions around Bean Validation, please don't > hesitate to contact the BV EG [5]. The Hibernate Validator reference > guide [6] can serve as good introduction to the API and its > possibilities. Also let us know if there are certain things missing, > which would be beneficial for the JavaFX use case. I'll also point the > BV EG and its spec lead, Emmanuel Bernard, to this thread. > > With best regards, > > --Gunnar > > [1] https://forum.hibernate.org/viewtopic.php?f=26&t=1015972 > [2] http://beanvalidation.org/roadmap/ > [3] https://github.com/gunnarmorling/jx-binding > [4] https://github.com/gunnarmorling/jx-binding/blob/master/src/test/java/de/gmorling/jxbinding/example/JxBindingExample.java > [5] https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > [6] http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/ From richard.bair at oracle.com Mon Jul 2 08:52:07 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 2 Jul 2012 08:52:07 -0700 Subject: JavaFX Form Validation In-Reply-To: References: Message-ID: <6B367C52-080F-47D0-9BE8-01093E642A0E@oracle.com> Gunnar, Thanks for the information I will be catching up on this. I am in complete agreement, to the greatest extent possible JavaFX should leverage the technology that already is used throughout the Java world such that it is part of a cohesive story rather than a silo'd technology. Reusing Bean Validation seems like a logical thing to pursue. Thanks Richard On Jun 27, 2012, at 1:59 PM, Gunnar Morling wrote: > Hi all, > > first off, sorry for arriving that late to the party, I just stumbled > upon this thread by a post in the Bean Validation feedback forum [1]. > > I'm member of the JSR 349 (BV 1.1) expert group and also committing to > the BV reference implementation, Hibernate Validator. Therefore I'm > very interested in the topic of integrating JavaFX with BV and just > wanted to add some thoughts from my side :) > > Reading through this thread, I saw the question whether BV might be > somehow dead or inactive. Please rest assured that this is absolutely > not the case. BV 1.0 is part of JEE 6 and as such is widely used in > enterprise applications. Currently we're working on BV 1.1 which is > intended to be part of JEE 7. See [2] for the roadmap. One general > theme is the integration with other specs (CDI, JAX-RS etc.), and I > feel Bean Validation would also be very valuable to be used together > with JavaFX. > > As someone already pointed out, BV is explicitly not targeting a > single application layer but is intended to be used in all places > where validation is required (persistence, service, frontend layer > etc.). It is also not restricted to the server side or Java EE, it > runs perfectly on the client and Java SE (and in fact is used in GUI > technologies such as JSF or GWT etc). So personally, I'd be a strong > proponent for making use of BV for validation purposes in JavaFX. IMO > using the same validation facility throughout all application layers > makes developer life easier, avoids redundancies and inconsistencies > etc. > > That said, I've actually played around a bit with integrating JavaFX > and BV a while ago, the result can be found at [3] (have a look at the > readme and the contained example application [4]). Back then, I didn't > pursue the idea any further, but the project shows that BV can easily > be used for validation with JavaFX. > > In case there are any questions around Bean Validation, please don't > hesitate to contact the BV EG [5]. The Hibernate Validator reference > guide [6] can serve as good introduction to the API and its > possibilities. Also let us know if there are certain things missing, > which would be beneficial for the JavaFX use case. I'll also point the > BV EG and its spec lead, Emmanuel Bernard, to this thread. > > With best regards, > > --Gunnar > > [1] https://forum.hibernate.org/viewtopic.php?f=26&t=1015972 > [2] http://beanvalidation.org/roadmap/ > [3] https://github.com/gunnarmorling/jx-binding > [4] https://github.com/gunnarmorling/jx-binding/blob/master/src/test/java/de/gmorling/jxbinding/example/JxBindingExample.java > [5] https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > [6] http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/ From hang.vo at oracle.com Mon Jul 2 11:34:02 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Jul 2012 18:34:02 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120702183405.934CE47C42@hg.openjdk.java.net> Changeset: 121a87ea1d97 Author: David Grieve Date: 2012-07-02 14:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/121a87ea1d97 RT-22076: backout patch for RT-22076 until after integration ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: 80668368c867 Author: David Grieve Date: 2012-07-02 14:16 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/80668368c867 RT-23140: NPE in getStyleHelper if stylesheet fails to load. Check if stylesheet is null and also check if stylesheet List is null or empty. If so, move on to next stylesheet. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StylesheetTest.java From hang.vo at oracle.com Mon Jul 2 12:18:12 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Jul 2012 19:18:12 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120702191814.2448C47C43@hg.openjdk.java.net> Changeset: 3e1c680c584d Author: Kinsley Wong Date: 2012-07-02 12:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/3e1c680c584d [DOC-ONLY] Pagination control has no entry in cssref.html doc. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: 5b9ab0325414 Author: Kinsley Wong Date: 2012-07-02 12:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/5b9ab0325414 [DOC ONLY] RT-21293: Typos in the API docs. ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java From hang.vo at oracle.com Mon Jul 2 13:18:23 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Jul 2012 20:18:23 +0000 Subject: hg: openjfx/2.2/controls/rt: 6 new changesets Message-ID: <20120702201828.D4B3847C4E@hg.openjdk.java.net> Changeset: 605a2c2253e5 Author: "Joseph Andresen" Date: 2012-06-19 12:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/605a2c2253e5 RT-22434: Canvas Defaults should be same as FX ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: cce23876f3c4 Author: flar Date: 2012-06-19 23:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/cce23876f3c4 Fix RT-19711 Color.web() should allow floating point values for percents and angles. ! javafx-ui-common/src/javafx/scene/paint/Color.java ! javafx-ui-common/test/unit/javafx/scene/paint/ColorTest.java Changeset: ab81c2cf3cca Author: flar Date: 2012-06-23 19:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ab81c2cf3cca Fix RT-22885: PixelFormat.get/setArgb() methods have errors. ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java + javafx-ui-common/test/unit/javafx/scene/image/PixelFormatTest.java Changeset: 8dc3a4c1f7fb Author: Yao Wang Date: 2012-06-26 10:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8dc3a4c1f7fb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt Changeset: 5f3d913cf4e3 Author: hudson Date: 2012-06-27 14:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/5f3d913cf4e3 Added tag 2.2-b15 for changeset 8dc3a4c1f7fb ! .hgtags Changeset: dffc6988a9ab Author: Kinsley Wong Date: 2012-07-02 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/dffc6988a9ab Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt From hang.vo at oracle.com Tue Jul 3 10:18:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Jul 2012 17:18:37 +0000 Subject: hg: openjfx/2.2/graphics/rt: 24 new changesets Message-ID: <20120703171858.6929047C6E@hg.openjdk.java.net> Changeset: 9a2b4524a317 Author: David Grieve Date: 2012-06-26 12:20 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9a2b4524a317 RT-22565: parent stylesheets may be in the default stylesheet container ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 385a5b779565 Author: David Grieve Date: 2012-06-27 18:52 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/385a5b779565 Backed out changeset 9a2b4524a317 ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: d20976d5d10f Author: Paru Somashekar Date: 2012-06-28 10:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d20976d5d10f [TEST ONLY] remove @ignore for some chart tests - they pass now. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java Changeset: 9ed69f9a93bb Author: jgiles Date: 2012-06-27 16:03 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9ed69f9a93bb [DOC ONLY] Update to cells package documentation. ! javafx-ui-controls/src/javafx/scene/control/cell/package.html Changeset: a42d594cef37 Author: jgiles Date: 2012-06-29 09:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a42d594cef37 RT-22676: Embedded: Ensemble sample throws an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 4484722efef7 Author: jgiles Date: 2012-06-29 09:39 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4484722efef7 RT-2295: Non-editable ComboBox does not show prompt text when it should ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 0d6d4249cce9 Author: jgiles Date: 2012-06-29 09:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0d6d4249cce9 RT-22908: Column width of data rows does not align with header column width ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: d17e7e409769 Author: jgiles Date: 2012-06-29 09:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d17e7e409769 RT-22875: CheckBoxTreeItem: indeterminate state does not affect rendering ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java Changeset: 480b6f9324a7 Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/480b6f9324a7 RT-22954: PieChart with rollover has picking issues ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: a81a3544722e Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a81a3544722e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 29a0e209d81f Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/29a0e209d81f RT-22937: Selection issue on editors based on ComboBox with dynamic item list ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: 2d7d2be9cdb7 Author: Kinsley Wong Date: 2012-06-28 14:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2d7d2be9cdb7 RT-22928: ClassCastException in TilePane while using the CSS style -fx-pref-columns ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java Changeset: feb33f9ce89b Author: Kinsley Wong Date: 2012-06-28 14:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/feb33f9ce89b RT-22925: When closing a Tab inside a TabPane, the selection model does not return the correct Tab. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: f90f6b0e27a4 Author: jgiles Date: 2012-06-29 09:47 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f90f6b0e27a4 RT-22076: CSS: Treat style class as a bit mask in Selector for better performance on selector matching. ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 90b96294241a Author: jgiles Date: 2012-06-29 09:49 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/90b96294241a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 68f2523b8433 Author: David Grieve Date: 2012-06-28 18:21 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/68f2523b8433 RT-22076: backout patch pushed by jgiles in favor of updated patch ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 29a95b63c732 Author: David Grieve Date: 2012-06-28 18:21 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/29a95b63c732 RT-22076: create a bitmask from style class strings to speed up SimpleSelector.isSubsetOf method. ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: ad5af91935ff Author: David Grieve Date: 2012-06-29 13:18 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ad5af91935ff RT-22565: parent stylesheets may be in the default stylesheet container ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 121a87ea1d97 Author: David Grieve Date: 2012-07-02 14:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/121a87ea1d97 RT-22076: backout patch for RT-22076 until after integration ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: 80668368c867 Author: David Grieve Date: 2012-07-02 14:16 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/80668368c867 RT-23140: NPE in getStyleHelper if stylesheet fails to load. Check if stylesheet is null and also check if stylesheet List is null or empty. If so, move on to next stylesheet. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StylesheetTest.java Changeset: 3e1c680c584d Author: Kinsley Wong Date: 2012-07-02 12:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3e1c680c584d [DOC-ONLY] Pagination control has no entry in cssref.html doc. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: 5b9ab0325414 Author: Kinsley Wong Date: 2012-07-02 12:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/5b9ab0325414 [DOC ONLY] RT-21293: Typos in the API docs. ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java Changeset: dffc6988a9ab Author: Kinsley Wong Date: 2012-07-02 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/dffc6988a9ab Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: 6b0866a7c08c Author: Yao Wang Date: 2012-07-03 10:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6b0866a7c08c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt From hang.vo at oracle.com Tue Jul 3 11:48:50 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Jul 2012 18:48:50 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22559: address isUserSetProperty and getAllPseudoClassStates causing bottleneck in StyleHelper.transitionToState Message-ID: <20120703184854.EC90E47C6F@hg.openjdk.java.net> Changeset: 9bcfd0822e48 Author: David Grieve Date: 2012-07-03 14:35 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9bcfd0822e48 RT-22559: address isUserSetProperty and getAllPseudoClassStates causing bottleneck in StyleHelper.transitionToState ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.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/Scene.java From hang.vo at oracle.com Tue Jul 3 12:48:13 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Jul 2012 19:48:13 +0000 Subject: hg: openjfx/2.2/controls/rt: 5 new changesets Message-ID: <20120703194817.E1E8647C74@hg.openjdk.java.net> Changeset: c74fc98bb9d4 Author: jgiles Date: 2012-07-03 12:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c74fc98bb9d4 RT-23008: TextFieldListCell throws NPE on Enter ! javafx-ui-controls/src/javafx/scene/control/cell/CellUtils.java Changeset: 587765f2009d Author: jgiles Date: 2012-07-03 12:22 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/587765f2009d [DOC ONLY] RT-23154: TextField Cells Javadoc doesn't specify clearly that StringConverter has to be set for them to work ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: e26d0e3bfcb3 Author: jgiles Date: 2012-07-03 15:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/e26d0e3bfcb3 [DOC ONLY] RT-22874: CheckBoxTreeItem: javadoc is incomplete ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java Changeset: ea0e80ad3933 Author: jgiles Date: 2012-07-04 07:36 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ea0e80ad3933 [DOC ONLY] Fixes for a number of JavaDoc errors and warnings. ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/MapValueFactory.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: b06e3fb7dd1a Author: jgiles Date: 2012-07-04 07:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b06e3fb7dd1a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From hang.vo at oracle.com Tue Jul 3 13:18:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Jul 2012 20:18:27 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22929 [Not bug court approved pushing so qa and can run tests] SplitPane: issue with position setting Message-ID: <20120703201828.912E947C75@hg.openjdk.java.net> Changeset: 53c9087d14fb Author: Kinsley Wong Date: 2012-07-03 13:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/53c9087d14fb RT-22929 [Not bug court approved pushing so qa and can run tests] SplitPane: issue with position setting ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java From hang.vo at oracle.com Tue Jul 3 17:32:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Jul 2012 00:32:39 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22076: reinsert patch Message-ID: <20120704003240.E1C8047C80@hg.openjdk.java.net> Changeset: 279dc6b31ebd Author: David Grieve Date: 2012-07-03 20:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/279dc6b31ebd RT-22076: reinsert patch ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java From pedro.duquevieira at gmail.com Tue Jul 3 18:05:32 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 4 Jul 2012 02:05:32 +0100 Subject: MouseEvent dragX and dragY Message-ID: Hi, I just remembered to ask why where dragX and dragY properties removed from MouseEvent. I believe they stopped existing when the migration javafx 1.3 -> javafx 2 occurred. They where good additions that helped remove some boiler plate code. Thanks, best regards, -- Pedro Duque Vieira From pavel.safrata at oracle.com Wed Jul 4 04:47:52 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 04 Jul 2012 13:47:52 +0200 Subject: MouseEvent dragX and dragY In-Reply-To: References: Message-ID: <4FF42D68.4020404@oracle.com> Hello, it was removed based on a request from our architects: The dragX, dragY, dragAnchorX, and dragAnchorY were added to MouseEvent way back in the 1.0 days as an attempt to do some of the book keeping necessary for handling simple "dragging the node around" type of support. But as it turns out, none of these four properties are actually useful for that use case. The simplest code is to not use them, just record the location at which the press occurred prior to the drag as well as the origin of the node being dragged, and then place the node at the new location during the drag event. We could add something back in later to make this use case easier, but for now, it is better to omit API. If I remember correctly there was one more reason for the removal - to report the values in transformed node's coordinates, the logic was really complex and used values stored to all nodes which was pretty ugly and non-effective, so this feature would need a complete rewrite anyway. There is already an open issue that requests to reintroduce the fields - I'm considering your email as a vote in favor of this issue: http://javafx-jira.kenai.com/browse/RT-16292 With regards, Pavel On 4.7.2012 3:05, Pedro Duque Vieira wrote: > Hi, > > I just remembered to ask why where dragX and dragY properties removed from > MouseEvent. I believe they stopped existing when the migration javafx 1.3 > -> javafx 2 occurred. > > They where good additions that helped remove some boiler plate code. > > Thanks, best regards, > From jmartine_1026 at yahoo.com Wed Jul 4 09:27:37 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 4 Jul 2012 09:27:37 -0700 (PDT) Subject: Deployment: native application bundles In-Reply-To: References: <4FDAE162.6070802@oracle.com> <4FDB8620.9030105@oracle.com> <4FDC228A.9090702@oracle.com> Message-ID: <1341419257.17746.YahooMailNeo@web160901.mail.bf1.yahoo.com> Hello, I installed Inno Setup but I still get the following error..... [Can not find Inno Setup Compiler (iscc.exe).] ?Any idea how this I can fix this? feedback: ?Was able to create the bundled jre with executable and it worked fine. ?Not bad at all. ?I been using Install4j, which is a $2000 application, to do my packaging (still using trial version). ?So if this works it will save me a lot of money. ?:-) ? thanks jose ________________________________ From: Daniel Zwolenski To: Igor Nekrestyanov Cc: "openjfx-dev at openjdk.java.net" Sent: Saturday, June 16, 2012 6:03 AM Subject: Re: Deployment: native application bundles I like the sound of the pluggable 'bundlers', and agree that having a WiX free implementation is very low priority if the customisation of WiX is fairly straight forward. Thanks for the code snippet - very interesting how you load the DLL and hook into it. You can ignore my comment about the executable jar, it's not applicable to the way you are doing things. I imagine native dependencies will work just fine in your approach. It all looks good! If we did want to make this work with the auto-update approach I've prototyped, the main challenge will be that your bundle assumes the local version is the only version (as you'd expect it to). It assumes everything in the app directory should be in the classpath, and the JRE is in the jre directory. My POC however uses an 'app-profile.xml' to explicitly define each JAR on the path and the version of the JRE to use. The reason this app-profile is needed in my POC is that when I download new versions I can't overwrite the current jars and JRE because they are locked by the process doing the download - so for some time at least both the new jars and old jars need to co-exist. My current solution is to append version numbers to everything, so when I download myapp-2.0.jar, the old myapp-1.0.jar is still there, same with jre6 and jre7. Then the app-profile.xml is used to decide which jars and jre are the correct ones to use and the old ones are ignored. Without an app-profile both the old 1.0 and the 2.0 jar would get loaded. The app-profile also doubles up as a record of the locally installed version and is used by the code to determine what needs updating. There would be plenty of other ways to do this (e.g. query the JVM for its version and look at the jar names) but the app-profile does make it pretty simple. All just stuff to look into as we explore the auto-updating functionality. Cheers, Dan On Sat, Jun 16, 2012 at 4:07 PM, Igor Nekrestyanov < igor.nekrestyanov at oracle.com> wrote: >? Hi, > > >? Regarding the MSI installer, using WiX does make it easier but I'm > wondering if there would be some merit in trying to write our own MSI > creator using the Windows Installer SDK. I haven't used it myself yet but I > believe it can be used to create MSI's. This would have the advantage of > not needing extra software installed, and also would allow us to customise > closely to what we need specifically for Java installations (e.g. provide > our own configuration options in whatever syntax or format we want - e.g. > an 'app-profile.xml'). The disadvantage of course is the extra work, but > this may be something I could look at in my POC side of it. Something to > think about anyway. > > Basic approach we are using is to adding support for "bundlers" to the > toolchain. Bundler is something that can produce package out of set of app > resources, JRE, etc. > Bundler may or may not have additional requirements (like run only on > specific platform or require WiX, etc.) > > When developer requests to "bundle" app we produce all bundles we can > generate (by running all applicable bundlers). > > JavaFX 2.2 will provide some set of bundlers embedded into packaging tools. > > This approach allow to add new bundler or rewrite bundler later on if > there will be better solution (e.g. WiX-less MSI bundler or cross platform > deb bundler, etc). > > As for WiX-less bundler specifically i think it might be nice to have but > i do not see it as critical issue right now. > We are generating WiX config files based on templates and can expose any > configuration parameters we need in whatever syntax we want. > Once we understand what is limiting with this approach we can decide on > how we can get something better. > Using existing solution that works well for producing MSI allow us to > focus on JavaFX specific problems and other bundlers. > >? Regarding natives, if you are using an executable JAR I don't think this > will work (i.e. executable JARs don't support native included in them), > unless the developer does the old extract and include on path trick. Better > that the natives just get bundled into the installation directory and not > into the jar, I reckon. It's a bit of a messy area (especially for > auto-updates) so probably worth making sure we're covered in this area > fairly early on. > > I think it do not understand the problem. > In my model i assume that application image is something you can run using > java.exe like >? ? cd app-image/ >? ? java -cp main.jar main.class > (where app image is your dist of build folder). > > When you are running app from your IDE, debugger or command line it knows > how to load native resources. > I expect same copy of app-image to be kept under app/ folder in the > installed image. > > Anyway, let me try to craft an example and we will see. > > > >? Regarding the launching of the process, the way I do it also seems to > give it the process the name of the app the proper name (and not > 'java.exe'), which is a pleasant surprise. Do you use the same sort of code > as follows? > > My windows launcher is fairly simple now. Here is relevant part: > > >? ? ? // Dynamically load the JVM >? ? HMODULE jvmLibHandle = LoadLibrary(jvmPath); >? ? if (jvmLibHandle == NULL) { >? ? ? ? DWORD dwErr = GetLastError(); >? ? ? ? MessageBox(0, _T("Error loading jvm.dll"), jvmPath, MB_ICONERROR | > MB_OK); >? ? ? ? return FALSE; >? ? } > >? ? //convert argument to ASCII string as this is what CreateJVM needs >? ? wcstombs_s(&outlen, jarASCII, (size_t) wcslen(jar) + 1, jar, (size_t) > wcslen(jar) + 1); >? ? strcpy_s(classpath, MAX_PATH*2, "-Djava.class.path="); >? ? strcat_s(classpath, MAX_PATH, jarASCII); > >? ? // Set up the VM init args >? ? jvmArgs.version = JNI_VERSION_1_2; > >? ? //TODO: add support for custom JVM parameters >? ? options[0].optionString = classpath; >? ? jvmArgs.version = 0x00010002; >? ? jvmArgs.options = options; >? ? jvmArgs.nOptions = 1; >? ? jvmArgs.ignoreUnrecognized = TRUE; > >? ? // Create the JVM >? ? // NB: need to use ASCII string as UNICODE is not supported >? ? createProc = (JVM_CREATE) GetProcAddress(jvmLibHandle, > "JNI_CreateJavaVM"); >? ? if (createProc == NULL) { >? ? ? ? MessageBox(0, _T("Failed to locate JNI_CreateJavaVM"), jvmPath, > MB_ICONERROR | MB_OK); >? ? ? ? return FALSE; >? ? } > >? ? if ((*createProc)(&jvm, &env, &jvmArgs) < 0) { >? ? ? ? // Should not happen >? ? ? ? // FIXME: report localized error >? ? ? ? return FALSE; >? ? } > >? ? cls = env->FindClass("com/javafx/main/Main"); >? ? if (cls != NULL) { >? ? ? ? mid = env->GetStaticMethodID(cls, "main", >? ? ? ? ? ? "([Ljava/lang/String;)V"); >? ? ? ? ? if (mid != NULL) { >? ? ? ? ? ? jclass stringClass = env->FindClass("java/lang/String"); >? ? ? ? ? ? jobjectArray args = env->NewObjectArray(0, stringClass, NULL); >? ? ? ? ? ? env->CallStaticVoidMethod(cls, mid, args); >? ? ? ? } else { >? ? ? ? ? ? MessageBox(0, _T("no main method"), _T("Expected to find > com.javafx.main.Main.main()"), MB_ICONERROR | MB_OK); >? ? ? ? } >? ? } else { >? ? ? ? MessageBox(0, _T("no main class"), _T("Expected to find > com.javafx.main.Main"), MB_ICONERROR | MB_OK); >? ? } > >? ? if (env->ExceptionOccurred()) { >? ? ? ? MessageBox(0, _T("Failed due to exception."), _T("Exception thrown > from com.javafx.main.Main.main()"), MB_ICONERROR | MB_OK); >? ? ? ? env->ExceptionDescribe(); >? ? } > > >? -igor > >? I'd be keen to keep what I do in line with what you are doing where > possible. > > > > > On Sat, Jun 16, 2012 at 4:59 AM, Igor Nekrestyanov < > igor.nekrestyanov at oracle.com> wrote: > >>? hi, thanks for all questions. >> >> Please keep them coming (bugs and suggestions are very welcome too!), >> >> >>? The Ensemble MSI install worked for me on Windows 7 no problems. I >> haven't tried building my own app as yet though. >> >>? It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. Installing >> into Program Files is probably more correct on windows. Is this 'appdata' >> the intended final location, or is this just for getting it all running for >> now? >> >>? Original goal was to be able to install without requiring admin >> permissions. >> Both MSI and EXE installers are currently build to do this. >> >> It is possible to customize install location and make it system wide by >> tweaking WiX/Inno Setup template files. >> Clearly we want to expose better APIs for customization but it is not >> clear what are importnat config parameters and how to expose them >> in more or less cross platform way, hence we decided that for 2u2 we will >> provide an easy way to build basic package and do minimal customization >> as well as (very) advanced way for advanced users. >> >> Based on feedback we will figure out how to expand built-in configuration >> APIs for future releases. >> >> I am planning to post more about package customization options and other >> tricks&tips but i am amateur blogger and slow typer, so it will take me few >> days :) >> >> Perhaps we should reconsider and produce EXE to be user level >> installation and MSI to be system level by default. >> I believe it is also possible to pass parameters to msiexec to overwrite >> some of MSI settings (end this is not unusual in the enterprise >> deployments). >> However, i had not tried if it is possible to install this MSI system >> wide (and i am not sure if my MSI expertise is deep enough to craft MSI >> that can do both, >> suggestions are very welcome). >> >> >>? Is the source code available for this at all? >> >>? Sorry, it is part of deploy/packager module that is not open sourced >> yet. >> >>? If not, I'm very interested in how the 'exe' launcher code looks. Is >> this code you've written or part of one of the tools you've made use of? >> I'm particularly interested to see how it starts the app - does it just >> kick off another process on the executable jar via something like 'java >> -jar ensemble.jar' or does it try to run the Java app within it's own 'exe' >> process somehow (I'm assuming the later?). >> >>? yes, launcher will instantiate JVM in the launcher process. >> Check out list of processes when sample app is running. There is no >> java.exe but there is Ensemble.exe >> >> >>? I notice also that the jfx DLLs have been copied straight into the >> 'jre/bin' directory. >> >>? Starting 7u6 JRE/JDK will include JavaFX as part of Java installation. >> So, nothing special here. It is just runtime image. >> >>? Is this how you see all native dependencies playing out, i.e. if my >> application uses other native libraries how do I package them into the >> build and where will they be installed to in the extracted directory? >> >>? No, i do not think application resources will go into runtime. >> Application resources will stay in the "app" folder (native libs too). >> >> The approach here is to "bundle" app without requiring to rewrite it. >> During the development cycle your build output should have copy of >> application you can execute and debug (but it depends on environment, i.e. >> java+javafx runtime). >> Bundle is essentially >>? ? ? copy of this application + java runtime? + launcher >> >> Having said that i had not tried to craft example with native libraries >> myself. Will certainly try to do. >> >> One more question: when we say we have to build on the native platform to >> get the correct deployments, does that include 32bit vs 64bit? I'm guessing >> I could have a 32bit and 64bit JDK installation on the one machine and >> build a version of my app for each, but correct me if I'm wrong on this. >> >>? yes, two installations should do. >> >> Currently ant task will try to use RUNNING version of java as source for >> cobundle. >> If it is not appropriate (e.g. java 6 that is not javafx cobundle) then >> it bundled app will not be created. >> >> In the future we may add option to specify which JDK to use as import for >> bundle creation but for now we are taking shortcuts to avoid exposing too >> much (kind of late in release). >> >>? I assume there's no way for a single JDK installation to produce both 32 >> and 64bit versions? >> >>? No, as currently JDK installations do not include both 32 and 64 bit >> bits. After all we are copying them into bundle. >> >> -igor >> >>? Very, very nice start to this all! >> >>? Cheers, >> Dan >> >> >> On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov < >> igor.nekrestyanov at oracle.com> wrote: >> >>> Hi, >>> >>> One thing we are adding to JavaFX packaging tools in 2.2 is ability to >>> produce native application bundles: >>> >>> https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx >>> >>> We are not seeing this as the only way to deploy JavaFX applications -- >>> webstart, embedded applications >>> and doubleclickable jars are first class citizens (and it would be great >>> to explore other options). >>> But we hope it might be good option for many deployment scenarios. >>> >>> Please give it a try and provide feedback (and report bugs of course), >>> >>> -igor >>> >> >> >> > > From jmartine_1026 at yahoo.com Wed Jul 4 11:52:21 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 4 Jul 2012 11:52:21 -0700 (PDT) Subject: Deployment: native application bundles In-Reply-To: <1341427795.63313.YahooMailNeo@web160906.mail.bf1.yahoo.com> References: <4FDAE162.6070802@oracle.com> <4FDB8620.9030105@oracle.com> <4FDC228A.9090702@oracle.com> <1341419257.17746.YahooMailNeo@web160901.mail.bf1.yahoo.com> <4FF47817.8000803@oracle.com> <1341427795.63313.YahooMailNeo@web160906.mail.bf1.yahoo.com> Message-ID: <1341427941.18817.YahooMailNeo@web160903.mail.bf1.yahoo.com> That worked! ?Thank you for the help. Do you know how we set the icon file? In the template.iss file how are those values passed (THE_ALL_CAP_ONES) to Inno? thanks jose ________________________________ From: Igor Nekrestyanov To: Jose Martinez Cc: Daniel Zwolenski ; "openjfx-dev at openjdk.java.net" Sent: Wednesday, July 4, 2012 1:06 PM Subject: Re: Deployment: native application bundles On 7/4/12 9:27 AM, Jose Martinez wrote: Hello, > > >I installed Inno Setup but I still get the following error..... > > >[Can not find Inno Setup Compiler (iscc.exe).] ?Any idea how this I can fix this? Make sure Inno Setup folder (typically it is "c:\Program Files\Inno Setup 5") is added to your path before you run ant. To verify it is ok simply try to run ?? iscc.exe from command line before you run ant or javafxpackager. Command should be found. Otherwise packager will not be able to find it. -igor > >feedback: ?Was able to create the bundled jre with executable and it worked fine. ?Not bad at all. ?I been using Install4j, which is a $2000 application, to do my packaging (still using trial version). ?So if this works it will save me a lot of money. ?:-) >? >thanks >jose From igor.nekrestyanov at oracle.com Wed Jul 4 14:36:56 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 04 Jul 2012 14:36:56 -0700 Subject: Deployment: native application bundles In-Reply-To: <1341427795.63313.YahooMailNeo@web160906.mail.bf1.yahoo.com> References: <4FDAE162.6070802@oracle.com> <4FDB8620.9030105@oracle.com> <4FDC228A.9090702@oracle.com> <1341419257.17746.YahooMailNeo@web160901.mail.bf1.yahoo.com> <4FF47817.8000803@oracle.com> <1341427795.63313.YahooMailNeo@web160906.mail.bf1.yahoo.com> Message-ID: <4FF4B778.6000300@oracle.com> On 7/4/12 11:49 AM, Jose Martinez wrote: > That worked! Thank you for the help. > > Do you know how we set the icon file? Icon file for the installer? I'll be posting details on configuration options but here are few hints for you to explore. 1) Many of existing options to JavaFX ant tasks make sense for native bundles. See RT-22889 and http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference001.htm Specifically you can add icon as fx:fileset of type icon http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference002.htm#CIAIHFGI Note that this is easy but will also impact other packages as same icon may be used for other things. And if same build.xml is used crossplatform you may need different icon files (.ico on Windows but .icns on Mac) 2) Add verbose="true" to the fx:deploy task. It will print out locations where you can drop resources to override icons and some scripts. You need to be add "." to the classpath when you are loading definitions of ant tasks (if you are using NB and it is not latest 7.2 build then you may need to edit jfx-impl.xml for this). Download latest javafx samples drop and try to build native bundles for Ensemble. It uses this approach to add custom icons, etc. I hope to post more details on configuration options soon but here are few hints for you. > In the template.iss file how are those values passed > (THE_ALL_CAP_ONES) to Inno? You can deeply customize it by providing your own .iss file. See verbose="true" output. -igor > > thanks > jose > ------------------------------------------------------------------------ > ** > > > > > From jmartine_1026 at yahoo.com Wed Jul 4 14:54:39 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 4 Jul 2012 14:54:39 -0700 (PDT) Subject: Deployment: native application bundles In-Reply-To: <4FF4B778.6000300@oracle.com> References: <4FDAE162.6070802@oracle.com> <4FDB8620.9030105@oracle.com> <4FDC228A.9090702@oracle.com> <1341419257.17746.YahooMailNeo@web160901.mail.bf1.yahoo.com> <4FF47817.8000803@oracle.com> <1341427795.63313.YahooMailNeo@web160906.mail.bf1.yahoo.com> <4FF4B778.6000300@oracle.com> Message-ID: <1341438879.91794.YahooMailNeo@web160902.mail.bf1.yahoo.com> Thanks again. ?Will digest all this new info. jose ________________________________ From: Igor Nekrestyanov To: Jose Martinez Cc: Daniel Zwolenski ; "openjfx-dev at openjdk.java.net" Sent: Wednesday, July 4, 2012 5:36 PM Subject: Re: Deployment: native application bundles On 7/4/12 11:49 AM, Jose Martinez wrote: That worked! ?Thank you for the help. > > >Do you know how we set the icon file? > Icon file for the installer? I'll be posting details on configuration options but here are few hints for you to explore. 1) Many of existing options to JavaFX ant tasks make sense for native bundles. ??? See RT-22889 and http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference001.htm ?? ??? Specifically you can add icon as fx:fileset of type icon ??????? http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference002.htm#CIAIHFGI ??? Note that this is easy but will also impact other packages as same icon may be used for other things. ??? And if same build.xml is used crossplatform you may need different icon files (.ico on Windows but .icns on Mac) 2) Add verbose="true" to the fx:deploy task. ??? It will print out locations where you can drop resources to override icons and some scripts. ??? You need to be add "." to the classpath when you are loading definitions of ant tasks ????? (if you are using NB and it is not latest 7.2 build then you may need to edit jfx-impl.xml for this). ?? Download latest javafx samples drop and try to build native bundles for Ensemble. ?? It uses this approach to add custom icons, etc. I hope to post more details on configuration options soon but here are few hints for you. In the template.iss file how are those values passed (THE_ALL_CAP_ONES) to Inno? You can deeply customize it by providing your own .iss file. See verbose="true" output. -igor > >thanks >jose > > >________________________________ > > > > > > > > From pedro.duquevieira at gmail.com Wed Jul 4 15:29:50 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 4 Jul 2012 23:29:50 +0100 Subject: MouseEvent dragX and dragY Message-ID: Hi Pavel, Thanks for the clarifications! I've voted up for the jira issue and put a comment. best regards, -- Pedro Duque Vieira From pedro.duquevieira at gmail.com Wed Jul 4 15:47:04 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 4 Jul 2012 23:47:04 +0100 Subject: Mouse cursors: open hand, closed hand Message-ID: Hi, Just tried the open hand cursor and closed hand cursor with javafx 2.2b14. These two cursor default to pointing hand cursor on windows 7. Is this a bug or is there some reasoning behind it? Thanks, -- Pedro Duque Vieira From anthony.petrov at oracle.com Thu Jul 5 02:09:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 05 Jul 2012 13:09:53 +0400 Subject: Mouse cursors: open hand, closed hand In-Reply-To: References: Message-ID: <4FF559E1.2080003@oracle.com> There's a bug: http://javafx-jira.kenai.com/browse/RT-11561 -- best regards, Anthony On 7/5/2012 2:47 AM, Pedro Duque Vieira wrote: > Hi, > > Just tried the open hand cursor and closed hand cursor with javafx 2.2b14. > These two cursor default to pointing hand cursor on windows 7. > > Is this a bug or is there some reasoning behind it? > > Thanks, From pedro.duquevieira at gmail.com Thu Jul 5 02:38:27 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 5 Jul 2012 10:38:27 +0100 Subject: Mouse cursors: open hand, closed hand In-Reply-To: <4FF559E1.2080003@oracle.com> References: <4FF559E1.2080003@oracle.com> Message-ID: Thanks Anthony! On Thu, Jul 5, 2012 at 10:09 AM, Anthony Petrov wrote: > There's a bug: > > http://javafx-jira.kenai.com/**browse/RT-11561 > > -- > best regards, > Anthony > > > On 7/5/2012 2:47 AM, Pedro Duque Vieira wrote: > >> Hi, >> >> Just tried the open hand cursor and closed hand cursor with javafx 2.2b14. >> These two cursor default to pointing hand cursor on windows 7. >> >> Is this a bug or is there some reasoning behind it? >> >> Thanks, >> > -- Pedro Duque Vieira From pedro.duquevieira at gmail.com Thu Jul 5 02:39:22 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 5 Jul 2012 10:39:22 +0100 Subject: Mouse cursors: open hand, closed hand In-Reply-To: References: <4FF559E1.2080003@oracle.com> Message-ID: Is this only to be fixed on Lombard (javafx 3) ? On Thu, Jul 5, 2012 at 10:38 AM, Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Thanks Anthony! > > > On Thu, Jul 5, 2012 at 10:09 AM, Anthony Petrov > wrote: > >> There's a bug: >> >> http://javafx-jira.kenai.com/**browse/RT-11561 >> >> -- >> best regards, >> Anthony >> >> >> On 7/5/2012 2:47 AM, Pedro Duque Vieira wrote: >> >>> Hi, >>> >>> Just tried the open hand cursor and closed hand cursor with javafx >>> 2.2b14. >>> These two cursor default to pointing hand cursor on windows 7. >>> >>> Is this a bug or is there some reasoning behind it? >>> >>> Thanks, >>> >> > > > -- > Pedro Duque Vieira > -- Pedro Duque Vieira From anthony.petrov at oracle.com Thu Jul 5 05:23:36 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 05 Jul 2012 16:23:36 +0400 Subject: Mouse cursors: open hand, closed hand In-Reply-To: References: <4FF559E1.2080003@oracle.com> Message-ID: <4FF58748.5030309@oracle.com> Yes. -- best regards, Anthony On 07/05/12 13:39, Pedro Duque Vieira wrote: > Is this only to be fixed on Lombard (javafx 3) ? > > On Thu, Jul 5, 2012 at 10:38 AM, Pedro Duque Vieira > > wrote: > > Thanks Anthony! > > > On Thu, Jul 5, 2012 at 10:09 AM, Anthony Petrov > > wrote: > > There's a bug: > > http://javafx-jira.kenai.com/__browse/RT-11561 > > > -- > best regards, > Anthony > > > On 7/5/2012 2:47 AM, Pedro Duque Vieira wrote: > > Hi, > > Just tried the open hand cursor and closed hand cursor with > javafx 2.2b14. > These two cursor default to pointing hand cursor on windows 7. > > Is this a bug or is there some reasoning behind it? > > Thanks, > > > > > -- > Pedro Duque Vieira > > > > > -- > Pedro Duque Vieira From hang.vo at oracle.com Thu Jul 5 13:34:25 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Jul 2012 20:34:25 +0000 Subject: hg: openjfx/2.2/controls/rt: 3 new changesets Message-ID: <20120705203430.7CD3C47D0D@hg.openjdk.java.net> Changeset: 907808cece4e Author: Kinsley Wong Date: 2012-07-05 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/907808cece4e RT-22866 Pagination control does not handle swipe gesture events. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 9d0660e793f6 Author: Kinsley Wong Date: 2012-07-05 11:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9d0660e793f6 RT-23084: Calling "setSelected(true)" on CheckBox fires ActionEvent. ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java Changeset: d48861b45651 Author: Kinsley Wong Date: 2012-07-05 13:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d48861b45651 RT-23063: Nested SplitPand rendering issue. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java From jasper.potts at oracle.com Thu Jul 5 15:17:36 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Thu, 5 Jul 2012 15:17:36 -0700 Subject: Region PickOnBounds default setting In-Reply-To: <4FEC0F2A.6060406@oracle.com> References: <4FE185F4.9020407@oracle.com> <4FE2DEF5.8080209@oracle.com> <4FE307EB.6020202@xs4all.nl> <4FEC0F2A.6060406@oracle.com> Message-ID: <2D9D89F2-2BEF-4979-ABEE-28D2ECCBFC11@oracle.com> Pavel, We recently found that bug in PieChart and have set PickOnBounds to false for all Pie slices. Jasper On Jun 28, 2012, at 1:00 AM, Pavel Safrata wrote: > I'm sorry for the delay. I commented on the issue and attached the EvilPane there. I also described another problem I just noticed: > > Another example is picking slices in a pie chart. Right now it by default picks completely wrong slices because each slice is a region and is picked on bounds that cover large portions of neighboring slices. You have to do a "data.getNode().setPickOnBounds(false);" exercise for each slice to make it behave reasonably. > > Thanks, > Pavel > > On 21.6.2012 17:37, Richard Bair wrote: >> Ah I see the problem. Pavel can we make sure there is some text in the issue describing the problem (ie bounds != region width/height, and thus pick on bounds is undeniably wrong in that case). >> >> Dan -- the bounds always must include the bounds of all stuff, without putting a clip on every region you have to be prepared for layout bounds != bounds in parent / bounds in local. >> >> Note that putting a clip on regions by default would be a huge mistake. You wouldn't be able to do a number of common effects where you are translating children outside the bounds of the container. It is the difference between basic form like apps and more graphical ones. >> >> On Jun 21, 2012, at 4:48 AM, Daniel Zwolenski wrote: >> >>> I just ran the code (thanks Pavel!) and I agree. While I see the problem >>> with the picking, a bigger problem in my mind is that the max bounds are >>> not being honoured. The picking to me is just a side effect of some odd >>> layout sizing behaviour. >>> >>> My expectation with this code is it should either honour the max bounds and >>> clip the child nodes (my preference) or, if it's really not going to honour >>> the max bounds, then it should stretch the region to the bounds that it is >>> actually covering. The hybrid thing it is doing is just weird in my >>> opinion. >>> >>> >>> On Thu, Jun 21, 2012 at 9:39 PM, John Hendrikx wrote: >>> >>>> Not sure if interested, but coming from someone who has never seen this >>>> before... I must say it certainly looks counter-intuitive. Why does the >>>> evilPane have such big bounds? It is restricted in layout to a max size of >>>> (50,50)... and thus I would expect the blue child to be clipped and the >>>> pane Bounds to be reduced to no more than (50,50). >>>> >>>> But I guess that is because of the tree style rendering that JavaFX does, >>>> where nodes can exceed their layout bounds when effects/translations are >>>> applied... as I said, it certainly looks counter-intuitive, in more ways >>>> than one coming from someone who is used to Container/Groups strictly sized >>>> to fit their children, and clipping the children that will not fit. >>>> >>>> --John >>>> >>>> >>>> On 21/06/2012 10:44, Pavel Safrata wrote: >>>> >>>>> Hi Daniel, >>>>> >>>>> On 20.6.2012 21:55, Daniel Zwolenski wrote: >>>>> >>>>>> Assuming I understand the problem then I've hit this sort of layout >>>>>>>> problem and my instinct was to look >>>>>>>> I'm not sure I agree with the bug description when it says that "both >>>>>>>> visually and in source code there is nothing in between the pane and the >>>>>>>> child". In code there is a pane. Visually there would be a pane if you set >>>>>>>> styles on it. >>>>>>>> >>>>>>> The pane from the description is small and is in a top-left corner. It >>>>>>> can be styled, and you can see it there. There is no code that would make >>>>>>> the pane big to cover the whole scene, there is no way to make it visible >>>>>>> in the whole area, because it's just not there. >>>>>>> >>>>>> I am perhaps missing something, but "Pane's bounds will then cover whole >>>>>> sceen" implies to me the pane is stretched, so if I styled it I would see >>>>>> it stretched. The description of #2 is a bit vague to me though. I guess a >>>>>> code example would clear this up but it probably doesn't matter that I dont >>>>>> understand. >>>>>> >>>>> The pane is not necessarily stretched to embrace all its children. I've >>>>> attached a code example that shows the problem. >>>>> >>>>> >>>>>> I'm guessing, for example, if this fix went in it would break all my >>>>>>>> 'glasspanes'? >>>>>>>> >>>>>>> I cannot say unless I know how your glasspanes are implemented... >>>>>>> >>>>>> I use glass panes to block the screen in two cases: when loading and >>>>>> behind a light box (ie embedded dialog). >>>>>> >>>>>> In both cases my glass pane is just a pane (eg BorderPane) added to the >>>>>> top of a StackPane with the rest of the app added to a lower layer of the >>>>>> stack. In the loading case it has no children, in the dialog case it's >>>>>> child is the dialog. >>>>>> >>>>>> The loading one is transparent but has an in-progress cursor when you >>>>>> mouse over. In the dialog case, the pane is a translucent grey, though you >>>>>> could style it differently and transparent would be a valid style (making >>>>>> the fill color define if it is clickable would not be nice for me and is a >>>>>> little scary). >>>>>> >>>>>> In both cases the point of it is that it blocks mouse input to the >>>>>> scene. I'd prefer this didn't break in a future release (sorry!). If auto >>>>>> updating (my nemesis) wasn't on then I'd be ok for it to change and then I >>>>>> fix my apps before moving to a higher version but it magically working one >>>>>> day and not the next would be pretty nasty for me. >>>>>> >>>>> It would break your glass panes only if they have no fill (which I agree >>>>> is bad enough). Pane with transparent fill would still block mouse events. >>>>> I'm not sure why this is scary, this approach is used everywhere in FX >>>>> except of Region. >>>>> >>>>> >>>>>> As such, I don't think it needs to be a default attribute now that it's >>>>>>>> in place the other way round but I do think it needs to be clear and >>>>>>>> intuitive how to deal with it. >>>>>>>> >>>>>>> I'm really sad that we've let this go that far, it could have been >>>>>>> fixed before our first release. If the decision comes that it's too late by >>>>>>> now, the way how to deal with it will be clear (setPickOnBounds(false)), >>>>>>> but I doubt it is (and could be) intuitive. >>>>>>> >>>>>> For me the current default behavior seems intuitive: the pane is >>>>>> clickable for whatever area it takes up. I get the feeling I might be >>>>>> missing something here though as it is obviously a concern for some people. >>>>>> Sorry if I have misunderstood. >>>>>> >>>>> I think the attached example shows pane that is clickable in area that it >>>>> doesn't take up. >>>>> >>>>> >>>>>> For me the only problem with the current approach is that in some cases >>>>>> I'd like a pane used purely for layout (anchor pane as top layer of a >>>>>> StackPane is a prime candidate) to not catch mouse clicks but the children >>>>>> on it still should. Calling setPickOnBounds(false) and setShape(null) to do >>>>>> this is not intuitive to me but I'm glad I now know its possible as I've >>>>>> struggled with this before (and possibly raised a bug, will have to check). >>>>>> >>>>> This is exactly the most common problem that would be solved. You see >>>>> you're glad that you now know how to solve it, but other users will keep >>>>> bumping into this issue.. >>>>> >>>>> Thanks, >>>>> Pavel >>>>> >>>>> >>>>>> Thanks, >>>>>>> Pavel >>>>>>> >>>>>>> >>>>>>>> On 20/06/2012, at 5:41 AM, Richard Bair >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi folks, >>>>>>>>> We have an issue which has been in the platform from before 2.0: >>>>>>>>> http://javafx-jira.kenai.com/**browse/RT-17024. >>>>>>>>> A better explanation of the issue can be found on >>>>>>>>> http://javafx-jira.kenai.com/**browse/RT-12258. >>>>>>>>> From 12258: >>>>>>>>> >>>>>>>>> Region behaves counter-intuitively regarding mouse event delivering. >>>>>>>>>> It reacts on mouse events everywhere in its bounds and people are often >>>>>>>>>> confused by it. Here are two simple examples: >>>>>>>>>> >>>>>>>>>> 1) You create let's say HBox just because you want it to layout its >>>>>>>>>> children. The HBox catches all mouse events in the whole area given by its >>>>>>>>>> bounds. Often it's hard to understand what area it is (with children of >>>>>>>>>> different size or with some other layout stretches taking place). >>>>>>>>>> >>>>>>>>>> 2) You create a small Pane in top-left corner of the scene with a >>>>>>>>>> child in bottom-right corner of the scene. Pane's bounds will then cover >>>>>>>>>> whole sceen and you won't be able to click on anything else than the pane >>>>>>>>>> and its child. Users don't understand why, because both visually and in >>>>>>>>>> source code there is nothing in between the pane and the child. >>>>>>>>>> >>>>>>>>>> Moreover, region may have a shape associated and the behavior here >>>>>>>>>> is also strange. If you create a region with a shape inside its bounds, >>>>>>>>>> it's just ignored. You can also create a shape somewhere else, then it >>>>>>>>>> extends region's bounds and it reacts on mouse click everywhere between the >>>>>>>>>> shape and the region. >>>>>>>>>> >>>>>>>>> This issue has to do with the semantics of picking on a Region. For >>>>>>>>> Region we have had pickOnBounds set to true by default, which yields the >>>>>>>>> above behaviors. We can change it to false by default, but then need to >>>>>>>>> update a bunch of skins (for example the up/down arrows of scroll bar, the >>>>>>>>> thumb of a slider, the down arrow of a combo box button, etc) so that they >>>>>>>>> switch back to having pickOnBounds set to true by default so that the >>>>>>>>> target area for clicks is larger. We could just change the default for Pane >>>>>>>>> and not for Region, although we use StackPane in Skins and would have to >>>>>>>>> update them anyhow. It seems that for a normal layout container the >>>>>>>>> behavior really should be pickOnBounds=false by default, but for UI >>>>>>>>> controls usages and such you generally want it true. >>>>>>>>> >>>>>>>>> I'm not certain making this change is worth being backwards >>>>>>>>> incompatible (semantically, binary compatibility would remain). But what do >>>>>>>>> you think? >>>>>>>>> >>>>>>>>> Richard >>>>>>>>> > > From pedro.duquevieira at gmail.com Fri Jul 6 02:52:40 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 6 Jul 2012 10:52:40 +0100 Subject: Differences between "standard" css Message-ID: Hi, I think javafx would benefit if its CSS would support the same keywords and syntax of the "standard" HTML CSS. However the current reality is that javafx css differs from the HTML css in various minor ways. It would be really nice if we could simply grab a css from the web and put it in javafx and it would simply just work. There is a lot of already built up knowledge on this area throughout the web and it would be great if we could leverage that knowledge, also designers coming from other backgrounds could easily and rapidly adapt to javafx. Richard had already mentioned this on his article: " JavaFX: The 10,000 Foot View", adding it would also be good if javafx could supported the box model from HTML for layout. I don?t think we have to make an exact copy of the HTML CSS but I think we could try to support it the best way possible. Here are some of the ways that javafx differs from standard css (not a comprehensive list, just a list of the ones that come to my mind): 1- Use of -fx- prefix everywhere. This was made so that javafx css would not interfere with standard css written on the same file. However I don't see this scenario coming up that often, and you can use different identifiers or css files if you happen to use the two models on the same app. 2- Effects Drop shadow and inner shadow syntax differs from HTML syntax 3- Lack of support for "margin" 4- The ":first-child", ":first-line", ":first-letter" is not supported 5-The ":active" and ":focus" dynamic pseudo-classes are not supported, Their name in javafx is ":pressed" and ":focused" 6- ":link" is not supported 7- JavaFX CSS does not support comma-separated series of font family names in the -fx-font-family property 8- Not sure but I think the ordering on some css properties is different And some more debatable ways that could make no sense to support: 9- The optional line height parameter when specifying fonts is not supported 10- No support for p, div, h1, h2, a... Thanks, best regards, -- Pedro Duque Vieira From david.grieve at oracle.com Fri Jul 6 05:59:30 2012 From: david.grieve at oracle.com (David Grieve) Date: Fri, 6 Jul 2012 08:59:30 -0400 Subject: Differences between "standard" css In-Reply-To: References: Message-ID: <644C46B1-636A-48A1-AF7B-3E0938DEFFFB@oracle.com> There are many CSS feature requests in JIRA that address these. Since CSS bugs end up in my lap, you can run the query "assignee = dgrieve AND (status = Open OR status = New)" to get an idea. Other comments in-line On Jul 6, 2012, at 5:52 AM, Pedro Duque Vieira wrote: > > Here are some of the ways that javafx differs from standard css (not a > comprehensive list, just a list of the ones that come to my mind): > > 1- Use of -fx- prefix everywhere. > > This was made so that javafx css would not interfere with standard css > written on the same file. However I don't see this scenario coming up that > often, and you can use different identifiers or css files if you happen to > use the two models on the same app. The need for the -fx- prefix is more for taking a JavaFX CSS file and using it in a browser. We should support border-color, for example, but border-color only supports one layer of color whereas -fx-border-color supports many layers of paint. > > 2- Effects > > Drop shadow and inner shadow syntax differs from HTML syntax Good point, and I don't think there is an issue in JIRA for this one. Would you mind creating one? > > 3- Lack of support for "margin" JavaFX doesn't implement the box model, per se. The class Region is where backgrounds and borders are encapsulated and "margin" can be accomplished through a combination of -fx-padding and -fx-background-insets. But in practice, you'd do this with layout. I'm not saying that JavaFX doesn't need margin, nor am I saying it does. > > 4- The ":first-child", ":first-line", ":first-letter" is not supported There is a feature request for this as well. > > 5-The ":active" and ":focus" dynamic pseudo-classes are not supported, > Their name in javafx is ":pressed" and ":focused" This is another place where we need to reconcile JavaFX CSS with W3C standard CSS. The pseudo-class names in JavaFX match the JavaFX property names and they should probably be prefixed with -fx-. > > 6- ":link" is not supported > > 7- JavaFX CSS does not support comma-separated series of font family names > in the -fx-font-family property This has been a bug for a long, long time. > > 8- Not sure but I think the ordering on some css properties is different > > > And some more debatable ways that could make no sense to support: > > 9- The optional line height parameter when specifying fonts is not supported > > 10- No support for p, div, h1, h2, a... > > > Thanks, best regards, > > -- > Pedro Duque Vieira David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From david.grieve at oracle.com Fri Jul 6 07:50:17 2012 From: david.grieve at oracle.com (David Grieve) Date: Fri, 6 Jul 2012 10:50:17 -0400 Subject: Differences between "standard" css In-Reply-To: References: <644C46B1-636A-48A1-AF7B-3E0938DEFFFB@oracle.com> Message-ID: <8B86CAF7-B3C7-40A7-ABAE-59D87D971D3C@oracle.com> On Jul 6, 2012, at 10:05 AM, Pedro Duque Vieira wrote: > David, thanks for answering. > > The need for the -fx- prefix is more for taking a JavaFX CSS file and using it in a browser. We should support border-color, for example, but border-color only supports one layer of color whereas -fx-border-color supports many layers of paint > > Isn't it still possible to do that without the -fx- prefix? Can't -fx-border-color be named border-color and still support both various layers of paint and only one? > Is there any practical advantage in using a javafx css file in a browser? would someone do that? > The point is I think the -fx- prefix brings less advantages than not having it. If we are to follow the W3C standard, which is a "good thing" ?, then we need to employ the -fx- prefix where javafx css syntax is not the same as, or not a part of, the W3C standard since such syntax would be considered a "vendor specific extension." > This is another place where we need to reconcile JavaFX CSS with W3C standard CSS. The pseudo-class names in JavaFX match the JavaFX property names and they should probably be prefixed with -fx-. > Wouldn't it be possible to have both? Both doing the same but with different names for the purpose of supporting "standard" css. > That is the objective, yes. > Also I remembered one more point: in "standard" css you don't have background-radius: border-radius affects both border and background. While in javafx css border-radius doesn't make any change to the background. > A backgrounds is handled by Region as separate a Rectangle from a border, hence the -fx-background-radius. As an aside, it is more efficient for JavaFX to paint a fill than a stroke. A skin for a Button for example (as styled in caspian.css) is layers of background fill even though it looks like one background fill with several borders. 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 tom.schindl at bestsolution.at Fri Jul 6 08:30:02 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 06 Jul 2012 17:30:02 +0200 Subject: FXML backwards compatibility issue In-Reply-To: <9CD5674A-D730-4472-95E2-D1112D842A06@oracle.com> References: <2F622BC0-BB3F-4F5A-9FC5-0B39B6F40BA5@gmail.com> <9CD5674A-D730-4472-95E2-D1112D842A06@oracle.com> Message-ID: <4FF7047A.4040002@bestsolution.at> I have to say that I'm not overly happy with this "Injection container like behavior of FXMLLoader". I think only fields marked for injection should be injected and because you are not a true DI-Container you'll have to use your own annotation. Be it @FXML or @FInject. Tom Am 27.06.12 16:15, schrieb Greg Brown: >> Thanks for the prompt reply on the resource issue. I appreciate it. > > No problem - thanks for identifying the issue. I just committed the fix. > > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From david.grieve at oracle.com Fri Jul 6 09:52:16 2012 From: david.grieve at oracle.com (David Grieve) Date: Fri, 6 Jul 2012 12:52:16 -0400 Subject: Differences between "standard" css In-Reply-To: References: <644C46B1-636A-48A1-AF7B-3E0938DEFFFB@oracle.com> <8B86CAF7-B3C7-40A7-ABAE-59D87D971D3C@oracle.com> Message-ID: On Jul 6, 2012, at 11:17 AM, Pedro Duque Vieira wrote: > I think that trying to be like "standard" css but at the same type also trying to be an optimized javafx version of it ends up with something that is neither. I think if Oracle is going for an optimized version of css for javafx might as well go all the way and define your own "language" (might be similar to css) since css has several issues and was intended for HTML not standard app development. I think it is important to be standard where possible and applicable and darn close otherwise. That we are not there yet is just a matter of resources and priorities. > > If we are to follow the W3C standard, which is a "good thing" ?, then we need to employ the -fx- prefix where javafx css syntax is not the same as, or not a part of, the W3C standard since such syntax would be considered a "vendor specific extension." > I don't defend following W3C standards just for the sake of being a W3C standard, I'm for being similar to standard css for the advantages I mentioned. > One more question that I sincerely don't know the answer to: if you don't have the standard border-color, background-color, etc because everything is prefixed with "-fx-" and in some cases works different is it still considered a "W3C css standard", that javafx css is trying to be? This raises the question of what it means to conform the standard. One should not expect a JavaFX user agent to have the same requirements as an browser user agent. A scene-graph is not the same thing as an HTML document tree. If you apply the point in http://www.w3.org/TR/CSS2/conform.html#conformance to JavaFX, JavaFX can comply with the standard. There is still much work to be done in every area from the parser on down to get to that point. David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From david.grieve at oracle.com Fri Jul 6 10:21:20 2012 From: david.grieve at oracle.com (David Grieve) Date: Fri, 6 Jul 2012 13:21:20 -0400 Subject: CSS-Documentation for IDE-Usage In-Reply-To: References: <4FE03A80.4040700@bestsolution.at> Message-ID: <4391A9D1-2466-455C-872D-613FF76F311A@oracle.com> There is no such document, just the cssref html document. I would like, however, to get all of the tables and such that describe the css properties out of that document and into proper javadoc for the corresponding JavaFX properties - perhaps with an @css javadoc tag or an @css annotation. I'm not sure if that would hurt or help. On Jun 19, 2012, at 11:59 AM, Richard Bair wrote: > Hi Tom, > > I don't think we have a structured document with this information, but it sounds useful! David is on Vacation but he should be involved when he gets back hopefully later this week or next week. > > Cheers > Richard > > On Jun 19, 2012, at 1:38 AM, Tom Schindl wrote: > >> Hi, >> >> Is there some structured text document one can use to teach IDEs hover >> documentation of CSS-Attribute, or do I need to extract those >> information from the published HTML-CSS-Documentation? >> >> My hope is that this document is generated from some more structured >> resource I can use in my Eclipse integration. If there's no such >> document, I'd like to contribute in creating such a meta-format and >> generate the HTML-Document from it. Any netbeans people here who'd like >> to work with me on this? >> >> Tom >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 > 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 tom.schindl at bestsolution.at Fri Jul 6 10:57:52 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 06 Jul 2012 19:57:52 +0200 Subject: CSS-Documentation for IDE-Usage In-Reply-To: <4391A9D1-2466-455C-872D-613FF76F311A@oracle.com> References: <4FE03A80.4040700@bestsolution.at> <4391A9D1-2466-455C-872D-613FF76F311A@oracle.com> Message-ID: <4FF72720.4020402@bestsolution.at> [resending because attached documents are too big :-(] Hi, Well for me the important thing is a meta format I can feed to my IDE-Tooling which holds the following informations: * property name * validation information I've been working on a long train drive 2 weeks ago on such a meta format and translated fairly all informations found in the HTML-document into my meta language (the grammer of the language is not yet able to define all constructs in the document but we I'm not far way I've developed this using xtext-framework (http://www.eclipse.org/Xtext/) which has the advantage that I also have an editor with syntax highlighting, auto-completetion, ... in my Eclipse. I'm not sure this is the same direction you are heading to - for me a meta format be it XML, ... (I can easily provide you an XML-Representation of the xtext-Spec I attached) is the important thing I need to make my tooling cleverer. The documents are: * grammer: http://pastebin.com/qsbtuTa6 * css-def: http://pastebin.com/FpqGmUBg Tom Am 06.07.12 19:21, schrieb David Grieve: > There is no such document, just the cssref html document. > > I would like, however, to get all of the tables and such that describe > the css properties out of that document and into proper javadoc for the > corresponding JavaFX properties - perhaps with an @css javadoc tag or an > @css annotation. I'm not sure if that would hurt or help. > > On Jun 19, 2012, at 11:59 AM, Richard Bair wrote: > >> Hi Tom, >> >> I don't think we have a structured document with this information, but >> it sounds useful! David is on Vacation but he should be involved when >> he gets back hopefully later this week or next week. >> >> Cheers >> Richard >> >> On Jun 19, 2012, at 1:38 AM, Tom Schindl wrote: >> >>> Hi, >>> >>> Is there some structured text document one can use to teach IDEs hover >>> documentation of CSS-Attribute, or do I need to extract those >>> information from the published HTML-CSS-Documentation? >>> >>> My hope is that this document is generated from some more structured >>> resource I can use in my Eclipse integration. If there's no such >>> document, I'd like to contribute in creating such a meta-format and >>> generate the HTML-Document from it. Any netbeans people here who'd like >>> to work with me on this? >>> >>> Tom >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 >> > > > 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 > -- 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 greg.x.brown at oracle.com Fri Jul 6 11:09:41 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 6 Jul 2012 14:09:41 -0400 Subject: FXML backwards compatibility issue In-Reply-To: <4FF7047A.4040002@bestsolution.at> References: <2F622BC0-BB3F-4F5A-9FC5-0B39B6F40BA5@gmail.com> <9CD5674A-D730-4472-95E2-D1112D842A06@oracle.com> <4FF7047A.4040002@bestsolution.at> Message-ID: <453F5025-D1ED-4AAF-B1DD-7152C7A98B6D@oracle.com> > I have to say that I'm not overly happy with this "Injection container > like behavior of FXMLLoader". I think only fields marked for injection > should be injected That's exactly how it works. If a protected or private field is not annotated, it will not be injected. From daniel at lotsovcookiez.com Fri Jul 6 17:17:54 2012 From: daniel at lotsovcookiez.com (Daniel Opitz) Date: Sat, 07 Jul 2012 02:17:54 +0200 Subject: Font anti-aliasing fixes not available on Linux? Message-ID: Hello, I'm using the current developer build (2.2 b15) and I'm wondering if the sub-pixel anti-aliasing is enabled on Linux too? I can change the hinting (none, slight, medium, full) and anti-aliasing (none, grayscale, rgba) system-wide and everything but JavaFX looks really nice with the slight/rgba setting. Kind regards, Daniel Opitz From philip.race at oracle.com Fri Jul 6 20:06:57 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 06 Jul 2012 20:06:57 -0700 Subject: Font anti-aliasing fixes not available on Linux? In-Reply-To: References: Message-ID: <4FF7A7D1.4060008@oracle.com> Its no different on Linux than any other platform meaning that if your system cannot support the hardware accelerated Prism stack that you will not get LCD text. It works just fine and dandy for me on a rather old (3-4 yrs) Dell PC with Ubuntu 11.10. But on Linux the whole h/w accelerated stack is unavailable unless you have Nvidia graphics and the right drivers etc. -phil. On 7/6/12 5:17 PM, Daniel Opitz wrote: > Hello, > > I'm using the current developer build (2.2 b15) and I'm wondering if > the sub-pixel anti-aliasing is enabled on Linux too? I can change the > hinting (none, slight, medium, full) and anti-aliasing (none, > grayscale, rgba) system-wide and everything but JavaFX looks really > nice with the slight/rgba setting. > > Kind regards, > Daniel Opitz From simon.ritter at oracle.com Sun Jul 8 01:09:52 2012 From: simon.ritter at oracle.com (Simon Ritter) Date: Sun, 08 Jul 2012 09:09:52 +0100 Subject: Access to Axis of a Slider Message-ID: <4FF94050.6000807@oracle.com> Hi, I've built a UI that puts a slider on a black background with tick marks and tick mark labels enabled. Given the dark grey colour they are almost invisible. It seems the only way to change this is via CSS through the -fx-tick-label-fill property. It strikes me that the Slider class should expose the encapsulated Axis object so that the properties of the Axis can be changed programmatically. Regards, Simon. From tom.schindl at bestsolution.at Sun Jul 8 04:07:23 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 08 Jul 2012 13:07:23 +0200 Subject: Access to Axis of a Slider In-Reply-To: <4FF94050.6000807@oracle.com> References: <4FF94050.6000807@oracle.com> Message-ID: <4FF969EB.9090306@bestsolution.at> I disagree to expose the Axis object! I think it is the wrong decision anyways to reuse the axis object in a Control. The reason I would change that is that if you want to split up FX into modules i think the control module should be independent of the chart module (and most likely it should be the other way round as well). Tom Am 08.07.12 10:09, schrieb Simon Ritter: > Hi, > I've built a UI that puts a slider on a black background with tick marks > and tick mark labels enabled. Given the dark grey colour they are > almost invisible. It seems the only way to change this is via CSS > through the -fx-tick-label-fill property. It strikes me that the Slider > class should expose the encapsulated Axis object so that the properties > of the Axis can be changed programmatically. > > Regards, > > Simon. -- 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 simon.ritter at oracle.com Sun Jul 8 13:55:38 2012 From: simon.ritter at oracle.com (Simon Ritter) Date: Sun, 08 Jul 2012 21:55:38 +0100 Subject: Access to Axis of a Slider Message-ID: <4FF9F3CA.1060400@oracle.com> OK, but if the Axis object is not exposed, there still needs to be a way to programmatically change at least the fill colour of the tick marks and tick mark labels, yes? Regards, Simon. > I disagree to expose the Axis object! > > I think it is the wrong decision anyways to reuse the axis object in a > Control. The reason I would change that is that if you want to split up > FX into modules i think the control module should be independent of the > chart module (and most likely it should be the other way round as well). > > Tom > > Am 08.07.12 10:09, schrieb Simon Ritter: >> > Hi, >> > I've built a UI that puts a slider on a black background with tick marks >> > and tick mark labels enabled. Given the dark grey colour they are >> > almost invisible. It seems the only way to change this is via CSS >> > through the -fx-tick-label-fill property. It strikes me that the Slider >> > class should expose the encapsulated Axis object so that the properties >> > of the Axis can be changed programmatically. >> > >> > Regards, >> > >> > Simon. From hang.vo at oracle.com Sun Jul 8 22:03:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Jul 2012 05:03:24 +0000 Subject: hg: openjfx/2.2/controls/rt: 3 new changesets Message-ID: <20120709050331.0997247E86@hg.openjdk.java.net> Changeset: 330911490952 Author: jgiles Date: 2012-07-09 10:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/330911490952 RT-21684: TableView with hidden/invisible columns: resizing of columns gets confused ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: e3ddeb5fe157 Author: jgiles Date: 2012-07-09 10:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/e3ddeb5fe157 RT-23067: AIOOBE when expand one of selected nodes in TreeView ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: 2e3e8a90f8c0 Author: jgiles Date: 2012-07-09 16:49 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2e3e8a90f8c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From tom.schindl at bestsolution.at Sun Jul 8 23:27:23 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 09 Jul 2012 08:27:23 +0200 Subject: Access to Axis of a Slider In-Reply-To: <4FF9F3CA.1060400@oracle.com> References: <4FF9F3CA.1060400@oracle.com> Message-ID: <4FFA79CB.6000001@bestsolution.at> A lot of stuff in controls can not be modified using API because they are defined by the Skin-Class which is not exposed. Tom Am 08.07.12 22:55, schrieb Simon Ritter: > OK, but if the Axis object is not exposed, there still needs to be a way > to programmatically change at least the fill colour of the tick marks > and tick mark labels, yes? > > Regards, > > Simon. > >> I disagree to expose the Axis object! >> >> I think it is the wrong decision anyways to reuse the axis object in a >> Control. The reason I would change that is that if you want to split up >> FX into modules i think the control module should be independent of the >> chart module (and most likely it should be the other way round as well). >> >> Tom >> >> Am 08.07.12 10:09, schrieb Simon Ritter: >>> > Hi, >>> > I've built a UI that puts a slider on a black background with tick >>> marks >>> > and tick mark labels enabled. Given the dark grey colour they are >>> > almost invisible. It seems the only way to change this is via CSS >>> > through the -fx-tick-label-fill property. It strikes me that the >>> Slider >>> > class should expose the encapsulated Axis object so that the >>> properties >>> > of the Axis can be changed programmatically. >>> > > Regards, >>> > > Simon. -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From pavel.safrata at oracle.com Mon Jul 9 06:40:40 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 09 Jul 2012 15:40:40 +0200 Subject: Region PickOnBounds default setting In-Reply-To: <2D9D89F2-2BEF-4979-ABEE-28D2ECCBFC11@oracle.com> References: <4FE185F4.9020407@oracle.com> <4FE2DEF5.8080209@oracle.com> <4FE307EB.6020202@xs4all.nl> <4FEC0F2A.6060406@oracle.com> <2D9D89F2-2BEF-4979-ABEE-28D2ECCBFC11@oracle.com> Message-ID: <4FFADF58.3060600@oracle.com> Ok but still it could have worked as expected automatically if the default value was correct. Issues like this will probably appear everywhere. Thanks, Pavel On 6.7.2012 0:17, Jasper Potts wrote: > Pavel, We recently found that bug in PieChart and have set PickOnBounds to false for all Pie slices. > > Jasper > > On Jun 28, 2012, at 1:00 AM, Pavel Safrata wrote: > >> I'm sorry for the delay. I commented on the issue and attached the EvilPane there. I also described another problem I just noticed: >> >> Another example is picking slices in a pie chart. Right now it by default picks completely wrong slices because each slice is a region and is picked on bounds that cover large portions of neighboring slices. You have to do a "data.getNode().setPickOnBounds(false);" exercise for each slice to make it behave reasonably. >> >> Thanks, >> Pavel >> >> On 21.6.2012 17:37, Richard Bair wrote: >>> Ah I see the problem. Pavel can we make sure there is some text in the issue describing the problem (ie bounds != region width/height, and thus pick on bounds is undeniably wrong in that case). >>> >>> Dan -- the bounds always must include the bounds of all stuff, without putting a clip on every region you have to be prepared for layout bounds != bounds in parent / bounds in local. >>> >>> Note that putting a clip on regions by default would be a huge mistake. You wouldn't be able to do a number of common effects where you are translating children outside the bounds of the container. It is the difference between basic form like apps and more graphical ones. >>> >>> On Jun 21, 2012, at 4:48 AM, Daniel Zwolenski wrote: >>> >>>> I just ran the code (thanks Pavel!) and I agree. While I see the problem >>>> with the picking, a bigger problem in my mind is that the max bounds are >>>> not being honoured. The picking to me is just a side effect of some odd >>>> layout sizing behaviour. >>>> >>>> My expectation with this code is it should either honour the max bounds and >>>> clip the child nodes (my preference) or, if it's really not going to honour >>>> the max bounds, then it should stretch the region to the bounds that it is >>>> actually covering. The hybrid thing it is doing is just weird in my >>>> opinion. >>>> >>>> >>>> On Thu, Jun 21, 2012 at 9:39 PM, John Hendrikx wrote: >>>> >>>>> Not sure if interested, but coming from someone who has never seen this >>>>> before... I must say it certainly looks counter-intuitive. Why does the >>>>> evilPane have such big bounds? It is restricted in layout to a max size of >>>>> (50,50)... and thus I would expect the blue child to be clipped and the >>>>> pane Bounds to be reduced to no more than (50,50). >>>>> >>>>> But I guess that is because of the tree style rendering that JavaFX does, >>>>> where nodes can exceed their layout bounds when effects/translations are >>>>> applied... as I said, it certainly looks counter-intuitive, in more ways >>>>> than one coming from someone who is used to Container/Groups strictly sized >>>>> to fit their children, and clipping the children that will not fit. >>>>> >>>>> --John >>>>> >>>>> >>>>> On 21/06/2012 10:44, Pavel Safrata wrote: >>>>> >>>>>> Hi Daniel, >>>>>> >>>>>> On 20.6.2012 21:55, Daniel Zwolenski wrote: >>>>>> >>>>>>> Assuming I understand the problem then I've hit this sort of layout >>>>>>>>> problem and my instinct was to look >>>>>>>>> I'm not sure I agree with the bug description when it says that "both >>>>>>>>> visually and in source code there is nothing in between the pane and the >>>>>>>>> child". In code there is a pane. Visually there would be a pane if you set >>>>>>>>> styles on it. >>>>>>>>> >>>>>>>> The pane from the description is small and is in a top-left corner. It >>>>>>>> can be styled, and you can see it there. There is no code that would make >>>>>>>> the pane big to cover the whole scene, there is no way to make it visible >>>>>>>> in the whole area, because it's just not there. >>>>>>>> >>>>>>> I am perhaps missing something, but "Pane's bounds will then cover whole >>>>>>> sceen" implies to me the pane is stretched, so if I styled it I would see >>>>>>> it stretched. The description of #2 is a bit vague to me though. I guess a >>>>>>> code example would clear this up but it probably doesn't matter that I dont >>>>>>> understand. >>>>>>> >>>>>> The pane is not necessarily stretched to embrace all its children. I've >>>>>> attached a code example that shows the problem. >>>>>> >>>>>> >>>>>>> I'm guessing, for example, if this fix went in it would break all my >>>>>>>>> 'glasspanes'? >>>>>>>>> >>>>>>>> I cannot say unless I know how your glasspanes are implemented... >>>>>>>> >>>>>>> I use glass panes to block the screen in two cases: when loading and >>>>>>> behind a light box (ie embedded dialog). >>>>>>> >>>>>>> In both cases my glass pane is just a pane (eg BorderPane) added to the >>>>>>> top of a StackPane with the rest of the app added to a lower layer of the >>>>>>> stack. In the loading case it has no children, in the dialog case it's >>>>>>> child is the dialog. >>>>>>> >>>>>>> The loading one is transparent but has an in-progress cursor when you >>>>>>> mouse over. In the dialog case, the pane is a translucent grey, though you >>>>>>> could style it differently and transparent would be a valid style (making >>>>>>> the fill color define if it is clickable would not be nice for me and is a >>>>>>> little scary). >>>>>>> >>>>>>> In both cases the point of it is that it blocks mouse input to the >>>>>>> scene. I'd prefer this didn't break in a future release (sorry!). If auto >>>>>>> updating (my nemesis) wasn't on then I'd be ok for it to change and then I >>>>>>> fix my apps before moving to a higher version but it magically working one >>>>>>> day and not the next would be pretty nasty for me. >>>>>>> >>>>>> It would break your glass panes only if they have no fill (which I agree >>>>>> is bad enough). Pane with transparent fill would still block mouse events. >>>>>> I'm not sure why this is scary, this approach is used everywhere in FX >>>>>> except of Region. >>>>>> >>>>>> >>>>>>> As such, I don't think it needs to be a default attribute now that it's >>>>>>>>> in place the other way round but I do think it needs to be clear and >>>>>>>>> intuitive how to deal with it. >>>>>>>>> >>>>>>>> I'm really sad that we've let this go that far, it could have been >>>>>>>> fixed before our first release. If the decision comes that it's too late by >>>>>>>> now, the way how to deal with it will be clear (setPickOnBounds(false)), >>>>>>>> but I doubt it is (and could be) intuitive. >>>>>>>> >>>>>>> For me the current default behavior seems intuitive: the pane is >>>>>>> clickable for whatever area it takes up. I get the feeling I might be >>>>>>> missing something here though as it is obviously a concern for some people. >>>>>>> Sorry if I have misunderstood. >>>>>>> >>>>>> I think the attached example shows pane that is clickable in area that it >>>>>> doesn't take up. >>>>>> >>>>>> >>>>>>> For me the only problem with the current approach is that in some cases >>>>>>> I'd like a pane used purely for layout (anchor pane as top layer of a >>>>>>> StackPane is a prime candidate) to not catch mouse clicks but the children >>>>>>> on it still should. Calling setPickOnBounds(false) and setShape(null) to do >>>>>>> this is not intuitive to me but I'm glad I now know its possible as I've >>>>>>> struggled with this before (and possibly raised a bug, will have to check). >>>>>>> >>>>>> This is exactly the most common problem that would be solved. You see >>>>>> you're glad that you now know how to solve it, but other users will keep >>>>>> bumping into this issue.. >>>>>> >>>>>> Thanks, >>>>>> Pavel >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>>> Pavel >>>>>>>> >>>>>>>> >>>>>>>>> On 20/06/2012, at 5:41 AM, Richard Bair >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi folks, >>>>>>>>>> We have an issue which has been in the platform from before 2.0: >>>>>>>>>> http://javafx-jira.kenai.com/**browse/RT-17024. >>>>>>>>>> A better explanation of the issue can be found on >>>>>>>>>> http://javafx-jira.kenai.com/**browse/RT-12258. >>>>>>>>>> From 12258: >>>>>>>>>> >>>>>>>>>> Region behaves counter-intuitively regarding mouse event delivering. >>>>>>>>>>> It reacts on mouse events everywhere in its bounds and people are often >>>>>>>>>>> confused by it. Here are two simple examples: >>>>>>>>>>> >>>>>>>>>>> 1) You create let's say HBox just because you want it to layout its >>>>>>>>>>> children. The HBox catches all mouse events in the whole area given by its >>>>>>>>>>> bounds. Often it's hard to understand what area it is (with children of >>>>>>>>>>> different size or with some other layout stretches taking place). >>>>>>>>>>> >>>>>>>>>>> 2) You create a small Pane in top-left corner of the scene with a >>>>>>>>>>> child in bottom-right corner of the scene. Pane's bounds will then cover >>>>>>>>>>> whole sceen and you won't be able to click on anything else than the pane >>>>>>>>>>> and its child. Users don't understand why, because both visually and in >>>>>>>>>>> source code there is nothing in between the pane and the child. >>>>>>>>>>> >>>>>>>>>>> Moreover, region may have a shape associated and the behavior here >>>>>>>>>>> is also strange. If you create a region with a shape inside its bounds, >>>>>>>>>>> it's just ignored. You can also create a shape somewhere else, then it >>>>>>>>>>> extends region's bounds and it reacts on mouse click everywhere between the >>>>>>>>>>> shape and the region. >>>>>>>>>>> >>>>>>>>>> This issue has to do with the semantics of picking on a Region. For >>>>>>>>>> Region we have had pickOnBounds set to true by default, which yields the >>>>>>>>>> above behaviors. We can change it to false by default, but then need to >>>>>>>>>> update a bunch of skins (for example the up/down arrows of scroll bar, the >>>>>>>>>> thumb of a slider, the down arrow of a combo box button, etc) so that they >>>>>>>>>> switch back to having pickOnBounds set to true by default so that the >>>>>>>>>> target area for clicks is larger. We could just change the default for Pane >>>>>>>>>> and not for Region, although we use StackPane in Skins and would have to >>>>>>>>>> update them anyhow. It seems that for a normal layout container the >>>>>>>>>> behavior really should be pickOnBounds=false by default, but for UI >>>>>>>>>> controls usages and such you generally want it true. >>>>>>>>>> >>>>>>>>>> I'm not certain making this change is worth being backwards >>>>>>>>>> incompatible (semantically, binary compatibility would remain). But what do >>>>>>>>>> you think? >>>>>>>>>> >>>>>>>>>> Richard >>>>>>>>>> >> From tom.schindl at bestsolution.at Mon Jul 9 06:56:44 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 09 Jul 2012 15:56:44 +0200 Subject: JavaFX and SWT (Eclipse SDK) on Linux and Popup/Context-Menus Message-ID: <4FFAE31C.1010505@bestsolution.at> Hi, I've a bug report against my tooling on linux [1] which says that once you embed JavaFX into an Eclipse View *all* popup menus are not shown any more. I tried to reproduce this with a standalone SWT/JavaFX snippet but I'm unable to reproduce it there yet :-( hence I've not yet filed a jira ticket for it. I've debugged the Eclipse code which runs fine and finally calls: .... menu.setLocation(...); menu.setVisible(true); but the Popup-Menu (e.g. on toolbar-dropdowns, inside the trees, ...) is not shown. I'm posting here because maybe someone from the fx-gtk-team has an idea what could cause this odd behaviour. It looks like *only* popup menus are affected so this is kind of strange. So has anyone out there an idea what could cause this problem? Maybe it has something to do with OSGi so I'll try to create an small OSGi-App which uses JavaFX and SWT but anyways anybody an idea? OS-X and Windows are not affected by this so my wild guess is that something in glass is vetoing the displaying of the menu. Tom [1]http://efxclipse.org/trac/ticket/164 -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Mon Jul 9 07:32:04 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 09 Jul 2012 16:32:04 +0200 Subject: JavaFX and SWT (Eclipse SDK) on Linux and Popup/Context-Menus In-Reply-To: <4FFAE31C.1010505@bestsolution.at> References: <4FFAE31C.1010505@bestsolution.at> Message-ID: <4FFAEB64.6020008@bestsolution.at> Hi, Well in an OSGi/SWT/JavaFX application the same problem happens. So all I can say now is that it's not my OSGi integration but something different that's going wrong somewhere. Tom Am 09.07.12 15:56, schrieb Tom Schindl: > Hi, > > I've a bug report against my tooling on linux [1] which says that once > you embed JavaFX into an Eclipse View *all* popup menus are not shown > any more. > > I tried to reproduce this with a standalone SWT/JavaFX snippet but I'm > unable to reproduce it there yet :-( hence I've not yet filed a jira > ticket for it. > > I've debugged the Eclipse code which runs fine and finally calls: > > .... > menu.setLocation(...); > menu.setVisible(true); > > but the Popup-Menu (e.g. on toolbar-dropdowns, inside the trees, ...) is > not shown. I'm posting here because maybe someone from the fx-gtk-team > has an idea what could cause this odd behaviour. It looks like *only* > popup menus are affected so this is kind of strange. > > So has anyone out there an idea what could cause this problem? Maybe it > has something to do with OSGi so I'll try to create an small OSGi-App > which uses JavaFX and SWT but anyways anybody an idea? > > OS-X and Windows are not affected by this so my wild guess is that > something in glass is vetoing the displaying of the menu. > > Tom > > [1]http://efxclipse.org/trac/ticket/164 > -- 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 Mon Jul 9 10:04:16 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Jul 2012 17:04:16 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120709170421.1C0FF47E9C@hg.openjdk.java.net> Changeset: 0122996d25d3 Author: David Grieve Date: 2012-07-09 12:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0122996d25d3 RT-22076: backout patch. Fix deferred to 3.0 ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: 5b3e02e4f23b Author: David Grieve Date: 2012-07-09 12:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/5b3e02e4f23b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: a88de67241de Author: David Grieve Date: 2012-07-09 12:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a88de67241de RT-21594: If the style cache for a node is null, then tell the node to reapply CSS because the StyleHelper is no good in this case. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 18f3884957e7 Author: David Grieve Date: 2012-07-09 12:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/18f3884957e7 RT-23184: adding same UA stylesheet should not cause styles to be obliterated ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java From hang.vo at oracle.com Mon Jul 9 10:18:48 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Jul 2012 17:18:48 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-23033 : Label with setFocusTraversable(true) breaks focus traversing Message-ID: <20120709171849.6171347E9F@hg.openjdk.java.net> Changeset: f3bb020babab Author: mickf Date: 2012-07-09 18:12 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/f3bb020babab RT-23033 : Label with setFocusTraversable(true) breaks focus traversing ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java From hang.vo at oracle.com Mon Jul 9 10:33:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Jul 2012 17:33:22 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20222 : Ensemble - Controls on the right side are not reachable via keyboard Message-ID: <20120709173323.B084147EA2@hg.openjdk.java.net> Changeset: a8bd152f64ad Author: mickf Date: 2012-07-09 18:17 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a8bd152f64ad RT-20222 : Ensemble - Controls on the right side are not reachable via keyboard ! javafx-ui-common/src/com/sun/javafx/scene/traversal/ContainerTabOrder.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java From hang.vo at oracle.com Mon Jul 9 13:33:36 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Jul 2012 20:33:36 +0000 Subject: hg: openjfx/2.2/controls/rt: 7 new changesets Message-ID: <20120709203343.9549447EB5@hg.openjdk.java.net> Changeset: 40d9b78ba945 Author: Pavel Safrata Date: 2012-07-02 14:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/40d9b78ba945 RT-22747, RT-22749: marked additional SB dependencies. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.java Changeset: b27852b420e2 Author: "Joseph Andresen" Date: 2012-07-02 06:08 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b27852b420e2 RT-21828 Canvas Screen Lock ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 6b0866a7c08c Author: Yao Wang Date: 2012-07-03 10:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6b0866a7c08c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: 7f0d5537b52a Author: mfang Date: 2012-06-29 21:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7f0d5537b52a RT-23080: NLS: javafx2.2 message drop 20 integration ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_de.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_es.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_fr.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_it.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ja.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ko.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_pt_BR.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_sv.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_CN.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_TW.properties Changeset: bc2e7244d877 Author: igor Date: 2012-07-03 16:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/bc2e7244d877 Merge Changeset: 554e78523bab Author: hudson Date: 2012-07-05 12:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/554e78523bab Added tag 2.2-b16 for changeset bc2e7244d877 ! .hgtags Changeset: 1eadff96bc2b Author: Kinsley Wong Date: 2012-07-09 13:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1eadff96bc2b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java From hang.vo at oracle.com Mon Jul 9 15:04:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Jul 2012 22:04:34 +0000 Subject: hg: openjfx/2.2/graphics/rt: [javadoc] RT-22593 Effects: some treat as private docs missing Message-ID: <20120709220439.94DC147EBB@hg.openjdk.java.net> Changeset: 64f2c821ab4e Author: "Joseph Andresen" Date: 2012-07-09 14:22 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/64f2c821ab4e [javadoc] RT-22593 Effects: some treat as private docs missing ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java From hjohn at xs4all.nl Mon Jul 9 15:51:45 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 10 Jul 2012 00:51:45 +0200 Subject: Little worried about the ListView/TreeView/TableView classes Message-ID: <4FFB6081.3090300@xs4all.nl> My program relies extensively on the *View classes, however, there are numerous little problems with these (JavaFX 2.2b13) that I'm considering rewriting these controls myself to "take control" and being able to fix problems. Many of the issues I've reported as bugs, which are all in the process of being deferred to JFX3.0 (if I understand correctly), which is scheduled for over a year from now. Here is a list of problems I've been running into just this past week -- and I've reported several others. Most of these apply to any of the *View classes, but some may be specific to one of the types. - Calling requestFocus() behaves differently from clicking with mouse/tabbing when using only keyboard navigation: Left Mouse Click: Current focusowner : VirtualFlow[id=virtual-flow, styleClass=] Current focusowner : ListView[id=null, styleClass=list-view] Tabbing to it: Current focusowner : ListView[id=null, styleClass=list-view] Programmatic requestFocus() immediately after ListView added to Scene: Current focusowner : ListView at 1966198[styleClass=list-view] Why is it not the same? This seems to be causing issues sometimes where the ListView is not properly activated and it is not accepting keyboard input (despite being the focusowner as printed above). - Sometimes ListView starts highlighting every Xth cell when scrolling through list Scrolling through a ListView using the cursor keys one can get the ListView stuck to highlighting only the Xth cell (where X seems to be in the range of the number of active Cells). When there is only few items in the list this bug manifests itself as not changing the focus of the item at all (ie, the wrong cell is highlighted). Usually a mouse click on a random item fixes this bug again, but sometimes even that doesn't work. This bug is incredibly hard to reproduce but the frequency of it can be increased by using a ScrollBar Skin that breaks the rule that getNode() should always return the same item. It however happens with the default ScrollBar Skin as well, just much much rarer. I have a test case with a contract-breaking ScrollBar Skin that manages to reproduce it almost every time. - Page up broken when used at bottom of ListView Scroll down fully with page down. Now page up, notice that it goes up one page, but the next page up only goes up one item for a few times (about a page worth of items) before starting to act like a real page up again. - Pressing Cursor Left/Right on an active ListView changes focus despite keys being consumed Despite having a handler in setOnKeyPressed that consumes the Cursor keys (to do something useful with them) the focus still also changes (ie, it triggers my action AND affects a focus change). I can block them with an EventFilter, but would rather allow users of my custom control to still being able to register these keys for special purposes... - Numerous scrollTo bugs Poor centering when scrolling to an item (sometimes even outside view port); not responding at all when called at inoppertune times (right after populating and adding to scene); unable to precisely save/restore view position; creating cells for every item from 0 to item being scrolled to... and recently (since 2.2betas) completely failure to draw the ListView at all (can take various forms, only scrollbars drawn, somtimes the entire container is missing). Restores itself on any ListView redrawing activity, like selecting cell, scrolling with cursor keys, etc.. - Numerous focus/select bugs Similar to above, when these things occur in rapid succession (ListView added to Scene, populated, correct item selected, scrolled to saved position) it happens frequently that no cell gets highlighted at all (or perhaps the wrong one is highlighted but not visible at the current scroll position) - Cells are sometimes a pixel different in height Haven't been able to find a pattern to this yet, it happens with the default cell renderer when it is styled with some fancy borders. Very noticable when holding cursor down because the borders jitter (create a border with an inset of 1 or 2 pixels so there should be a fixed gap between the cells, the gap will sometimes be a pixel larger than usual). It doesn't seem to be content related as a cell that is a pixel too large in the upper half of the ListView can appear regular size in the bottom half of the ListView. .... There are probably more I forgot to list or already worked around and forgot about (I seem to remember constructing a ListView, not adding it to Scene, but populating it and selecting an item and calling scrollTo, and THEN adding it to the Scene works very poorly as well). Anyway... I'm a bit worried that fixes for these are now over a year away... I don't really need much (just a scrollbar, some same height, same width custom cells, nicely stacked on top of each other reacting to cursor input) but I just keep running into above problems during normal use of the app. Can I help get these debugged or am I on my own? --John From jonathan.giles at oracle.com Mon Jul 9 16:02:43 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 10 Jul 2012 11:02:43 +1200 Subject: Little worried about the ListView/TreeView/TableView classes In-Reply-To: <4FFB6081.3090300@xs4all.nl> References: <4FFB6081.3090300@xs4all.nl> Message-ID: <4FFB6313.8000303@oracle.com> I'm happy to help work through these issues to try to find fixes (which may be able to get into 2.2) or find workarounds, although it is probably easier to have a discussion on each of the jira issue pages, rather than grouped together in an email (both for ease of discussion, and so we can have a record of what was said). Chances are all these bugs are already assigned to me. If so, lets start working through these right away. If not, email me the bug report numbers and I'll add myself as a watcher (or take ownership of them as they are likely my bugs anyway). -- Jonathan On 10/07/2012 10:51 a.m., John Hendrikx wrote: > My program relies extensively on the *View classes, however, there are > numerous little problems with these (JavaFX 2.2b13) that I'm > considering rewriting these controls myself to "take control" and > being able to fix problems. > > Many of the issues I've reported as bugs, which are all in the process > of being deferred to JFX3.0 (if I understand correctly), which is > scheduled for over a year from now. > > Here is a list of problems I've been running into just this past week > -- and I've reported several others. Most of these apply to any of > the *View classes, but some may be specific to one of the types. > > - Calling requestFocus() behaves differently from clicking with > mouse/tabbing when > using only keyboard navigation: > > Left Mouse Click: > Current focusowner : VirtualFlow[id=virtual-flow, styleClass=] > Current focusowner : ListView[id=null, styleClass=list-view] > > Tabbing to it: > Current focusowner : ListView[id=null, styleClass=list-view] > > Programmatic requestFocus() immediately after ListView added to Scene: > Current focusowner : ListView at 1966198[styleClass=list-view] > > Why is it not the same? This seems to be causing issues sometimes > where the ListView > is not properly activated and it is not accepting keyboard input > (despite being the > focusowner as printed above). > > - Sometimes ListView starts highlighting every Xth cell when scrolling > through list > > Scrolling through a ListView using the cursor keys one can get the > ListView stuck to > highlighting only the Xth cell (where X seems to be in the range of > the number of active > Cells). When there is only few items in the list this bug manifests > itself as not > changing the focus of the item at all (ie, the wrong cell is > highlighted). Usually a > mouse click on a random item fixes this bug again, but sometimes even > that doesn't work. > > This bug is incredibly hard to reproduce but the frequency of it can > be increased > by using a ScrollBar Skin that breaks the rule that getNode() should > always return the > same item. It however happens with the default ScrollBar Skin as > well, just much much > rarer. I have a test case with a contract-breaking ScrollBar Skin > that manages to > reproduce it almost every time. > > - Page up broken when used at bottom of ListView > > Scroll down fully with page down. Now page up, notice that it goes up > one page, but the > next page up only goes up one item for a few times (about a page worth > of items) before > starting to act like a real page up again. > > - Pressing Cursor Left/Right on an active ListView changes focus > despite keys being consumed > > Despite having a handler in setOnKeyPressed that consumes the Cursor > keys (to do something > useful with them) the focus still also changes (ie, it triggers my > action AND affects > a focus change). I can block them with an EventFilter, but would > rather allow users of > my custom control to still being able to register these keys for > special purposes... > > - Numerous scrollTo bugs > > Poor centering when scrolling to an item (sometimes even outside view > port); not responding > at all when called at inoppertune times (right after populating and > adding to scene); unable > to precisely save/restore view position; creating cells for every item > from 0 to item being > scrolled to... and recently (since 2.2betas) completely failure to > draw the ListView at all > (can take various forms, only scrollbars drawn, somtimes the entire > container is missing). > Restores itself on any ListView redrawing activity, like selecting > cell, scrolling with cursor > keys, etc.. > > - Numerous focus/select bugs > > Similar to above, when these things occur in rapid succession > (ListView added to Scene, > populated, correct item selected, scrolled to saved position) it > happens frequently that no > cell gets highlighted at all (or perhaps the wrong one is highlighted > but not visible at > the current scroll position) > > - Cells are sometimes a pixel different in height > > Haven't been able to find a pattern to this yet, it happens with the > default cell renderer > when it is styled with some fancy borders. Very noticable when > holding cursor down because > the borders jitter (create a border with an inset of 1 or 2 pixels so > there should be a fixed > gap between the cells, the gap will sometimes be a pixel larger than > usual). > > It doesn't seem to be content related as a cell that is a pixel too > large in the upper half > of the ListView can appear regular size in the bottom half of the > ListView. > > .... > > There are probably more I forgot to list or already worked around and > forgot about (I seem > to remember constructing a ListView, not adding it to Scene, but > populating it and selecting > an item and calling scrollTo, and THEN adding it to the Scene works > very poorly as well). > > Anyway... I'm a bit worried that fixes for these are now over a year > away... I don't really need > much (just a scrollbar, some same height, same width custom cells, > nicely stacked on top of each > other reacting to cursor input) but I just keep running into above > problems during normal use > of the app. > > Can I help get these debugged or am I on my own? > > --John > From lubomir.nerad at oracle.com Tue Jul 10 06:55:24 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Tue, 10 Jul 2012 15:55:24 +0200 Subject: Image loading error reporting / handling In-Reply-To: <2D915C8A-7F4A-49FC-94E0-A46E5D1F63E7@oracle.com> References: <4FE9D2B0.90609@oracle.com> <4FE9F207.6050006@geomatys.fr> <411E73D23DEC4C46BA48F2B6D8BF3D2215FCA51236@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <4FEB2BDF.50009@oracle.com> <2D915C8A-7F4A-49FC-94E0-A46E5D1F63E7@oracle.com> Message-ID: <4FFC344C.60604@oracle.com> Hi Richard, On 7/2/2012 4:47 PM, Richard Bair wrote: > I was also wondering if we shouldn't reuse the Worker API for this. For what exactly? Having Image.getLoadWorker can only partially satisfy RT-17645 and doesn't add on* handlers requested in RT-976. It is almost complementary to ImageLoader. > However I have another question as well, which is how does ImageLoader work in a declarative environment, such as FXML? ImageLoader doesn't remove the possibility to create images through Image constructors, so FXML will still have that possibility. If we want to make ImageLoader usable from FXML, we can always add an additional Image constructor with an ImageLoader parameter. This will specify which ImageLoader to use to load that particular Image. Then one can create an instance of ImageLoader in the "fx:define" section (can attach event handlers to it there) and then reference it from the defined scene graph through its "fx:id". Alternatively if we don't need that level of control, we can allow to define a default ImageLoader for a FXMLLoader or event to define it for the whole FX platform (Platfom.setImageLoader?). But this might introduce unwanted dependencies. > It seems like having Image have a getLoadWorker() would be better in that it would (a) be consistent with web engine, (b) present a consistent API with the other places where we do background monitoring / loading work I am not against introducing Image.getLoadWorker. But how do we address the duplicated properties it will create? Image.progress vs Image.loadWorker.progress Image.cancel vs Image.loadWorker.cancel Image.error vs Image.loadWorker.state Would you allow deprecation in this case? > and (c) could be used declaratively. > How? I tried to use web engine load worker in FXML and was quite unsuccessful with it. First I don't know how to attach a property listener to a property declaratively in FXML and even if that is possible somehow, how to dereference WebView.engine and the WebEngine.loadWorker. The only way which seemed promising was to use the properties of load worker in expression bindings, but that tried to access the properties through the internal WebEngine.LoadWorker class instead of the public Worker interface and so it ended with an Exception (FXML bug?). > Which is not to say that having an ImageLoader wouldn't be nice (especially if it means we can make what is now a private implementation public rather than adding a new class), but I don't think it is sufficient since it would require procedural programming. > > Richard > Lubo > On Jun 27, 2012, at 8:50 AM, Lubomir Nerad wrote: > >> Hi John, >> >> good question, but I don't think it will be useful in this case. Worker interface is more suitable to track loading of a single Image and most of the information available through that interface is already provided by the Image class. Or we can try to define ImageLoader as a javafx.concurrent.Service, but in that case we would inherit some unwanted methods and loose the possibility to attach some additional information to the reported events. >> >> Thanks, >> Lubo >> >> On 6/27/2012 2:19 AM, John Smith wrote: >>> Could (or should) a Worker interface be used as the API to monitor and control Image loading - similar to how webEngine.getLoadWorker() can be used to monitor and control web page loading? >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Martin Desruisseaux >>> Sent: Tuesday, June 26, 2012 10:32 AM >>> To: openjfx-dev at openjdk.java.net >>> Subject: Re: Image loading error reporting / handling >>> >>> One advantage that I see with the proposed ImageLoader class would be >>> its similarity with javax.imageio.ImageWriter, which may make easier to >>> write adapters for interoperability between the two frameworks. >>> >>> Martin >>> >>> >>> Le 26/06/12 17:18, Lubomir Nerad a ?crit : >>>> Hi all, >>>> >>>> I have two feature requests which ask for better error reporting / >>>> handling of image loading. >>>> >>>> The issues are: >>>> >>>> Make Image class support exceptions for both asynchronous and >>>> synchronous loading >>>> (http://javafx-jira.kenai.com/browse/RT-17645) >>>> Image/Media need consistent error reporting >>>> (http://javafx-jira.kenai.com/browse/RT-976) >>>> >>>> Currently my idea of fixing them is through a new ImageLoader class. >>>> >>>> This class will have two sets of instance methods for image loading: >>>> >>>> Image load(...) - Used for foreground image loading. The difference >>>> between them and the Image constructors would be that by default (!) >>>> they will throw an exception if image loading fails [RT-17645] >>>> (instead of returning an Image with error set to true). >>>> >>>> Image loadAsync(...) - Used for background image loading. Will throw >>>> only when input arguments are null or invalid. >>>> >>>> Then there will be methods for registering image loading event >>>> handlers [RT-976]. I can think of the following basic set of events: >>>> >>>> loading started (setOnLoadingStarted) >>>> loading progress (setOnLoadingProgress) >>>> loading finished >>>> loading succeeded (setOnLoadingSucceeded) >>>> loading failed (setOnLoadingFailed) >>>> >>>> They will use a new ImageLoadingEvent and possibly >>>> ImageLoadingFailedEvent (with an added exception field). The >>>> ImageLoadingEvent will report the image for which the event has been >>>> generated (null for foreground images?). >>>> >>>> Image loading errors will be reported as runtime (!) >>>> ImageLoadingException-s. >>>> >>>> ImageLoader instances will be created through constructor(s) with >>>> possibility to pass some configuration parameters (for example the >>>> maximum number of images being loaded at the same time). >>>> >>>> For "logging only" image loaders we might want to allow to configure >>>> (constructor parameter? loadingFailedEvent.consume()?) whether the >>>> load methods will throw ImageLoadingException or merely create Images >>>> with error flags set (as is the case of Image constructors). >>>> >>>> This is just a basic outline of my proposal. We can focus on details >>>> when/if this approach is accepted. Alternatively the issues could be >>>> fixed by additional properties / methods on Image class. I didn't like >>>> it, because the added properties would be useful only during short >>>> period of the whole image lifetime and absolutely unusable for some >>>> images (images created from scratch). I also think that the >>>> ImageLoader approach makes uniform error handling of image loading >>>> easier (one handler for several images instead of one handler per image). >>>> >>>> What is your preference / opinion about this? >>>> >>>> Thanks, >>>> Lubo >>>> From hang.vo at oracle.com Tue Jul 10 07:04:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Jul 2012 14:04:26 +0000 Subject: hg: openjfx/2.2/graphics/rt: 25 new changesets Message-ID: <20120710140449.4CF0647EF5@hg.openjdk.java.net> Changeset: 7f0d5537b52a Author: mfang Date: 2012-06-29 21:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7f0d5537b52a RT-23080: NLS: javafx2.2 message drop 20 integration ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_de.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_es.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_fr.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_it.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ja.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ko.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_pt_BR.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_sv.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_CN.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_TW.properties Changeset: bc2e7244d877 Author: igor Date: 2012-07-03 16:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/bc2e7244d877 Merge Changeset: 554e78523bab Author: hudson Date: 2012-07-05 12:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/554e78523bab Added tag 2.2-b16 for changeset bc2e7244d877 ! .hgtags Changeset: 9bcfd0822e48 Author: David Grieve Date: 2012-07-03 14:35 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9bcfd0822e48 RT-22559: address isUserSetProperty and getAllPseudoClassStates causing bottleneck in StyleHelper.transitionToState ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.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/Scene.java Changeset: c74fc98bb9d4 Author: jgiles Date: 2012-07-03 12:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c74fc98bb9d4 RT-23008: TextFieldListCell throws NPE on Enter ! javafx-ui-controls/src/javafx/scene/control/cell/CellUtils.java Changeset: 587765f2009d Author: jgiles Date: 2012-07-03 12:22 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/587765f2009d [DOC ONLY] RT-23154: TextField Cells Javadoc doesn't specify clearly that StringConverter has to be set for them to work ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: e26d0e3bfcb3 Author: jgiles Date: 2012-07-03 15:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e26d0e3bfcb3 [DOC ONLY] RT-22874: CheckBoxTreeItem: javadoc is incomplete ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java Changeset: ea0e80ad3933 Author: jgiles Date: 2012-07-04 07:36 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ea0e80ad3933 [DOC ONLY] Fixes for a number of JavaDoc errors and warnings. ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/MapValueFactory.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: b06e3fb7dd1a Author: jgiles Date: 2012-07-04 07:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b06e3fb7dd1a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 53c9087d14fb Author: Kinsley Wong Date: 2012-07-03 13:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/53c9087d14fb RT-22929 [Not bug court approved pushing so qa and can run tests] SplitPane: issue with position setting ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java Changeset: 279dc6b31ebd Author: David Grieve Date: 2012-07-03 20:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/279dc6b31ebd RT-22076: reinsert patch ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: 907808cece4e Author: Kinsley Wong Date: 2012-07-05 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/907808cece4e RT-22866 Pagination control does not handle swipe gesture events. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 9d0660e793f6 Author: Kinsley Wong Date: 2012-07-05 11:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9d0660e793f6 RT-23084: Calling "setSelected(true)" on CheckBox fires ActionEvent. ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java Changeset: d48861b45651 Author: Kinsley Wong Date: 2012-07-05 13:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d48861b45651 RT-23063: Nested SplitPand rendering issue. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java Changeset: 330911490952 Author: jgiles Date: 2012-07-09 10:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/330911490952 RT-21684: TableView with hidden/invisible columns: resizing of columns gets confused ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: e3ddeb5fe157 Author: jgiles Date: 2012-07-09 10:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e3ddeb5fe157 RT-23067: AIOOBE when expand one of selected nodes in TreeView ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: 2e3e8a90f8c0 Author: jgiles Date: 2012-07-09 16:49 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2e3e8a90f8c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 0122996d25d3 Author: David Grieve Date: 2012-07-09 12:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0122996d25d3 RT-22076: backout patch. Fix deferred to 3.0 ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: 5b3e02e4f23b Author: David Grieve Date: 2012-07-09 12:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/5b3e02e4f23b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: a88de67241de Author: David Grieve Date: 2012-07-09 12:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a88de67241de RT-21594: If the style cache for a node is null, then tell the node to reapply CSS because the StyleHelper is no good in this case. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 18f3884957e7 Author: David Grieve Date: 2012-07-09 12:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/18f3884957e7 RT-23184: adding same UA stylesheet should not cause styles to be obliterated ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: f3bb020babab Author: mickf Date: 2012-07-09 18:12 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f3bb020babab RT-23033 : Label with setFocusTraversable(true) breaks focus traversing ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: a8bd152f64ad Author: mickf Date: 2012-07-09 18:17 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a8bd152f64ad RT-20222 : Ensemble - Controls on the right side are not reachable via keyboard ! javafx-ui-common/src/com/sun/javafx/scene/traversal/ContainerTabOrder.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java Changeset: 1eadff96bc2b Author: Kinsley Wong Date: 2012-07-09 13:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1eadff96bc2b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 1d8c6251f243 Author: kcr Date: 2012-07-10 06:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1d8c6251f243 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt From pavel.safrata at oracle.com Tue Jul 10 07:50:12 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 10 Jul 2012 16:50:12 +0200 Subject: Color.toWeb & Color.toHexString Message-ID: <4FFC4124.6040207@oracle.com> Hello, based on Jira issue http://javafx-jira.kenai.com/browse/RT-22400 I propose the following new methods to Color class (targeting Lombard): public String toWeb() This method will return the simplest string representation of the color using one of the following notations: #rrggbb rgb(r, g, b) rgba(r, g, b, a) The resulting string, when passed to Color.toWeb(), will produce an eqivalent color. public String toHexString() This method will return a string rrggbb without the leading hash. It will ignore opacity and will round the values to the nearest color that can be represented with such string. An example of use is displaying a web-based color value in a color picker. Regards, Pavel From pavel.safrata at oracle.com Tue Jul 10 08:00:14 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 10 Jul 2012 17:00:14 +0200 Subject: Affine transforms - matrix algebra Message-ID: <4FFC437E.2070505@oracle.com> Hello, based on previous discussions, we're going to propose a set of new methods to our transforms. Tracking Jira issue: http://javafx-jira.kenai.com/browse/RT-17942 I hope the names are self-explanatory, otherwise please let me know and I'll provide some description. On Transform class: public Transform getConcatenation(Transform transform) // multiplication public Transform getInverse() throws NoninvertibleTransformException // negation public Transform copy() Note: in subclasses these methods will be overridden and will return more specific types where possible. On Affine class: Constructors: public Affine(Transform transform) public Affine(double mxx, double mxy, double mxz, double tx, double myx, double myy, double myz, double ty, double mzx, double mzy, double mzz, double tz) Setters of the entire matrix: public void setToTransform(Transform t) public void setToTransform(double mxx, double mxy, double mxz, double mxt, double myx, double myy, double myz, double myt, double mzx, double mzy, double mzz, double mzt) public void setToIdentity() public void setToTranslation(double tx, double ty) public void setToTranslation(double tx, double ty, double tz) public void setToScale(double sx, double sy) public void setToScale(double sx, double sy, double pivotX, double pivotY) public void setToScale(double sx, double sy, double sz) public void setToScale(double sx, double sy, double sz, double pivotX, double pivotY, double pivotZ) public void setToRotation(double theta) public void setToRotation(double theta, double pivotX, double pivotY) public void setToRotation(double theta, double axisX, double axisY, double axisZ, double pivotX, double pivotY, double pivotZ) public void setToShear(double shx, double shy) public void setToShear(double shx, double shy, double pivotX, double pivotY) Operations on the matrix (modifying it in place): public void invert() throws NoninvertibleTransformException public void concatenate(Transform t) public void concatenate(double Txx, double Txy, double Txz, double Txt, double Tyx, double Tyy, double Tyz, double Tyt, double Tzx, double Tzy, double Tzz, double Tzt) public void preConcatenate(Transform t) // left multiplication public void preConcatenate(double Txx, double Txy, double Txz, double Txt, double Tyx, double Tyy, double Tyz, double Tyt, double Tzx, double Tzy, double Tzz, double Tzt) public void concatWithTranslation(double tx, double ty) public void concatWithTranslation(double tx, double ty, double tz) public void concatWithScale(double sx, double sy) public void concatWithScale(double sx, double sy, double pivotX, double pivotY) public void concatWithScale(double sx, double sy, double sz) public void concatWithScale(double sx, double sy, double sz, double pivotX, double pivotY, double pivotZ) public void concatWithRotation(double theta) public void concatWithRotation(double theta, double pivotX, double pivotY) public void concatWithRotation(double theta, double axisX, double axisY, double axisZ, double pivotX, double pivotY, double pivotZ) public void concatWithShear(double shx, double shy) public void concatWithShear(double shx, double shy, double pivotX, double pivotY) public void preTranslate(double mxt, double myt) public void preTranslate(double mxt, double myt, double mzt) Other methods: public double getDeterminant() Notes: Instead of "concatWithTranslation" it would be more natural to use just "translate" (and similarly for the others), but unfortunately these method names are already taken by the static factory methods on Transform class. This is unpleasant but we need to be backward compatible so we have to introduce different names. We'll be happy to hear better naming suggestions than the concatWith* (which is pretty descriptive I think but not really nice). To avoid even bigger method explosion this proposal doesn't contain all the convenience "preConcatWith*" methods. However, we added preTranslate, because it is needed quite often (and preConcatWithTranslation looks quite horrible). Any comments to that? Should rotation axis be passed as Point3D (rather than the three doubles), consistently with Rotate transform? Would you want static factory methods on Affine (creating Affine instances with the simple transforms)? Would it be important to you whether or not matrix changes are atomic? If you call one of the methods that modify the entire matrix, can be listeners for each member called immediately as the members are set, or do they need to be called after all the members are updated? Any missing operations? Thanks, Pavel From richard.bair at oracle.com Tue Jul 10 09:27:33 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 10 Jul 2012 09:27:33 -0700 Subject: Color.toWeb & Color.toHexString In-Reply-To: <4FFC4124.6040207@oracle.com> References: <4FFC4124.6040207@oracle.com> Message-ID: Hi Pavel, On Jul 10, 2012, at 7:50 AM, Pavel Safrata wrote: > Hello, > based on Jira issue > http://javafx-jira.kenai.com/browse/RT-22400 > I propose the following new methods to Color class (targeting Lombard): > > > public String toWeb() > > This method will return the simplest string representation of the color using one of the following notations: > > #rrggbb > rgb(r, g, b) > rgba(r, g, b, a) > > The resulting string, when passed to Color.toWeb(), will produce an eqivalent color. I like the idea that color.equals(Color.web(color.toWeb())). How do we determine which format is going to be returned by toWeb? I think it should be consistent (ie: pick one to use all the time). Otherwise it becomes arbitrary and folks cannot easily parse the results or do what they need with it. > public String toHexString() > > This method will return a string rrggbb without the leading hash. It will ignore opacity and will round the values to the nearest color that can be represented with such string. An example of use is displaying a web-based color value in a color picker. Why remove the #? What is the use case for toHexString()? Richard From martin.desruisseaux at geomatys.fr Tue Jul 10 09:36:18 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 10 Jul 2012 18:36:18 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFC437E.2070505@oracle.com> References: <4FFC437E.2070505@oracle.com> Message-ID: <4FFC5A02.8040709@geomatys.fr> Hello Pavel Many thanks for taking care of this task! Le 10/07/12 17:00, Pavel Safrata a ?crit : > On Transform class: > public Transform getConcatenation(Transform transform) // > multiplication > public Transform getInverse() throws > NoninvertibleTransformException // negation > public Transform copy() Sound fine to me, while I'm not sure why a 'copy' method instead than overriding the 'clone()' method? > Constructors: > public Affine(Transform transform) > public Affine(double mxx, double mxy, double mxz, double tx, > double myx, double myy, double myz, double ty, > double mzx, double mzy, double mzz, double tz) Look fine. > Setters of the entire matrix: > (...snip...) I don't know for JavaFX, but in my experience with Java2D, I wasn't using the setter methods often, except 'setToIdentity' and 'setToTransform'. For example rather than invoking 'setToTranslation', I strongly push our developers to use 'translate' (or 'concatWithTranslation' in this proposal) instead. If a developer really wants the functionality of 'setToTranslation', he can get it by invoking 'setToIdentity()' followed by 'concatWithTranslation'. Or yet better, 'setToTransform(...)' instead than 'setToIdentity' with the coefficients of some previous state that the user saved. The rational is that in many cases, the affine transform is already initialized to some important value. For example in Java2D, AffineTransform is initialized to the transform from 'dot' to whatever units the underlying device uses. When rendering on screen, this is the identity transform. But when printing, this is something different that depends on the printer resolution. In GIS applications, it depends on the zoom level. Other applications may use magnifier glass over some areas. Because the initial transform is often (but not always) the identity one, developers with limited experience with affine transforms often use 'setTranslate' or 'setScale' in situations where they should really use 'translate' or 'scale', and do not realize their bug before late in the development process. For this reason, I would be inclined to discourage every setter methods except 'setToIdentity()' and 'setToTransform'. Keeping in mind that it is often easier to fill a hole later than to fix something broken, I think it would be safer to leave out all other setter methods for now, and revisit later if experience show that they are really needed. > Operations on the matrix (modifying it in place): > (...snip...) Sound good, minus the unfortunate 'concatWith*' naming :-(. > Instead of "concatWithTranslation" it would be more natural to use > just "translate" (and similarly for the others), but unfortunately > these method names are already taken by the static factory methods on > Transform class. This is unpleasant but we need to be backward > compatible so we have to introduce different names. We'll be happy to > hear better naming suggestions than the concatWith* (which is pretty > descriptive I think but not really nice). Hard to say... A consistency with "preTranslate" would be nice, but "postTranslate" doesn't look very nice... What about the following? * Rename "preTranslate" as "appendTranslation" * Rename "concatWithTranslation" as "prependTranslation" The "preConcatenate(Tx)" name in Java2D was actually misleading to some developers, because it works as if points were first transformed by the original transform, then transformed by 'Tx'. Maybe "appendTranslation(Tx)" would make clear that the translation is applied after the original transform. This would also make operation order clearer. The following code using Java2D API: tr.translate(...) tr.scale(...) tr.rotate(...) must be read from bottom to up: it is as if points were rotated first, then scaled, then translated. So maybe the above proposition would make that more obvious: tr.prependTranslation(....) tr.prependScale(...) tr.prependRotate(...) tr.appendTranslation(...) // Just for fun. > Would you want static factory methods on Affine (creating Affine > instances with the simple transforms)? I don't think it is necessary. I found the static factory methods of Java2D AffineTransform rarely used. > Would it be important to you whether or not matrix changes are atomic? > If you call one of the methods that modify the entire matrix, can be > listeners for each member called immediately as the members are set, > or do they need to be called after all the members are updated? I don't have experience in this area. But naively, it seems to we that it would be better to be notified only after the full matrix has been updated... Regards, Martin From pavel.safrata at oracle.com Tue Jul 10 09:53:57 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 10 Jul 2012 18:53:57 +0200 Subject: Color.toWeb & Color.toHexString In-Reply-To: References: <4FFC4124.6040207@oracle.com> Message-ID: <4FFC5E25.7000403@oracle.com> Hi Richard, On 10.7.2012 18:27, Richard Bair wrote: > Hi Pavel, > > On Jul 10, 2012, at 7:50 AM, Pavel Safrata wrote: > >> Hello, >> based on Jira issue >> http://javafx-jira.kenai.com/browse/RT-22400 >> I propose the following new methods to Color class (targeting Lombard): >> >> >> public String toWeb() >> >> This method will return the simplest string representation of the color using one of the following notations: >> >> #rrggbb >> rgb(r, g, b) >> rgba(r, g, b, a) >> >> The resulting string, when passed to Color.toWeb(), will produce an eqivalent color. > I like the idea that color.equals(Color.web(color.toWeb())). I think this is a must. > > How do we determine which format is going to be returned by toWeb? I think it should be consistent (ie: pick one to use all the time). Otherwise it becomes arbitrary and folks cannot easily parse the results or do what they need with it. We use the simplest possible format. If all the components are integers and the color is fully opaque, we can use the classic #rrggbb format. If the values need decimal numbers, we need to use rgb(r%, g%, b%). If the opacity is non-one, we need rgba(r, g, b, a) in case of integers and rgba(r%, g%, b%, a) in case of decimals. The only format that can accommodate all possible colors is the last one. We can use it always, just to me Color.ANTIQUEWHITE.toWeb() = "#FAEBD7" looks more natural than Color.ANTIQUEWHITE.toWeb() = "rgba(98.039215%,92.15686%,84.31373%,1.0)" If you use the predefined colors, you can always do with the simple format and you don't need to deal with the CSS3 complex formats. Who's going to parse it? I think that either our Color or some web engine. Both can parse all the formats. The result of the simple colors would be parseable also by old CSS engines, so it has the advantage of backward compatibility for basic colors. Another considerable advantage is much better human readability for the simple colors. I'm not firmly opposed to your suggestion but those are my reasons that make me like the varying results better. What do you think? > >> public String toHexString() >> >> This method will return a string rrggbb without the leading hash. It will ignore opacity and will round the values to the nearest color that can be represented with such string. An example of use is displaying a web-based color value in a color picker. > Why remove the #? What is the use case for toHexString()? I did mention the use-case: "displaying a web-based color value in a color picker". If it's displayed in an editable field, you usually don't want the hash there. Moreover, strictly speaking, a string beginning with hash is not really a hex string, so in this case we should use a different name (something like toNearestSimpleWebColor). Thanks, Pavel > > Richard From hjohn at xs4all.nl Tue Jul 10 10:38:23 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 10 Jul 2012 19:38:23 +0200 Subject: Little worried about the ListView/TreeView/TableView classes In-Reply-To: <4FFB6313.8000303@oracle.com> References: <4FFB6081.3090300@xs4all.nl> <4FFB6313.8000303@oracle.com> Message-ID: <4FFC688F.4020209@xs4all.nl> Hi Jonathan, I'll do what can to help get some of these resolved, so I have filed three new issues (all using the same sample code), RT-23331, RT-23332 and RT-23333 which address three of the problems below. Some of the others I already created issues for, the most critical of those (causing graphics glitches) is a solution for this one: RT-22555 Unpredictable behaviour with scrollTo and the view classes (TableView as example) It causes rendering to fail -- for Scenes that are fairly static this can mean some controls are simply invisible until the user tries interacting with them. The provided sample is brute-force code to get this to occur, but it happens in normal use of my app (especially when only layout is changed and some controls are swapped out, ie, a TreeView becomes a TableView to show items in 2 columns -- in those cases all data is loaded already and the change can happen very fast -- when more processing still needs to occur (like images being loaded causing item changes) it doesn't happen.. or it simple hides the problem because of a redraw occuring). Then there several issues dealing with Cell creation: RT-22946 TreeView creates cells for every item from start to scrollTo position RT-20892 Layout pass of TreeView can result in unneccessary recreation of TreeCells RT-20616 TreeView creates new cells every time root is changed The first one is the most problematic because it creates lots of cells but more importantly.. *different* cells. The other two are less of a problem since atleast they donot cause data to be accessed that is not going to be displayed. The issue with creation of a ListView and using it immediately (with select/focus/scrollTo calls) is captured a bit in RT-22555 as well I think, resolving that will probably resolve these issues as well. And there's two minor issues I filed related to these classes as well: RT-20879 After setting new root on TreeView, focus model's focused item property is not updated RT-22398 Some navigation keys (pg-down/up, etc) donot work until TreeView/ListView/TableView item has both focus AND is selected For some of these it is rather hard to create good small test programs -- there appear to be timing issues with some of them (whether the ListView has already been rendered atleast once or not yet, and/or whether it was added to a Scene or not). Sometimes putting things like select/focus/scrollTo in a Platform.runLater() makes the issue worse or better. I can provide help in the form of trying to write test cases for problems that you cannot reproduce at all. The three most annoying bugs are: RT-22555 (causes graphic glitches) RT-22946 (makes large lists slow to display when scrolling to a high index in the list when restoring last cursor position) RT-23331 (graphics glitch where user cannot see the highlighted item) The rest are annoying but only waste some resources or are minor gfx glitches or have work-arounds. If there is anything I can do to make these easier to solve, I can work on that in the weekend/evenings. I'll upgrade to the latest beta tonight to see if any of them happened to have been resolved. --John On 10/07/2012 01:02, Jonathan Giles wrote: > I'm happy to help work through these issues to try to find fixes > (which may be able to get into 2.2) or find workarounds, although it > is probably easier to have a discussion on each of the jira issue > pages, rather than grouped together in an email (both for ease of > discussion, and so we can have a record of what was said). > > Chances are all these bugs are already assigned to me. If so, lets > start working through these right away. If not, email me the bug > report numbers and I'll add myself as a watcher (or take ownership of > them as they are likely my bugs anyway). > > -- Jonathan > > On 10/07/2012 10:51 a.m., John Hendrikx wrote: >> My program relies extensively on the *View classes, however, there >> are numerous little problems with these (JavaFX 2.2b13) that I'm >> considering rewriting these controls myself to "take control" and >> being able to fix problems. >> >> Many of the issues I've reported as bugs, which are all in the >> process of being deferred to JFX3.0 (if I understand correctly), >> which is scheduled for over a year from now. >> >> Here is a list of problems I've been running into just this past week >> -- and I've reported several others. Most of these apply to any of >> the *View classes, but some may be specific to one of the types. >> >> - Calling requestFocus() behaves differently from clicking with >> mouse/tabbing when >> using only keyboard navigation: >> >> Left Mouse Click: >> Current focusowner : VirtualFlow[id=virtual-flow, styleClass=] >> Current focusowner : ListView[id=null, styleClass=list-view] >> >> Tabbing to it: >> Current focusowner : ListView[id=null, styleClass=list-view] >> >> Programmatic requestFocus() immediately after ListView added to Scene: >> Current focusowner : ListView at 1966198[styleClass=list-view] >> >> Why is it not the same? This seems to be causing issues sometimes >> where the ListView >> is not properly activated and it is not accepting keyboard input >> (despite being the >> focusowner as printed above). >> >> - Sometimes ListView starts highlighting every Xth cell when >> scrolling through list >> >> Scrolling through a ListView using the cursor keys one can get the >> ListView stuck to >> highlighting only the Xth cell (where X seems to be in the range of >> the number of active >> Cells). When there is only few items in the list this bug manifests >> itself as not >> changing the focus of the item at all (ie, the wrong cell is >> highlighted). Usually a >> mouse click on a random item fixes this bug again, but sometimes even >> that doesn't work. >> >> This bug is incredibly hard to reproduce but the frequency of it can >> be increased >> by using a ScrollBar Skin that breaks the rule that getNode() should >> always return the >> same item. It however happens with the default ScrollBar Skin as >> well, just much much >> rarer. I have a test case with a contract-breaking ScrollBar Skin >> that manages to >> reproduce it almost every time. >> >> - Page up broken when used at bottom of ListView >> >> Scroll down fully with page down. Now page up, notice that it goes >> up one page, but the >> next page up only goes up one item for a few times (about a page >> worth of items) before >> starting to act like a real page up again. >> >> - Pressing Cursor Left/Right on an active ListView changes focus >> despite keys being consumed >> >> Despite having a handler in setOnKeyPressed that consumes the Cursor >> keys (to do something >> useful with them) the focus still also changes (ie, it triggers my >> action AND affects >> a focus change). I can block them with an EventFilter, but would >> rather allow users of >> my custom control to still being able to register these keys for >> special purposes... >> >> - Numerous scrollTo bugs >> >> Poor centering when scrolling to an item (sometimes even outside view >> port); not responding >> at all when called at inoppertune times (right after populating and >> adding to scene); unable >> to precisely save/restore view position; creating cells for every >> item from 0 to item being >> scrolled to... and recently (since 2.2betas) completely failure to >> draw the ListView at all >> (can take various forms, only scrollbars drawn, somtimes the entire >> container is missing). >> Restores itself on any ListView redrawing activity, like selecting >> cell, scrolling with cursor >> keys, etc.. >> >> - Numerous focus/select bugs >> >> Similar to above, when these things occur in rapid succession >> (ListView added to Scene, >> populated, correct item selected, scrolled to saved position) it >> happens frequently that no >> cell gets highlighted at all (or perhaps the wrong one is highlighted >> but not visible at >> the current scroll position) >> >> - Cells are sometimes a pixel different in height >> >> Haven't been able to find a pattern to this yet, it happens with the >> default cell renderer >> when it is styled with some fancy borders. Very noticable when >> holding cursor down because >> the borders jitter (create a border with an inset of 1 or 2 pixels so >> there should be a fixed >> gap between the cells, the gap will sometimes be a pixel larger than >> usual). >> >> It doesn't seem to be content related as a cell that is a pixel too >> large in the upper half >> of the ListView can appear regular size in the bottom half of the >> ListView. >> >> .... >> >> There are probably more I forgot to list or already worked around and >> forgot about (I seem >> to remember constructing a ListView, not adding it to Scene, but >> populating it and selecting >> an item and calling scrollTo, and THEN adding it to the Scene works >> very poorly as well). >> >> Anyway... I'm a bit worried that fixes for these are now over a year >> away... I don't really need >> much (just a scrollbar, some same height, same width custom cells, >> nicely stacked on top of each >> other reacting to cursor input) but I just keep running into above >> problems during normal use >> of the app. >> >> Can I help get these debugged or am I on my own? >> >> --John >> > > From christian.schudt at gmx.de Tue Jul 10 11:57:25 2012 From: christian.schudt at gmx.de (Christian Schudt) Date: Tue, 10 Jul 2012 20:57:25 +0200 Subject: Little worried about the ListView/TreeView/TableView classes In-Reply-To: <4FFB6081.3090300@xs4all.nl> References: <4FFB6081.3090300@xs4all.nl> Message-ID: John, I share your worries. During the last two months I reported 13 bugs. 5 of these were targeted for Lombard, 6 are still unscheduled and only 2 were scheduled for 2.2. Generally speaking I got the impression, that there are more important issues, as can be also seen here in the last comment: http://javafx-jira.kenai.com/browse/RT-20616 (which is already Priority Major) I don't know what these priorities are, but in my opinion fixing bugs and stabilizing existing code, should be high priority for a new release, especially if they are a regression from a prior version, like this one: http://javafx-jira.kenai.com/browse/RT-21936 (worked in 2.1 beta and is now targeted for Lombard, too) I would appreciate, if the JavaFX Team let the community know, what these priorities for 2.2 are and when it is supposed to be released. Have you (Oracle?) considered to release further minor 2.x releases until JavaFX 3.0? I worry, that 2.2 won't be stable enough to work with until Q3 2013. Best regards, Christian Am 10.07.2012 um 00:51 schrieb John Hendrikx: > My program relies extensively on the *View classes, however, there are numerous little problems with these (JavaFX 2.2b13) that I'm considering rewriting these controls myself to "take control" and being able to fix problems. > > Many of the issues I've reported as bugs, which are all in the process of being deferred to JFX3.0 (if I understand correctly), which is scheduled for over a year from now. > > Here is a list of problems I've been running into just this past week -- and I've reported several others. Most of these apply to any of the *View classes, but some may be specific to one of the types. > > - Calling requestFocus() behaves differently from clicking with mouse/tabbing when > using only keyboard navigation: > > Left Mouse Click: > Current focusowner : VirtualFlow[id=virtual-flow, styleClass=] > Current focusowner : ListView[id=null, styleClass=list-view] > > Tabbing to it: > Current focusowner : ListView[id=null, styleClass=list-view] > > Programmatic requestFocus() immediately after ListView added to Scene: > Current focusowner : ListView at 1966198[styleClass=list-view] > > Why is it not the same? This seems to be causing issues sometimes where the ListView > is not properly activated and it is not accepting keyboard input (despite being the > focusowner as printed above). > > - Sometimes ListView starts highlighting every Xth cell when scrolling through list > > Scrolling through a ListView using the cursor keys one can get the ListView stuck to > highlighting only the Xth cell (where X seems to be in the range of the number of active > Cells). When there is only few items in the list this bug manifests itself as not > changing the focus of the item at all (ie, the wrong cell is highlighted). Usually a > mouse click on a random item fixes this bug again, but sometimes even that doesn't work. > > This bug is incredibly hard to reproduce but the frequency of it can be increased > by using a ScrollBar Skin that breaks the rule that getNode() should always return the > same item. It however happens with the default ScrollBar Skin as well, just much much > rarer. I have a test case with a contract-breaking ScrollBar Skin that manages to > reproduce it almost every time. > > - Page up broken when used at bottom of ListView > > Scroll down fully with page down. Now page up, notice that it goes up one page, but the > next page up only goes up one item for a few times (about a page worth of items) before > starting to act like a real page up again. > > - Pressing Cursor Left/Right on an active ListView changes focus despite keys being consumed > > Despite having a handler in setOnKeyPressed that consumes the Cursor keys (to do something > useful with them) the focus still also changes (ie, it triggers my action AND affects > a focus change). I can block them with an EventFilter, but would rather allow users of > my custom control to still being able to register these keys for special purposes... > > - Numerous scrollTo bugs > > Poor centering when scrolling to an item (sometimes even outside view port); not responding > at all when called at inoppertune times (right after populating and adding to scene); unable > to precisely save/restore view position; creating cells for every item from 0 to item being > scrolled to... and recently (since 2.2betas) completely failure to draw the ListView at all > (can take various forms, only scrollbars drawn, somtimes the entire container is missing). > Restores itself on any ListView redrawing activity, like selecting cell, scrolling with cursor > keys, etc.. > > - Numerous focus/select bugs > > Similar to above, when these things occur in rapid succession (ListView added to Scene, > populated, correct item selected, scrolled to saved position) it happens frequently that no > cell gets highlighted at all (or perhaps the wrong one is highlighted but not visible at > the current scroll position) > > - Cells are sometimes a pixel different in height > > Haven't been able to find a pattern to this yet, it happens with the default cell renderer > when it is styled with some fancy borders. Very noticable when holding cursor down because > the borders jitter (create a border with an inset of 1 or 2 pixels so there should be a fixed > gap between the cells, the gap will sometimes be a pixel larger than usual). > > It doesn't seem to be content related as a cell that is a pixel too large in the upper half > of the ListView can appear regular size in the bottom half of the ListView. > > .... > > There are probably more I forgot to list or already worked around and forgot about (I seem > to remember constructing a ListView, not adding it to Scene, but populating it and selecting > an item and calling scrollTo, and THEN adding it to the Scene works very poorly as well). > > Anyway... I'm a bit worried that fixes for these are now over a year away... I don't really need > much (just a scrollbar, some same height, same width custom cells, nicely stacked on top of each > other reacting to cursor input) but I just keep running into above problems during normal use > of the app. > > Can I help get these debugged or am I on my own? > > --John > From jonathan.giles at oracle.com Tue Jul 10 12:55:18 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 11 Jul 2012 07:55:18 +1200 Subject: Little worried about the ListView/TreeView/TableView classes In-Reply-To: <4FFC688F.4020209@xs4all.nl> References: <4FFB6081.3090300@xs4all.nl> <4FFB6313.8000303@oracle.com> <4FFC688F.4020209@xs4all.nl> Message-ID: <4FFC88A6.2050107@oracle.com> Comments inline. -- Jonathan On 11/07/2012 5:38 a.m., John Hendrikx wrote: > Hi Jonathan, > > I'll do what can to help get some of these resolved, so I have filed > three new issues (all using the same sample code), RT-23331, RT-23332 > and RT-23333 which address three of the problems below. Some of the > others I already created issues for, the most critical of those > (causing graphics glitches) is a solution for this one: > > RT-22555 Unpredictable behaviour with scrollTo and the view classes > (TableView as example) > > It causes rendering to fail -- for Scenes that are fairly static this > can mean some controls are simply invisible until the user tries > interacting with them. The provided sample is brute-force code to get > this to occur, but it happens in normal use of my app (especially when > only layout is changed and some controls are swapped out, ie, a > TreeView becomes a TableView to show items in 2 columns -- in those > cases all data is loaded already and the change can happen very fast > -- when more processing still needs to occur (like images being loaded > causing item changes) it doesn't happen.. or it simple hides the > problem because of a redraw occuring). I've noted a simplistic workaround to this problem in the jira issue. Basically, you're trying to modify the state of UI controls before they are in a scene, which is not very well defined. > > Then there several issues dealing with Cell creation: > > RT-22946 TreeView creates cells for every item from start to scrollTo > position > RT-20892 Layout pass of TreeView can result in unneccessary recreation > of TreeCells > RT-20616 TreeView creates new cells every time root is changed > > The first one is the most problematic because it creates lots of cells > but more importantly.. *different* cells. The other two are less of a > problem since atleast they donot cause data to be accessed that is not > going to be displayed. I've definitely got a few performance issues with TreeView/ListView/TableView, but I wasn't about to try and fix them at the end of the 2.2 development cycle (it's just too risky). Instead, I hope to look at these issues very early in the next release cycle. I'm more than happy to work with others on developing fixes via openjfx though! :-) > > The issue with creation of a ListView and using it immediately (with > select/focus/scrollTo calls) is captured a bit in RT-22555 as well I > think, resolving that will probably resolve these issues as well. I'm not too sure whether you're referring to another jira issue here? > > And there's two minor issues I filed related to these classes as well: > > RT-20879 After setting new root on TreeView, focus model's focused > item property is not updated > RT-22398 Some navigation keys (pg-down/up, etc) donot work until > TreeView/ListView/TableView item has both focus AND is selected I've asked for further feedback on these two issues in Jira - I'm awaiting your response. > > For some of these it is rather hard to create good small test programs > -- there appear to be timing issues with some of them (whether the > ListView has already been rendered atleast once or not yet, and/or > whether it was added to a Scene or not). Sometimes putting things like > select/focus/scrollTo in a Platform.runLater() makes the issue worse > or better. Platform.runLater is unfortunately not a solution (as you note). The primary issue really is whether a node is part of a scene before you run operations on it, and whether you're running operations in the JavaFX application thread. > > I can provide help in the form of trying to write test cases for > problems that you cannot reproduce at all. The three most annoying > bugs are: > > RT-22555 (causes graphic glitches) > RT-22946 (makes large lists slow to display when scrolling to a high > index in the list when restoring last cursor position) > RT-23331 (graphics glitch where user cannot see the highlighted item) I've commented about RT-22555. RT-22946 falls into the bucket of perf fixes I hope to do early in the next release cycle. RT-23331 seems to relate to a custom written skin. I would be very interested if there are any issues when using the provided default skins. > > The rest are annoying but only waste some resources or are minor gfx > glitches or have work-arounds. > > If there is anything I can do to make these easier to solve, I can > work on that in the weekend/evenings. I'll upgrade to the latest beta > tonight to see if any of them happened to have been resolved. Another thing you can consider doing is pulling the latest openjfx mercurial repo code and attempting to develop fixes - all the controls source is open. You never know, you might be able to fix some of these bugs :-) > > --John > > On 10/07/2012 01:02, Jonathan Giles wrote: >> I'm happy to help work through these issues to try to find fixes >> (which may be able to get into 2.2) or find workarounds, although it >> is probably easier to have a discussion on each of the jira issue >> pages, rather than grouped together in an email (both for ease of >> discussion, and so we can have a record of what was said). >> >> Chances are all these bugs are already assigned to me. If so, lets >> start working through these right away. If not, email me the bug >> report numbers and I'll add myself as a watcher (or take ownership of >> them as they are likely my bugs anyway). >> >> -- Jonathan >> >> On 10/07/2012 10:51 a.m., John Hendrikx wrote: >>> My program relies extensively on the *View classes, however, there >>> are numerous little problems with these (JavaFX 2.2b13) that I'm >>> considering rewriting these controls myself to "take control" and >>> being able to fix problems. >>> >>> Many of the issues I've reported as bugs, which are all in the >>> process of being deferred to JFX3.0 (if I understand correctly), >>> which is scheduled for over a year from now. >>> >>> Here is a list of problems I've been running into just this past >>> week -- and I've reported several others. Most of these apply to >>> any of the *View classes, but some may be specific to one of the types. >>> >>> - Calling requestFocus() behaves differently from clicking with >>> mouse/tabbing when >>> using only keyboard navigation: >>> >>> Left Mouse Click: >>> Current focusowner : VirtualFlow[id=virtual-flow, styleClass=] >>> Current focusowner : ListView[id=null, styleClass=list-view] >>> >>> Tabbing to it: >>> Current focusowner : ListView[id=null, styleClass=list-view] >>> >>> Programmatic requestFocus() immediately after ListView added to Scene: >>> Current focusowner : ListView at 1966198[styleClass=list-view] >>> >>> Why is it not the same? This seems to be causing issues sometimes >>> where the ListView >>> is not properly activated and it is not accepting keyboard input >>> (despite being the >>> focusowner as printed above). >>> >>> - Sometimes ListView starts highlighting every Xth cell when >>> scrolling through list >>> >>> Scrolling through a ListView using the cursor keys one can get the >>> ListView stuck to >>> highlighting only the Xth cell (where X seems to be in the range of >>> the number of active >>> Cells). When there is only few items in the list this bug manifests >>> itself as not >>> changing the focus of the item at all (ie, the wrong cell is >>> highlighted). Usually a >>> mouse click on a random item fixes this bug again, but sometimes >>> even that doesn't work. >>> >>> This bug is incredibly hard to reproduce but the frequency of it can >>> be increased >>> by using a ScrollBar Skin that breaks the rule that getNode() should >>> always return the >>> same item. It however happens with the default ScrollBar Skin as >>> well, just much much >>> rarer. I have a test case with a contract-breaking ScrollBar Skin >>> that manages to >>> reproduce it almost every time. >>> >>> - Page up broken when used at bottom of ListView >>> >>> Scroll down fully with page down. Now page up, notice that it goes >>> up one page, but the >>> next page up only goes up one item for a few times (about a page >>> worth of items) before >>> starting to act like a real page up again. >>> >>> - Pressing Cursor Left/Right on an active ListView changes focus >>> despite keys being consumed >>> >>> Despite having a handler in setOnKeyPressed that consumes the Cursor >>> keys (to do something >>> useful with them) the focus still also changes (ie, it triggers my >>> action AND affects >>> a focus change). I can block them with an EventFilter, but would >>> rather allow users of >>> my custom control to still being able to register these keys for >>> special purposes... >>> >>> - Numerous scrollTo bugs >>> >>> Poor centering when scrolling to an item (sometimes even outside >>> view port); not responding >>> at all when called at inoppertune times (right after populating and >>> adding to scene); unable >>> to precisely save/restore view position; creating cells for every >>> item from 0 to item being >>> scrolled to... and recently (since 2.2betas) completely failure to >>> draw the ListView at all >>> (can take various forms, only scrollbars drawn, somtimes the entire >>> container is missing). >>> Restores itself on any ListView redrawing activity, like selecting >>> cell, scrolling with cursor >>> keys, etc.. >>> >>> - Numerous focus/select bugs >>> >>> Similar to above, when these things occur in rapid succession >>> (ListView added to Scene, >>> populated, correct item selected, scrolled to saved position) it >>> happens frequently that no >>> cell gets highlighted at all (or perhaps the wrong one is >>> highlighted but not visible at >>> the current scroll position) >>> >>> - Cells are sometimes a pixel different in height >>> >>> Haven't been able to find a pattern to this yet, it happens with the >>> default cell renderer >>> when it is styled with some fancy borders. Very noticable when >>> holding cursor down because >>> the borders jitter (create a border with an inset of 1 or 2 pixels >>> so there should be a fixed >>> gap between the cells, the gap will sometimes be a pixel larger than >>> usual). >>> >>> It doesn't seem to be content related as a cell that is a pixel too >>> large in the upper half >>> of the ListView can appear regular size in the bottom half of the >>> ListView. >>> >>> .... >>> >>> There are probably more I forgot to list or already worked around >>> and forgot about (I seem >>> to remember constructing a ListView, not adding it to Scene, but >>> populating it and selecting >>> an item and calling scrollTo, and THEN adding it to the Scene works >>> very poorly as well). >>> >>> Anyway... I'm a bit worried that fixes for these are now over a year >>> away... I don't really need >>> much (just a scrollbar, some same height, same width custom cells, >>> nicely stacked on top of each >>> other reacting to cursor input) but I just keep running into above >>> problems during normal use >>> of the app. >>> >>> Can I help get these debugged or am I on my own? >>> >>> --John >>> >> >> > From jonathan.giles at oracle.com Tue Jul 10 13:08:21 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 11 Jul 2012 08:08:21 +1200 Subject: Little worried about the ListView/TreeView/TableView classes In-Reply-To: References: <4FFB6081.3090300@xs4all.nl> Message-ID: <4FFC8BB5.9010809@oracle.com> Of course bug fixing is very high priority for us. We try our very best to ship releases with the most critical bugs fixed, and as few of the other level of bug as is possible. The flow of incoming bugs never stops, and sometimes we just have to draw an imaginary line in the sand. It really has no reflection on you or the quality of your bug report - it's just that if we didn't do this, we'd never make a release. What isn't entirely obvious to the rest of the community is the speed at which our releases start to ramp down, entering what we call high resistance mode. In this stage of the release, it becomes more and more difficult to make fixes as the risk / reward ratio has to be conveyed to a team of people who form what we call 'bug court'. The ratio has to better as the weeks wind on. Many of the issues that have been filed against me recently would be very risky in my opinion, and whilst the reward is also high, I could not comfortably defend making a change at this stage of the release without potentially causing follow-on issues that would be worse and / or be considered showstoppers - bugs that stop a release from happening or from other teams (such as the Scene Builder team) from being able to build with the latest promoted code. This is why I am cautious with these bugs. Trust me, I wish I could fix them all right now. I really do. We are already in high resistance mode for JavaFX 2.2. You've probably noticed the number of emails coming from our pushes to the repo has been diminishing in the last few weeks. Of course, the flip side is that you can be far less cautious at the start of a release, as it is a long way off from the next release (no matter how short the cycles are). I hope to find time to really get through my bug backlog - and I hear you loud and clear what issues are causing you pain. I just hope I don't need to jump straight into feature work - trust me, I've been asking for more focus on bug fixes for a long time. JavaFX releases are synced with Java update releases, which I believe are every three months. Personally I would love to do a minor 2.x release prior to the next major release so that we can iterate on bug count and a few minor features. It probably won't surprise you to say I've already mentioned this numerous times to the people that make these kind of decisions but I'm not aware of the current plans - I'm just a lowly engineer here, trying to give you guys the best darn API (with as few bugs as possible) :-) I hope that clears up some things. -- Jonathan On 11/07/2012 6:57 a.m., Christian Schudt wrote: > John, I share your worries. During the last two months I reported 13 bugs. 5 of these were targeted for Lombard, 6 are still unscheduled and only 2 were scheduled for 2.2. > > Generally speaking I got the impression, that there are more important issues, as can be also seen here in the last comment: > http://javafx-jira.kenai.com/browse/RT-20616 (which is already Priority Major) > > I don't know what these priorities are, but in my opinion fixing bugs and stabilizing existing code, should be high priority for a new release, especially if they are a regression from a prior version, like this one: > http://javafx-jira.kenai.com/browse/RT-21936 (worked in 2.1 beta and is now targeted for Lombard, too) > > I would appreciate, if the JavaFX Team let the community know, what these priorities for 2.2 are and when it is supposed to be released. > > Have you (Oracle?) considered to release further minor 2.x releases until JavaFX 3.0? I worry, that 2.2 won't be stable enough to work with until Q3 2013. > > Best regards, > Christian > > From pedro.duquevieira at gmail.com Tue Jul 10 13:55:47 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 10 Jul 2012 21:55:47 +0100 Subject: Little worried about the ListView/TreeView/TableView Message-ID: +1 for that. I also have a show stopper bug that hasn't had the target version specified: http://javafx-jira.kenai.com/browse/RT-23127 I would very much like to have this fixed so I can release my app to the public. Thanks, best regards, -- Pedro Duque Vieira From hang.vo at oracle.com Tue Jul 10 14:04:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Jul 2012 21:04:11 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120710210416.5F93E47F13@hg.openjdk.java.net> Changeset: 9b69d1047d82 Author: Kinsley Wong Date: 2012-07-10 13:52 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9b69d1047d82 RT-23281: GridPaneDesignInfo.getCellBounds() breaks after adding a new RowConstraints to a GridPane. ! javafx-designtime/src/javafx/scene/layout/GridPaneDesignInfo.java Changeset: b26dbc994eec Author: Kinsley Wong Date: 2012-07-10 13:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b26dbc994eec RT-23288: [Accordion] SHIFT-TAB should move focus to previous control. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: 153fdd6ebb3d Author: Kinsley Wong Date: 2012-07-10 13:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/153fdd6ebb3d RT-23198: TabPane menu is shown when not necessary. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: a0ca6475993a Author: Kinsley Wong Date: 2012-07-10 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a0ca6475993a RT-23225: Pagination incorrect behavior when page count is less than 0. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java From hang.vo at oracle.com Tue Jul 10 14:04:19 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Jul 2012 21:04:19 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix for RT-21784: use tag @since in the javadoc Message-ID: <20120710210420.ED79B47F16@hg.openjdk.java.net> Changeset: 9f73665d3945 Author: rbair Date: 2012-07-10 13:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9f73665d3945 Fix for RT-21784: use tag @since in the javadoc ! javafx-concurrent/src/javafx/concurrent/Task.java ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java ! javafx-ui-common/src/javafx/application/Platform.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SnapshotParameters.java ! javafx-ui-common/src/javafx/scene/SnapshotResult.java ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.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/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/transform/Transform.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.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/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/Menu.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/MapValueFactory.java ! javafx-ui-controls/src/javafx/scene/control/cell/ProgressBarTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java ! javafx-util-converter/src/javafx/util/converter/FormatStringConverter.java From tom.schindl at bestsolution.at Tue Jul 10 14:07:47 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 10 Jul 2012 23:07:47 +0200 Subject: Ant-Task-Documentation Message-ID: <4FFC99A3.5060400@bestsolution.at> Hi, I'm just working on IDE support for fx-ant tasks but the documentation for things like fx:icon and fx:splash is a bit sparse (see http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference002.htm#CIAIEJHG). The biggest mystery for me what effect fx:icon what width/height/depth combination are expected to be set? An educated guess from my eclipse applications is: 16x16 8bit 16x16 32bit 32x32 8bit 32x32 32bit 48x48 8bit 48x48 32bit 256x256 32bit What are the icons used for (where do they show up)? What are the supported formats (guess is png,jpg,gif)? 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 Tue Jul 10 15:15:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Jul 2012 22:15:37 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-22953 effects docs Message-ID: <20120710221539.DFFA747F1E@hg.openjdk.java.net> Changeset: b7f67bf6f737 Author: "Joseph Andresen" Date: 2012-07-10 14:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b7f67bf6f737 RT-22953 effects docs ! javafx-ui-common/src/javafx/scene/effect/Blend.java ! javafx-ui-common/src/javafx/scene/effect/Bloom.java ! javafx-ui-common/src/javafx/scene/effect/BoxBlur.java ! javafx-ui-common/src/javafx/scene/effect/ColorAdjust.java ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/DropShadow.java ! javafx-ui-common/src/javafx/scene/effect/FloatMap.java ! javafx-ui-common/src/javafx/scene/effect/GaussianBlur.java ! javafx-ui-common/src/javafx/scene/effect/Glow.java ! javafx-ui-common/src/javafx/scene/effect/ImageInput.java ! javafx-ui-common/src/javafx/scene/effect/InnerShadow.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java ! javafx-ui-common/src/javafx/scene/effect/MotionBlur.java ! javafx-ui-common/src/javafx/scene/effect/PerspectiveTransform.java ! javafx-ui-common/src/javafx/scene/effect/Reflection.java ! javafx-ui-common/src/javafx/scene/effect/SepiaTone.java ! javafx-ui-common/src/javafx/scene/effect/Shadow.java From jmartine_1026 at yahoo.com Tue Jul 10 17:00:21 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Tue, 10 Jul 2012 17:00:21 -0700 (PDT) Subject: Ant-Task-Documentation In-Reply-To: <4FFC99A3.5060400@bestsolution.at> References: <4FFC99A3.5060400@bestsolution.at> Message-ID: <1341964821.3753.YahooMailNeo@web160904.mail.bf1.yahoo.com> Have not had much luck setting the application executable's icon. ?No matter what I try I keep getting this msg... "Using default package resource [application icon] (add package/windows/TurretMaster.ico to the class path to customize)" I tried using both fx:icon and fx:fileset but neither work. ?Fx:fileset at least puts the icon in the 'app' directory. Here are the ant commands I am using (arrows added to point out the two icon lines)... ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? --> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? --> ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Was able to get the installation executable to have the correct icon but in a round about way.... had to prevent the ant script from launching Inno setup then I put in the correct icon and launched Inno Setup's compile myself. ? jose ________________________________ From: Tom Schindl To: "openjfx-dev at openjdk.java.net" Sent: Tuesday, July 10, 2012 5:07 PM Subject: Ant-Task-Documentation Hi, I'm just working on IDE support for fx-ant tasks but the documentation for things like fx:icon and fx:splash is a bit sparse (see http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference002.htm#CIAIEJHG). The biggest mystery for me what effect fx:icon what width/height/depth combination are expected to be set? An educated guess from my eclipse applications is: 16x16 8bit 16x16 32bit 32x32 8bit 32x32 32bit 48x48 8bit 48x48 32bit 256x256 32bit What are the icons used for (where do they show up)? What are the supported formats (guess is png,jpg,gif)? 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 Tue Jul 10 17:34:14 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 11 Jul 2012 00:34:14 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120711003416.94DF847F24@hg.openjdk.java.net> Changeset: 302ba4698b33 Author: David Grieve Date: 2012-07-10 20:19 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/302ba4698b33 RT-23207: if node has inline styles, use slowpath ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: cefe52608b67 Author: David Grieve Date: 2012-07-10 20:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/cefe52608b67 RT-20643: add Scene to CssError and Node to CssError.PropertySetError ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-controls/src/javafx/scene/control/Control.java From jmartine_1026 at yahoo.com Tue Jul 10 20:08:14 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Tue, 10 Jul 2012 20:08:14 -0700 (PDT) Subject: invisible images when scaling Message-ID: <1341976094.81112.YahooMailNeo@web160902.mail.bf1.yahoo.com> hello, When scaling in my app while units are moving through PathTransitions they start?disappearing or flickering, or both. ?This time I got code to reproduce.? Jira 23351 Hopefully its user error. ? In the past things like this were caused by passing NaN to some node for something or other. ?In this case I do not see that?happening, but maybe I am missing it.... will keep checking for it. thanks? jose From hjohn at xs4all.nl Tue Jul 10 21:18:34 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 11 Jul 2012 06:18:34 +0200 Subject: Little worried about the ListView/TreeView/TableView classes In-Reply-To: <4FFC88A6.2050107@oracle.com> References: <4FFB6081.3090300@xs4all.nl> <4FFB6313.8000303@oracle.com> <4FFC688F.4020209@xs4all.nl> <4FFC88A6.2050107@oracle.com> Message-ID: <4FFCFE9A.3040709@xs4all.nl> On 10/07/2012 21:55, Jonathan Giles wrote: > Comments inline. > > -- Jonathan > > On 11/07/2012 5:38 a.m., John Hendrikx wrote: >> Hi Jonathan, >> >> I'll do what can to help get some of these resolved, so I have filed >> three new issues (all using the same sample code), RT-23331, >> RT-23332 and RT-23333 which address three of the problems below. >> Some of the others I already created issues for, the most critical of >> those (causing graphics glitches) is a solution for this one: >> >> RT-22555 Unpredictable behaviour with scrollTo and the view classes >> (TableView as example) >> >> It causes rendering to fail -- for Scenes that are fairly static this >> can mean some controls are simply invisible until the user tries >> interacting with them. The provided sample is brute-force code to >> get this to occur, but it happens in normal use of my app (especially >> when only layout is changed and some controls are swapped out, ie, a >> TreeView becomes a TableView to show items in 2 columns -- in those >> cases all data is loaded already and the change can happen very fast >> -- when more processing still needs to occur (like images being >> loaded causing item changes) it doesn't happen.. or it simple hides >> the problem because of a redraw occuring). > I've noted a simplistic workaround to this problem in the jira issue. > Basically, you're trying to modify the state of UI controls before > they are in a scene, which is not very well defined. They are part of the Scene, but not rendered yet probably. It all occurs in a ChangeListener on a property that a user can change (they can choose different layouts for the screen) so it is all on the FX-thread. Here's a code snippet (with added comments): // Inside ChangeListener here MediaNode selectedNode = null; // holds previous select node if(layout != null) { // unbinds/removes old layout from the StackPane this Changelistener is part of if(currentRoot.equals(layout.getRoot())) { selectedNode = layout.getSelectedNode(); // it only makes sense to re-select the focused node if the root did not change } layout.onNodeSelected().set(null); // unbinding of listeners layout.onNodeAlternateSelect().set(null); focusedNode.unbind(); getChildren().remove(layout); // remove from StackPane } layout = layoutExtension.createLayout(); // creates the new layout, a StackPane with two panels one containing a *View class getChildren().add((Node)layout); // adds it to the Scene (the ChangeListener is part of a StackPane that is already visible and doesn't change). backgroundPane.mediaNodeProperty().bind(layout.mediaNodeBinding()); layout.onNodeSelected().set(onNodeSelected.get()); layout.onNodeAlternateSelect().set(onNodeAlternateSelect.get()); focusedNode.bind(layout.focusedNodeProperty()); layout.setRoot(currentRoot); // this causes the Tree/TableView to be filled with data (well after it was added to Scene) if(selectedNode != null) { setSelectedNode(selectedNode); // this causes the correct item to be selected and scrolled to } I haven't tried other "solutions" yet, like binding to sceneProperty() and waiting for it to become non-null (but I guess that happens right after the getChildren().add() occurs). Other workarounds might be adding all possible layouts to the Scene right from the start, hiding all but the user choosen one. >> >> Then there several issues dealing with Cell creation: >> >> RT-22946 TreeView creates cells for every item from start to scrollTo >> position >> RT-20892 Layout pass of TreeView can result in unneccessary >> recreation of TreeCells >> RT-20616 TreeView creates new cells every time root is changed >> >> The first one is the most problematic because it creates lots of >> cells but more importantly.. *different* cells. The other two are >> less of a problem since atleast they donot cause data to be accessed >> that is not going to be displayed. > I've definitely got a few performance issues with > TreeView/ListView/TableView, but I wasn't about to try and fix them at > the end of the 2.2 development cycle (it's just too risky). Instead, I > hope to look at these issues very early in the next release cycle. I'm > more than happy to work with others on developing fixes via openjfx > though! :-) Yes, I can understand that -- I don't know if I will be able to understand to code well enough and have the time to offer any help here -- I've looked through it before and it seems the VirtualFlow class which is common to all of these controls is probably where this can be resolved. I haven't looked at openjfx much yet, I don't know yet how to go about getting that code base to run locally. >> >> The issue with creation of a ListView and using it immediately (with >> select/focus/scrollTo calls) is captured a bit in RT-22555 as well I >> think, resolving that will probably resolve these issues as well. > I'm not too sure whether you're referring to another jira issue here? Not specifically, this is related to manipulating controls before they're added to the Scene (or atleast before rendering first time). See the code above where I add a new control to a (visible) StackPane and set it up correctly with data/selection/scroll position all in the same ChangeListener. >> >> And there's two minor issues I filed related to these classes as well: >> >> RT-20879 After setting new root on TreeView, focus model's focused >> item property is not updated >> RT-22398 Some navigation keys (pg-down/up, etc) donot work until >> TreeView/ListView/TableView item has both focus AND is selected > I've asked for further feedback on these two issues in Jira - I'm > awaiting your response. I commented on the 2nd one, I'll check out the other now. >> For some of these it is rather hard to create good small test >> programs -- there appear to be timing issues with some of them >> (whether the ListView has already been rendered atleast once or not >> yet, and/or whether it was added to a Scene or not). Sometimes >> putting things like select/focus/scrollTo in a Platform.runLater() >> makes the issue worse or better. > Platform.runLater is unfortunately not a solution (as you note). The > primary issue really is whether a node is part of a scene before you > run operations on it, and whether you're running operations in the > JavaFX application thread. >> >> I can provide help in the form of trying to write test cases for >> problems that you cannot reproduce at all. The three most annoying >> bugs are: >> >> RT-22555 (causes graphic glitches) >> RT-22946 (makes large lists slow to display when scrolling to a high >> index in the list when restoring last cursor position) >> RT-23331 (graphics glitch where user cannot see the highlighted item) > I've commented about RT-22555. > RT-22946 falls into the bucket of perf fixes I hope to do early in the > next release cycle. > RT-23331 seems to relate to a custom written skin. I would be very > interested if there are any issues when using the provided default skins. As said, RT-23331 also occurs with the standard skin, just much more rare -- the custom skin just makes it easier to reproduce. I don't understand how the skin is even involved in this (especially since it is the ScrollBarSkin and not the ListViewSkin itself). I've not seen it happen yet with my fixed custom skin, but it might also be much more rare now, just like the default skin. Could you reproduce it atleast? It should show up as the wrong cell being selected and the real active cell not showing up as selected. >> >> The rest are annoying but only waste some resources or are minor gfx >> glitches or have work-arounds. >> >> If there is anything I can do to make these easier to solve, I can >> work on that in the weekend/evenings. I'll upgrade to the latest >> beta tonight to see if any of them happened to have been resolved. > Another thing you can consider doing is pulling the latest openjfx > mercurial repo code and attempting to develop fixes - all the controls > source is open. You never know, you might be able to fix some of these > bugs :-) I haven't tried anything like that before... is this code complete enough to run? Do I need tricks to get it loaded (like putting it in the 'pre' boot classpath?) --John From kirill.prazdnikov at oracle.com Wed Jul 11 00:44:14 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Wed, 11 Jul 2012 11:44:14 +0400 Subject: invisible images when scaling In-Reply-To: <1341976094.81112.YahooMailNeo@web160902.mail.bf1.yahoo.com> References: <1341976094.81112.YahooMailNeo@web160902.mail.bf1.yahoo.com> Message-ID: <4FFD2ECE.8070408@oracle.com> Hi Jose Is it possible to reproduce in static to understand is it Image issue or Animation issue ? Thanks On 11.07.2012 7:08, Jose Martinez wrote: > hello, > > When scaling in my app while units are moving through PathTransitions they start disappearing or flickering, or both. This time I got code to reproduce. > > Jira 23351 > > Hopefully its user error. In the past things like this were caused by passing NaN to some node for something or other. In this case I do not see that happening, but maybe I am missing it.... will keep checking for it. > > thanks > jose From alexandre.iline at oracle.com Wed Jul 11 01:00:25 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Wed, 11 Jul 2012 08:00:25 +0000 Subject: hg: openjfx/2.2/master/tests: 7 new changesets Message-ID: <20120711080026.8C64647F5B@hg.openjdk.java.net> Changeset: 5c018133b733 Author: Oleg Barbashov Date: 2012-06-29 07:58 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/5c018133b733 AccordionWrap: waiter of animation ending is added ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TitledPaneWrap.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/AccordionApp.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/AccordionTest.java Changeset: b51327306edb Author: Alexandre (Shura) Iline Date: 2012-07-02 19:23 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/b51327306edb some more javadoc a few more usages of As@ ! tools/Jemmy/JemmyFX/depend.properties ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputSampleBase.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/TextWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/CheckBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TextInputControlWrap.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TextTest.java Changeset: b6609370b51e Author: Alexandre (Shura) Iline Date: 2012-07-02 19:39 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/b6609370b51e merge ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java Changeset: 42c1d926580e Author: Alexander Kouznetsov Date: 2012-07-03 12:36 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/42c1d926580e Added mini samples for ComboBox and ChoiceBox. + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/combobox/ComboBoxApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/combobox/ComboBoxSample.java Changeset: e233a16f3e2a Author: Alexandre (Shura) Iline Date: 2012-07-09 11:34 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/e233a16f3e2a Major rewrite for tree, table and list support. Check appropriate tests for sample usage. ! tools/Jemmy/JemmyFX/depend.properties ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextSample.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ItemDataParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ItemParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ListItemParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ListItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ListViewWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TableCellItemParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TableCellItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TableViewWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeImpl.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeItemParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeNodeParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeNodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeViewWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ViewElement.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/TreeItem.java ! tools/Jemmy/JemmyFX/src/org/jemmy/interfaces/CellOwner.java ! tools/Jemmy/JemmyFX/src/org/jemmy/interfaces/Tree.java ! tools/Jemmy/JemmyFX/src/org/jemmy/interfaces/TreeSelector.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/LookupTest.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/ListItemTest.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/ListTest.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TableItemTest.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TableViewLookupTest.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeApp.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeItemTest.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeTest.java Changeset: fd64947dad08 Author: Alexandre (Shura) Iline Date: 2012-07-09 11:56 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/fd64947dad08 merge Changeset: 23d44916e7f3 Author: Alexandre (Shura) Iline Date: 2012-07-09 16:12 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/23d44916e7f3 ComboBox sample fix DockWrapObjectSample ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/combobox/ComboBoxSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/docks/DockWrapObjectSample.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/index.html ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ChoiceBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ComboBoxWrap.java From neugens.limasoftware at gmail.com Wed Jul 11 01:02:16 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 11 Jul 2012 10:02:16 +0200 Subject: State of OpenJFX Message-ID: Hi all! It has been a bit that I don't follow the development of JavaFX, so I would like if possible to get a small overview of the state of the code. I see from the development page that we still need quite some bits from the closed repository to be able to build OpenJFX. What is the state of that, and how much closed code we still need to get the JFX experience? Any estimation when the rest will released? Thanks a lot! Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From kirill.prazdnikov at oracle.com Wed Jul 11 02:30:47 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Wed, 11 Jul 2012 13:30:47 +0400 Subject: invisible images when scaling In-Reply-To: <4FFD2ECE.8070408@oracle.com> References: <1341976094.81112.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FFD2ECE.8070408@oracle.com> Message-ID: <4FFD47C7.4070006@oracle.com> Hi Jose, It is an issue with dirty rect optimization. The following code is a workaround. > public static void main(String[] args) { > System.setProperty("prism.dirtyopts", "false"); > launch(args); > } Thanks -Kirill On 11.07.2012 11:44, Kirill.Prazdnikov wrote: > Hi Jose > > Is it possible to reproduce in static to understand is it Image issue > or Animation issue ? > > Thanks > > On 11.07.2012 7:08, Jose Martinez wrote: >> hello, >> >> When scaling in my app while units are moving through PathTransitions >> they start disappearing or flickering, or both. This time I got code >> to reproduce. >> Jira 23351 >> >> Hopefully its user error. In the past things like this were caused >> by passing NaN to some node for something or other. In this case I >> do not see that happening, but maybe I am missing it.... will keep >> checking for it. >> >> thanks jose > From hang.vo at oracle.com Wed Jul 11 05:18:51 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 11 Jul 2012 12:18:51 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20643: add Scene to CssError and Node to CssError.PropertySetError - fix bug found by SceneBuilder testing Message-ID: <20120711121854.0F00547F6F@hg.openjdk.java.net> Changeset: 30b375f0ad85 Author: David Grieve Date: 2012-07-11 08:03 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/30b375f0ad85 RT-20643: add Scene to CssError and Node to CssError.PropertySetError - fix bug found by SceneBuilder testing ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java From kevin.rushforth at oracle.com Wed Jul 11 05:35:57 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 Jul 2012 05:35:57 -0700 Subject: invisible images when scaling In-Reply-To: <4FFD47C7.4070006@oracle.com> References: <1341976094.81112.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FFD2ECE.8070408@oracle.com> <4FFD47C7.4070006@oracle.com> Message-ID: <4FFD732D.1010704@oracle.com> Note that this is just for debugging and isn't meant for deployment (it is not a supported property). Also, this will only work if you actually run your app via the main method and not via the javafx packager. -- Kevin Kirill.Prazdnikov wrote: > Hi Jose, > > It is an issue with dirty rect optimization. > > The following code is a workaround. > >> public static void main(String[] args) { >> System.setProperty("prism.dirtyopts", "false"); >> launch(args); >> } > > Thanks > -Kirill > > On 11.07.2012 11:44, Kirill.Prazdnikov wrote: >> Hi Jose >> >> Is it possible to reproduce in static to understand is it Image issue >> or Animation issue ? >> >> Thanks >> >> On 11.07.2012 7:08, Jose Martinez wrote: >>> hello, >>> >>> When scaling in my app while units are moving through >>> PathTransitions they start disappearing or flickering, or both. >>> This time I got code to reproduce. >>> Jira 23351 >>> >>> Hopefully its user error. In the past things like this were caused >>> by passing NaN to some node for something or other. In this case I >>> do not see that happening, but maybe I am missing it.... will keep >>> checking for it. >>> >>> thanks jose >> > From tom.schindl at bestsolution.at Wed Jul 11 05:51:40 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 11 Jul 2012 14:51:40 +0200 Subject: Ant-Task-Documentation In-Reply-To: <1341964821.3753.YahooMailNeo@web160904.mail.bf1.yahoo.com> References: <4FFC99A3.5060400@bestsolution.at> <1341964821.3753.YahooMailNeo@web160904.mail.bf1.yahoo.com> Message-ID: <4FFD76DC.9060607@bestsolution.at> well I found out that splash and icon endup in the jnlp file - so my guess is that they are only used for the webstart stuff but not for native packaging stuff. tom Am 11.07.12 02:00, schrieb Jose Martinez: > Have not had much luck setting the application executable's icon. No > matter what I try I keep getting this msg... > > "Using default package resource [application icon] (add > package/windows/TurretMaster.ico to the class path to customize)" > > I tried using both fx:icon and fx:fileset but neither work. Fx:fileset > at least puts the icon in the 'app' directory. > > Here are the ant commands I am using (arrows added to point out the two > icon lines)... > > height="${javafx.run.height}" > nativeBundles="all" verbose="true" > outdir="${basedir}/${dist.dir}" > outfile="${application.title}"> > mainClass="${javafx.main.class}"/> > > includes="${application.title}.jar"/> > --> includes="${application.title}.ico"/> > > vendor="${application.vendor}"> > --> > > > > > Was able to get the installation executable to have the correct icon but > in a round about way.... had to prevent the ant script from launching > Inno setup then I put in the correct icon and launched Inno Setup's > compile myself. > > jose > ------------------------------------------------------------------------ > *From:* Tom Schindl > *To:* "openjfx-dev at openjdk.java.net" > *Sent:* Tuesday, July 10, 2012 5:07 PM > *Subject:* Ant-Task-Documentation > > Hi, > > I'm just working on IDE support for fx-ant tasks but the documentation > for things like fx:icon and fx:splash is a bit sparse (see > http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference002.htm#CIAIEJHG). > > The biggest mystery for me what effect fx:icon what width/height/depth > combination are expected to be set? > > An educated guess from my eclipse applications is: > 16x16 8bit > 16x16 32bit > 32x32 8bit > 32x32 32bit > 48x48 8bit > 48x48 32bit > 256x256 32bit > > What are the icons used for (where do they show up)? What are the > supported formats (guess is png,jpg,gif)? > > Tom > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at > phone ++43 512 935834 > > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From jmartine_1026 at yahoo.com Wed Jul 11 06:40:52 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 11 Jul 2012 06:40:52 -0700 (PDT) Subject: invisible images when scaling In-Reply-To: <4FFD2ECE.8070408@oracle.com> References: <1341976094.81112.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FFD2ECE.8070408@oracle.com> Message-ID: <1342014052.77008.YahooMailNeo@web160902.mail.bf1.yahoo.com> Krill, >Is it possible to reproduce in static to understand is it Image issue or Animation issue ? I would say that it is not?reproducible?on static for two reasons. ?In my app there are dozens of static nodes on screen and they do not flicker off. ?Second, when the problem occurs the offending nodes on the PathTransition flicker off further down the path from where the scaling change occurred. thanks jose ________________________________ From: Kirill.Prazdnikov To: Jose Martinez Cc: openjfx mailing list Sent: Wednesday, July 11, 2012 3:44 AM Subject: Re: invisible images when scaling Hi Jose Is it possible to reproduce in static to understand is it Image issue or Animation issue ? Thanks On 11.07.2012 7:08, Jose Martinez wrote: > hello, > > When scaling in my app while units are moving through PathTransitions they start disappearing or flickering, or both.? This time I got code to reproduce. > Jira 23351 > > Hopefully its user error.? In the past things like this were caused by passing NaN to some node for something or other.? In this case I do not see that happening, but maybe I am missing it.... will keep checking for it. > > thanks jose From eva.krejcirova at oracle.com Wed Jul 11 07:40:27 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 11 Jul 2012 16:40:27 +0200 Subject: Extending builders: StageBuilder Message-ID: <4FFD905B.9070009@oracle.com> 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 pavel.safrata at oracle.com Wed Jul 11 07:57:47 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 11 Jul 2012 16:57:47 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFC5A02.8040709@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> Message-ID: <4FFD946B.1070905@oracle.com> Hi Martin, thank you for your input. On 10.7.2012 18:36, Martin Desruisseaux wrote: > Hello Pavel > > Many thanks for taking care of this task! > > > Le 10/07/12 17:00, Pavel Safrata a ?crit : >> On Transform class: >> public Transform getConcatenation(Transform transform) // >> multiplication >> public Transform getInverse() throws >> NoninvertibleTransformException // negation >> public Transform copy() > Sound fine to me, while I'm not sure why a 'copy' method instead than > overriding the 'clone()' method? Good point, we can use clone(). > > >> Constructors: >> public Affine(Transform transform) >> public Affine(double mxx, double mxy, double mxz, double tx, >> double myx, double myy, double myz, double ty, >> double mzx, double mzy, double mzz, double tz) > Look fine. > > >> Setters of the entire matrix: >> (...snip...) > I don't know for JavaFX, but in my experience with Java2D, I wasn't > using the setter methods often, except 'setToIdentity' and > 'setToTransform'. For example rather than invoking 'setToTranslation', > I strongly push our developers to use 'translate' (or > 'concatWithTranslation' in this proposal) instead. If a developer > really wants the functionality of 'setToTranslation', he can get it by > invoking 'setToIdentity()' followed by 'concatWithTranslation'. Or yet > better, 'setToTransform(...)' instead than 'setToIdentity' with the > coefficients of some previous state that the user saved. I don't insist on having the setters, anybody wants them? > > The rational is that in many cases, the affine transform is already > initialized to some important value. For example in Java2D, > AffineTransform is initialized to the transform from 'dot' to whatever > units the underlying device uses. When rendering on screen, this is > the identity transform. But when printing, this is something different > that depends on the printer resolution. In GIS applications, it > depends on the zoom level. Other applications may use magnifier glass > over some areas. Because the initial transform is often (but not > always) the identity one, developers with limited experience with > affine transforms often use 'setTranslate' or 'setScale' in situations > where they should really use 'translate' or 'scale', and do not > realize their bug before late in the development process. For this > reason, I would be inclined to discourage every setter methods except > 'setToIdentity()' and 'setToTransform'. Keeping in mind that it is > often easier to fill a hole later than to fix something broken, I > think it would be safer to leave out all other setter methods for now, > and revisit later if experience show that they are really needed. > While I don't think our Affine class will ever have varying initial values I'm ok with keeping only setToIdentity() and setToTransform() if there is no demand for the other setters right now. > >> Operations on the matrix (modifying it in place): >> (...snip...) > Sound good, minus the unfortunate 'concatWith*' naming :-(. > > >> Instead of "concatWithTranslation" it would be more natural to use >> just "translate" (and similarly for the others), but unfortunately >> these method names are already taken by the static factory methods on >> Transform class. This is unpleasant but we need to be backward >> compatible so we have to introduce different names. We'll be happy to >> hear better naming suggestions than the concatWith* (which is pretty >> descriptive I think but not really nice). > Hard to say... A consistency with "preTranslate" would be nice, but > "postTranslate" doesn't look very nice... What about the following? > > * Rename "preTranslate" as "appendTranslation" > * Rename "concatWithTranslation" as "prependTranslation" > > The "preConcatenate(Tx)" name in Java2D was actually misleading to > some developers, because it works as if points were first transformed > by the original transform, then transformed by 'Tx'. Maybe > "appendTranslation(Tx)" would make clear that the translation is > applied after the original transform. This would also make operation > order clearer. The following code using Java2D API: > > tr.translate(...) > tr.scale(...) > tr.rotate(...) > > must be read from bottom to up: it is as if points were rotated first, > then scaled, then translated. So maybe the above proposition would > make that more obvious: > > tr.prependTranslation(....) > tr.prependScale(...) > tr.prependRotate(...) > tr.appendTranslation(...) // Just for fun. > These names indeed sound way better. If we are going this way, shouldn't we do also this? * Rename 'concatenate' as 'prepend' * Rename 'preConcatenate' as 'append' * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) As a black-box transformation composing this makes sense. As a matrix algebra, it may be also confusing: tA.append(tB) means matrix multiplication 'B x A', does it sound good? Maybe yes, I'm not sure. Anyway, so far the best proposal I think. > >> Would you want static factory methods on Affine (creating Affine >> instances with the simple transforms)? > I don't think it is necessary. I found the static factory methods of > Java2D AffineTransform rarely used. > >> Would it be important to you whether or not matrix changes are >> atomic? If you call one of the methods that modify the entire matrix, >> can be listeners for each member called immediately as the members >> are set, or do they need to be called after all the members are updated? > I don't have experience in this area. But naively, it seems to we that > it would be better to be notified only after the full matrix has been > updated... Yes, I would also pick this option. It's just that it would mean writing much more complicated (and a bit less effective) code so the question is whether or not you think it is important. Thanks, Pavel > > Regards, > > Martin > From martin.desruisseaux at geomatys.fr Wed Jul 11 08:39:51 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Wed, 11 Jul 2012 17:39:51 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFD946B.1070905@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> Message-ID: <4FFD9E47.7040403@geomatys.fr> Le 11/07/12 16:57, Pavel Safrata a ?crit : > If we are going this way, shouldn't we do also this? > * Rename 'concatenate' as 'prepend' > * Rename 'preConcatenate' as 'append' Yes, I think it would bring more uniformity in the method naming. > * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) I missed that method... What would its function? Or are we are talking about something like a 'getTransformCoefficients()' method? > As a black-box transformation composing this makes sense. As a matrix > algebra, it may be also confusing: tA.append(tB) means matrix > multiplication 'B x A', does it sound good? Maybe yes, I'm not sure. > Anyway, so far the best proposal I think. Yes, I realize that a risk of confusion may exist. We may need to stress out in the javadoc that "append" is not "multiply". Indeed, if the "append" method was defined in the parent Transform class and if that parent was the base class of generic transformations (not just linear transformations), then the "append" method would actually not be implemented as a matrix multiplication except in the special case of linear transformations. >> I don't have experience in this area. But naively, it seems to we >> that it would be better to be notified only after the full matrix has >> been updated... > Yes, I would also pick this option. It's just that it would mean > writing much more complicated (and a bit less effective) code so the > question is whether or not you think it is important. I don't have a use case where I would like to listen to individual coefficient changes. It seems to me that I would rather listen to whatever property contains the Transform object as a whole. Consequently, I don't think that the atomicity of Affine operations would have much incidence (assuming that there is some way - other than listening to individual coefficients - to be informed that the matrix as a whole has changed). Martin From hang.vo at oracle.com Wed Jul 11 08:48:33 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 11 Jul 2012 15:48:33 +0000 Subject: hg: openjfx/2.2/controls/rt: [TEST-ONLY] RT-23320 - Traversal : write unit test to check for nested focus-traversal cycles inside a TabPane. Message-ID: <20120711154835.3C6AB47F79@hg.openjdk.java.net> Changeset: 1953b610d096 Author: mickf Date: 2012-07-11 16:46 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1953b610d096 [TEST-ONLY] RT-23320 - Traversal : write unit test to check for nested focus-traversal cycles inside a TabPane. ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java From igor.nekrestyanov at oracle.com Wed Jul 4 10:06:31 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 04 Jul 2012 10:06:31 -0700 Subject: Deployment: native application bundles In-Reply-To: <1341419257.17746.YahooMailNeo@web160901.mail.bf1.yahoo.com> References: <4FDAE162.6070802@oracle.com> <4FDB8620.9030105@oracle.com> <4FDC228A.9090702@oracle.com> <1341419257.17746.YahooMailNeo@web160901.mail.bf1.yahoo.com> Message-ID: <4FF47817.8000803@oracle.com> On 7/4/12 9:27 AM, Jose Martinez wrote: > Hello, > > I installed Inno Setup but I still get the following error..... > > [Can not find Inno Setup Compiler (iscc.exe).] Any idea how this I > can fix this? Make sure Inno Setup folder (typically it is "c:\Program Files\Inno Setup 5") is added to your path before you run ant. To verify it is ok simply try to run iscc.exe from command line before you run ant or javafxpackager. Command should be found. Otherwise packager will not be able to find it. -igor > > feedback: Was able to create the bundled jre with executable and it > worked fine. Not bad at all. I been using Install4j, which is a > $2000 application, to do my packaging (still using trial version). So > if this works it will save me a lot of money. :-) > thanks > jose > ------------------------------------------------------------------------ > *From:* Daniel Zwolenski > *To:* Igor Nekrestyanov > *Cc:* "openjfx-dev at openjdk.java.net" > *Sent:* Saturday, June 16, 2012 6:03 AM > *Subject:* Re: Deployment: native application bundles > > I like the sound of the pluggable 'bundlers', and agree that having a WiX > free implementation is very low priority if the customisation of WiX is > fairly straight forward. > > Thanks for the code snippet - very interesting how you load the DLL and > hook into it. You can ignore my comment about the executable jar, it's not > applicable to the way you are doing things. I imagine native dependencies > will work just fine in your approach. > > It all looks good! > > If we did want to make this work with the auto-update approach I've > prototyped, the main challenge will be that your bundle assumes the local > version is the only version (as you'd expect it to). It assumes everything > in the app directory should be in the classpath, and the JRE is in the jre > directory. My POC however uses an 'app-profile.xml' to explicitly define > each JAR on the path and the version of the JRE to use. > > The reason this app-profile is needed in my POC is that when I > download new > versions I can't overwrite the current jars and JRE because they are > locked > by the process doing the download - so for some time at least both the new > jars and old jars need to co-exist. My current solution is to append > version numbers to everything, so when I download myapp-2.0.jar, the old > myapp-1.0.jar is still there, same with jre6 and jre7. Then the > app-profile.xml is used to decide which jars and jre are the correct ones > to use and the old ones are ignored. Without an app-profile both the old > 1.0 and the 2.0 jar would get loaded. > > The app-profile also doubles up as a record of the locally installed > version and is used by the code to determine what needs updating. There > would be plenty of other ways to do this (e.g. query the JVM for its > version and look at the jar names) but the app-profile does make it pretty > simple. > > All just stuff to look into as we explore the auto-updating functionality. > > > Cheers, > Dan > > > > On Sat, Jun 16, 2012 at 4:07 PM, Igor Nekrestyanov < > igor.nekrestyanov at oracle.com > wrote: > > > Hi, > > > > > > Regarding the MSI installer, using WiX does make it easier but I'm > > wondering if there would be some merit in trying to write our own MSI > > creator using the Windows Installer SDK. I haven't used it myself > yet but I > > believe it can be used to create MSI's. This would have the advantage of > > not needing extra software installed, and also would allow us to > customise > > closely to what we need specifically for Java installations (e.g. > provide > > our own configuration options in whatever syntax or format we want - > e.g. > > an 'app-profile.xml'). The disadvantage of course is the extra work, but > > this may be something I could look at in my POC side of it. Something to > > think about anyway. > > > > Basic approach we are using is to adding support for "bundlers" to the > > toolchain. Bundler is something that can produce package out of set > of app > > resources, JRE, etc. > > Bundler may or may not have additional requirements (like run only on > > specific platform or require WiX, etc.) > > > > When developer requests to "bundle" app we produce all bundles we can > > generate (by running all applicable bundlers). > > > > JavaFX 2.2 will provide some set of bundlers embedded into packaging > tools. > > > > This approach allow to add new bundler or rewrite bundler later on if > > there will be better solution (e.g. WiX-less MSI bundler or cross > platform > > deb bundler, etc). > > > > As for WiX-less bundler specifically i think it might be nice to > have but > > i do not see it as critical issue right now. > > We are generating WiX config files based on templates and can expose any > > configuration parameters we need in whatever syntax we want. > > Once we understand what is limiting with this approach we can decide on > > how we can get something better. > > Using existing solution that works well for producing MSI allow us to > > focus on JavaFX specific problems and other bundlers. > > > > Regarding natives, if you are using an executable JAR I don't think > this > > will work (i.e. executable JARs don't support native included in them), > > unless the developer does the old extract and include on path trick. > Better > > that the natives just get bundled into the installation directory > and not > > into the jar, I reckon. It's a bit of a messy area (especially for > > auto-updates) so probably worth making sure we're covered in this area > > fairly early on. > > > > I think it do not understand the problem. > > In my model i assume that application image is something you can run > using > > java.exe like > > cd app-image/ > > java -cp main.jar main.class > > (where app image is your dist of build folder). > > > > When you are running app from your IDE, debugger or command line it > knows > > how to load native resources. > > I expect same copy of app-image to be kept under app/ folder in the > > installed image. > > > > Anyway, let me try to craft an example and we will see. > > > > > > > > Regarding the launching of the process, the way I do it also seems to > > give it the process the name of the app the proper name (and not > > 'java.exe'), which is a pleasant surprise. Do you use the same sort > of code > > as follows? > > > > My windows launcher is fairly simple now. Here is relevant part: > > > > > > // Dynamically load the JVM > > HMODULE jvmLibHandle = LoadLibrary(jvmPath); > > if (jvmLibHandle == NULL) { > > DWORD dwErr = GetLastError(); > > MessageBox(0, _T("Error loading jvm.dll"), jvmPath, > MB_ICONERROR | > > MB_OK); > > return FALSE; > > } > > > > //convert argument to ASCII string as this is what CreateJVM needs > > wcstombs_s(&outlen, jarASCII, (size_t) wcslen(jar) + 1, jar, (size_t) > > wcslen(jar) + 1); > > strcpy_s(classpath, MAX_PATH*2, "-Djava.class.path="); > > strcat_s(classpath, MAX_PATH, jarASCII); > > > > // Set up the VM init args > > jvmArgs.version = JNI_VERSION_1_2; > > > > //TODO: add support for custom JVM parameters > > options[0].optionString = classpath; > > jvmArgs.version = 0x00010002; > > jvmArgs.options = options; > > jvmArgs.nOptions = 1; > > jvmArgs.ignoreUnrecognized = TRUE; > > > > // Create the JVM > > // NB: need to use ASCII string as UNICODE is not supported > > createProc = (JVM_CREATE) GetProcAddress(jvmLibHandle, > > "JNI_CreateJavaVM"); > > if (createProc == NULL) { > > MessageBox(0, _T("Failed to locate JNI_CreateJavaVM"), jvmPath, > > MB_ICONERROR | MB_OK); > > return FALSE; > > } > > > > if ((*createProc)(&jvm, &env, &jvmArgs) < 0) { > > // Should not happen > > // FIXME: report localized error > > return FALSE; > > } > > > > cls = env->FindClass("com/javafx/main/Main"); > > if (cls != NULL) { > > mid = env->GetStaticMethodID(cls, "main", > > "([Ljava/lang/String;)V"); > > if (mid != NULL) { > > jclass stringClass = env->FindClass("java/lang/String"); > > jobjectArray args = env->NewObjectArray(0, stringClass, > NULL); > > env->CallStaticVoidMethod(cls, mid, args); > > } else { > > MessageBox(0, _T("no main method"), _T("Expected to find > > com.javafx.main.Main.main()"), MB_ICONERROR | MB_OK); > > } > > } else { > > MessageBox(0, _T("no main class"), _T("Expected to find > > com.javafx.main.Main"), MB_ICONERROR | MB_OK); > > } > > > > if (env->ExceptionOccurred()) { > > MessageBox(0, _T("Failed due to exception."), _T("Exception > thrown > > from com.javafx.main.Main.main()"), MB_ICONERROR | MB_OK); > > env->ExceptionDescribe(); > > } > > > > > > -igor > > > > I'd be keen to keep what I do in line with what you are doing where > > possible. > > > > > > > > > > On Sat, Jun 16, 2012 at 4:59 AM, Igor Nekrestyanov < > > igor.nekrestyanov at oracle.com > > wrote: > > > >> hi, thanks for all questions. > >> > >> Please keep them coming (bugs and suggestions are very welcome too!), > >> > >> > >> The Ensemble MSI install worked for me on Windows 7 no problems. I > >> haven't tried building my own app as yet though. > >> > >> It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. > Installing > >> into Program Files is probably more correct on windows. Is this > 'appdata' > >> the intended final location, or is this just for getting it all > running for > >> now? > >> > >> Original goal was to be able to install without requiring admin > >> permissions. > >> Both MSI and EXE installers are currently build to do this. > >> > >> It is possible to customize install location and make it system wide by > >> tweaking WiX/Inno Setup template files. > >> Clearly we want to expose better APIs for customization but it is not > >> clear what are importnat config parameters and how to expose them > >> in more or less cross platform way, hence we decided that for 2u2 > we will > >> provide an easy way to build basic package and do minimal customization > >> as well as (very) advanced way for advanced users. > >> > >> Based on feedback we will figure out how to expand built-in > configuration > >> APIs for future releases. > >> > >> I am planning to post more about package customization options and > other > >> tricks&tips but i am amateur blogger and slow typer, so it will > take me few > >> days :) > >> > >> Perhaps we should reconsider and produce EXE to be user level > >> installation and MSI to be system level by default. > >> I believe it is also possible to pass parameters to msiexec to > overwrite > >> some of MSI settings (end this is not unusual in the enterprise > >> deployments). > >> However, i had not tried if it is possible to install this MSI system > >> wide (and i am not sure if my MSI expertise is deep enough to craft MSI > >> that can do both, > >> suggestions are very welcome). > >> > >> > >> Is the source code available for this at all? > >> > >> Sorry, it is part of deploy/packager module that is not open sourced > >> yet. > >> > >> If not, I'm very interested in how the 'exe' launcher code looks. Is > >> this code you've written or part of one of the tools you've made > use of? > >> I'm particularly interested to see how it starts the app - does it just > >> kick off another process on the executable jar via something like 'java > >> -jar ensemble.jar' or does it try to run the Java app within it's > own 'exe' > >> process somehow (I'm assuming the later?). > >> > >> yes, launcher will instantiate JVM in the launcher process. > >> Check out list of processes when sample app is running. There is no > >> java.exe but there is Ensemble.exe > >> > >> > >> I notice also that the jfx DLLs have been copied straight into the > >> 'jre/bin' directory. > >> > >> Starting 7u6 JRE/JDK will include JavaFX as part of Java installation. > >> So, nothing special here. It is just runtime image. > >> > >> Is this how you see all native dependencies playing out, i.e. if my > >> application uses other native libraries how do I package them into the > >> build and where will they be installed to in the extracted directory? > >> > >> No, i do not think application resources will go into runtime. > >> Application resources will stay in the "app" folder (native libs too). > >> > >> The approach here is to "bundle" app without requiring to rewrite it. > >> During the development cycle your build output should have copy of > >> application you can execute and debug (but it depends on > environment, i.e. > >> java+javafx runtime). > >> Bundle is essentially > >> copy of this application + java runtime + launcher > >> > >> Having said that i had not tried to craft example with native libraries > >> myself. Will certainly try to do. > >> > >> One more question: when we say we have to build on the native > platform to > >> get the correct deployments, does that include 32bit vs 64bit? I'm > guessing > >> I could have a 32bit and 64bit JDK installation on the one machine and > >> build a version of my app for each, but correct me if I'm wrong on > this. > >> > >> yes, two installations should do. > >> > >> Currently ant task will try to use RUNNING version of java as > source for > >> cobundle. > >> If it is not appropriate (e.g. java 6 that is not javafx cobundle) then > >> it bundled app will not be created. > >> > >> In the future we may add option to specify which JDK to use as > import for > >> bundle creation but for now we are taking shortcuts to avoid > exposing too > >> much (kind of late in release). > >> > >> I assume there's no way for a single JDK installation to produce > both 32 > >> and 64bit versions? > >> > >> No, as currently JDK installations do not include both 32 and 64 bit > >> bits. After all we are copying them into bundle. > >> > >> -igor > >> > >> Very, very nice start to this all! > >> > >> Cheers, > >> Dan > >> > >> > >> On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov < > >> igor.nekrestyanov at oracle.com > > wrote: > >> > >>> Hi, > >>> > >>> One thing we are adding to JavaFX packaging tools in 2.2 is ability to > >>> produce native application bundles: > >>> > >>> > https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx > >>> > >>> We are not seeing this as the only way to deploy JavaFX > applications -- > >>> webstart, embedded applications > >>> and doubleclickable jars are first class citizens (and it would be > great > >>> to explore other options). > >>> But we hope it might be good option for many deployment scenarios. > >>> > >>> Please give it a try and provide feedback (and report bugs of course), > >>> > >>> -igor > >>> > >> > >> > >> > > > > > > From tom.schindl at bestsolution.at Fri Jul 6 10:52:18 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 06 Jul 2012 19:52:18 +0200 Subject: CSS-Documentation for IDE-Usage In-Reply-To: <4391A9D1-2466-455C-872D-613FF76F311A@oracle.com> References: <4FE03A80.4040700@bestsolution.at> <4391A9D1-2466-455C-872D-613FF76F311A@oracle.com> Message-ID: <4FF725D2.2080503@bestsolution.at> Hi, Well for me the important thing is a meta format I can feed to my IDE-Tooling which holds the following informations: * property name * validation information I've been working on a long train drive 2 weeks ago on such a meta format and translated fairly all informations found in the HTML-document into my meta language (the grammer of the language is not yet able to define all constructs in the document but we I'm not far way :-) I've developed this using xtext-framework (http://www.eclipse.org/Xtext/) which has the advantage that I also have an editor with syntax highlighting, auto-completetion, ... in my Eclipse. I'm not sure this is the same direction you are heading to - for me a meta format be it XML, ... (I can easily provide you an XML-Representation of the xtext-Spec I attached) is the important thing I need to make my tooling cleverer. Tom Am 06.07.12 19:21, schrieb David Grieve: > There is no such document, just the cssref html document. > > I would like, however, to get all of the tables and such that describe > the css properties out of that document and into proper javadoc for the > corresponding JavaFX properties - perhaps with an @css javadoc tag or an > @css annotation. I'm not sure if that would hurt or help. > > On Jun 19, 2012, at 11:59 AM, Richard Bair wrote: > >> Hi Tom, >> >> I don't think we have a structured document with this information, but >> it sounds useful! David is on Vacation but he should be involved when >> he gets back hopefully later this week or next week. >> >> Cheers >> Richard >> >> On Jun 19, 2012, at 1:38 AM, Tom Schindl wrote: >> >>> Hi, >>> >>> Is there some structured text document one can use to teach IDEs hover >>> documentation of CSS-Attribute, or do I need to extract those >>> information from the published HTML-CSS-Documentation? >>> >>> My hope is that this document is generated from some more structured >>> resource I can use in my Eclipse integration. If there's no such >>> document, I'd like to contribute in creating such a meta-format and >>> generate the HTML-Document from it. Any netbeans people here who'd like >>> to work with me on this? >>> >>> Tom >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 >> > > > 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 > -- 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 -------------- next part -------------- package javafx { // type boolean { // // }, type t_number { DOUBLE }, enumtype unit_symbols { 'px', 'mm', 'cm', 'in', 'pt','pc','em','ex' }, enumtype angle_symbols { 'deg','rad','grad','turn' }, type size { | | }, type length { []? }, type percentage { '%' }, type angle { }, type point { [ ] | [ | ] }, type color_stop { [ | ]? }, type uri { STRING // url ( [\"\']?
[\"\']? ) }, enumtype blur_type { 'gaussian','one-pass-box','three-pass-box','two-pass-box' }, type effect { | }, type dropshadow { // dropshadow( ',' ',' ',' ',' ',' ) }, type innershadow { }, type font_family { STRING }, type font_size { }, enumtype font_style { 'normal','italic','oblique' }, enumtype font_weight { 'normal','bold','bolder','lighter', '100','200','300','400','500','600','700','800','900' }, type font { [ || ]? // }, type paint { | | }, type linear_gradient { STRING //NOT SUPPORTED linear-gradient( [ [from to ] | [ to ], ]? [ [ repeat | reflect ], ]? [, ]+) }, type radial_gradient { STRING //NOT SUPPORTED radial-gradient([ focus-angle , ]? [ focus-distance , ]? [ center , ]? radius [ | ] [ [ repeat | reflect ], ]? [, ]+) }, type color { | | | | }, enumtype named_color { 'aliceblue', 'antiquewhite' // .... }, type looked_up_color { STRING }, type rgb_color { STRING }, type hsb_color { STRING }, type color_function { STRING } package stage { Window { }, PopupWindow extends Window { } } package scene { enumtype fx_cursor { 'null', 'crosshair', 'default', 'hand', 'move', 'e-resize', 'h-resize', 'ne-resize', 'nw-resize', 'n-resize', 'se-resize', 'sw-resize','s-resize', 'w-resize', 'v-resize', 'text', 'wait' } /# # All attributes that can be applied to Nodes #/ Node { /# # Some blurb about the blend mode #/ enum '-fx-blend-mode' default 'null' { /# # blurb about add #/ 'add', 'blue', 'color-burn', 'color-dodge', 'darken', 'difference', 'exclusion', 'green', 'hard-light', 'lighten', 'multiply', 'overlay', 'red', 'screen', 'soft-light', 'src-atop', 'src-in', 'src-out', 'src-over' }, '-fx-cursor' default 'null' { | }, boolean '-fx-focus-traversable' default false, /# # Opacity can be thought of conceptually as a postprocessing operation. # Conceptually, after the node (including its descendants) is rendered into an # RGBA offscreen image, the opacity setting specifies how to blend the offscreen # rendering into the current composite rendering. #/ number '-fx-opacity' default 0d range 0d to 1d, /# # This is the angle of the rotation in degrees. # Zero degrees is at 3 o'clock (directly to the right). # Angle values are positive clockwise. Rotation is about the center. #/ number '-fx-rotate' default 0d, /# # scale about the center #/ unsigned number '-fx-scale-x' default 1l, /# # scale about the center #/ unsigned number '-fx-scale-y' default 1l, /# # scale about the center #/ unsigned number '-fx-scale-z' default 1l, enum 'visibility' default 'visible' { 'visible','hidden','collapse','inherit' }, /# # applies when the disabled variable is true #/ pseudoclass 'disabled', /# # applies when the focused variable is true #/ pseudoclass 'focused', /# # applies when the hover variable is true #/ pseudoclass 'hover', /# # applies when the pressed variable is true #/ pseudoclass 'pressed', /# # apples when the mnemonic affordance (typically an underscore) should be shown. #/ pseudoclass 'show-mnemonic' }, Parent extends Node { }, Group extends Parent { } package image { ImageView extends Node { '-fx-image' default 'null' { } } } package layout { enumtype bg_pos_1 { 'left','center','right' }, enumtype bg_pos_2 { 'top','center','bottom' }, enumtype bg_pos_3 { 'center', 'center' }, enumtype bg_pos_4 { 'left' , 'right' }, enumtype bg_pos_5 { 'top' , 'bottom' }, type bg_position { [[ | ] [ | ]?] | [ [ | []? ] || [ | []? ]] }, enumtype repeat_vals_1 { 'repeat-x','repeat-y' }, enumtype repeat_vals_2 { 'repeat','space','round','stretch','no-repeat' }, type repeat_style { [ | ]{1,2} }, enumtype bg_size_1 { 'auto','auto' }, enumtype bg_size_2 { 'cover','contain','stretch' }, type bg_size { [ | ]{1,2} | }, enumtype dash_style_1 { 'none','solid','dotted','dashed' }, type dash_style { //NOT SUPPORTED| segments( , [',' ]*) }, enumtype border_style_1 { 'centered','inside','outside' }, type border_style { /*NOT SUPPORTED['phase' ]?*/ []? //NOT SUPPORTED [phase ]? [centered | inside | outside]? [line-join [miter | bevel | round]]? [line-cap [square | butt | round]]? // --- // [ none | solid | dotted | dashed | segments( , [, ]*) ] } Region extends Parent { /# # A series of paint values separated by commas. #/ '-fx-background-color' default 'null' { //NOT SUPPORTED[ , ]* }, /# # A series of size values or sets of four size values, separated by commas. A single size value means all insets are the same. Otherwise, the four values for each inset are given in the order top, right, bottom, left. Each comma-separated value or set of values in the series applies to the corresponding background color. #/ '-fx-background-insets' default 'null' { //NOT SUPPORTED | [ , [ | ] ]* }, /# # A series of radius values or sets of four radius values, separated by commas. A single radius value means the radius of all four corners is the same. Otherwise, the four values in the set determine the radii of the top-left, top-right, bottom-right, and bottom-left corners, in that order. Each comma-separated value or set of values in the series applies to the corresponding background color. #/ '-fx-background-radius' default 'null' { //NOT SUPPORTED | [ , [ | ] ]* }, /# # A series of image URIs separated by commas. #/ '-fx-background-image' default 'null' { //NOT SUPPORTED [ , ]* }, '-fx-background-position' default 'null' { //NOT SUPPORTED [ , ]* }, '-fx-background-repeat' default 'null' { //NOT SUPPORTED [ , ]* }, '-fx-background-size' default 'null' { //NOT SUPPORTED [ , ]* }, '-fx-border-color' default 'null' { //NOT SUPPORTED | [ , [ | ] ]* }, '-fx-border-insets' default 'null' { //NOT SUPPORTED| [ , [ | ] ]* }, '-fx-border-radius' default 'null' { //NOT SUPPORTED | [ , [ | ] ]* }, '-fx-border-style' default 'null' { // NOT SUPPORTED[ , ]* }, '-fx-border-width' default 'null' { //NOT SUPPORTED| [ , [ | ] ]* }, '-fx-border-image-source' default 'null' { //NOT SUPPORTED [ , ]* }, '-fx-border-image-insets' default 'null' { //NOT SUPPORTED | [ , [ | ] ]* }, '-fx-border-image-repeat' default 'null' { //NOT SUPPORTED[ , ]* }, '-fx-border-image-slice' default 'null' { [ | ] //NOT SUPPORTED'fill'? [ , [ | ] 'fill'? ]* }, '-fx-border-image-width' default 'null' { // NOT SUPPORTED| [ , [ | ] ]* }, '-fx-padding' default 'null' { | }, boolean '-fx-position-shape' default true, boolean '-fx-scale-shape' default true, string '-fx-shape' default 'null', boolean '-fx-snap-to-pixel' default true // '-fx-background-fills' // '-fx-background-images' // '-fx-stroke-borders' // '-fx-image-borders' }, Pane { }, AnchorPane extends Pane { }, BorderPane extends Pane { }, FlowPane extends Pane { '-fx-hgap' default '0' { }, '-fx-vgap' default '0' { }, enum '-fx-alignment' default 'top-left' { 'top-left', 'top-center', 'top-right', 'center-left', 'center', 'center-right', 'bottom-left', 'bottom-center', 'bottom-right', 'baseline-left', 'baseline-center', 'baseline-right' }, enum '-fx-column-halignment' default 'center' { 'left', 'center', 'right' }, enum '-fx-row-valignment' default 'center' { 'top', 'center', 'baseline', 'bottom' }, enum '-fx-orientation' default 'horizontal' { 'horizontal', 'vertical' } }, GridPane extends Pane { '-fx-hgap' default '0' { }, '-fx-vgap' default '0' { }, enum '-fx-alignment' default 'top-left' { 'top-left', 'top-center', 'top-right', 'center-left', 'center', 'center-right', 'bottom-left', 'bottom-center', 'bottom-right', 'baseline-left', 'baseline-center', 'baseline-right' }, boolean '-fx-grid-lines-visible' default false }, HBox extends Pane { '-fx-spacing' default '0' { }, enum '-fx-alignment' default 'top-left' { 'top-left', 'top-center', 'top-right', 'center-left', 'center', 'center-right', 'bottom-left', 'bottom-center', 'bottom-right', 'baseline-left', 'baseline-center', 'baseline-right' }, boolean '-fx-fill-height' default false }, StackPane extends Pane { enum '-fx-alignment' default 'top-left' { 'top-left', 'top-center', 'top-right', 'center-left', 'center', 'center-right', 'bottom-left', 'bottom-center', 'bottom-right', 'baseline-left', 'baseline-center', 'baseline-right' } }, TilePane extends Pane { enum '-fx-orientation' default 'horizontal' { 'horizontal','vertical' }, unsigned integer '-fx-pref-rows' default 5, unsigned integer '-fx-pref-columns' default 5, '-fx-pref-tile-width' default '-1' { }, '-fx-pref-tile-height' default '-1' { }, '-fx-hgap' default '0' { }, '-fx-vgap' default '0' { }, enum '-fx-alignment' default 'top-left' { 'top-left', 'top-center', 'top-right', 'center-left', 'center','center-right', 'bottom-left', 'bottom-center', 'bottom-right', 'baseline-left', 'baseline-center', 'baseline-right' }, enum '-fx-tile-alignment' default 'center' { 'top-left', 'top-center', 'top-right', 'center-left', 'center','center-right', 'bottom-left', 'bottom-center', 'bottom-right', 'baseline-left', 'baseline-center', 'baseline-right' } }, VBox { '-fx-spacing' default '0' { }, enum '-fx-alignment' default 'top-left' { 'top-left', 'top-center', 'top-right', 'center-left', 'center','center-right', 'bottom-left', 'bottom-center', 'bottom-right', 'baseline-left', 'baseline-center', 'baseline-right' }, boolean '-fx-fill-width' default true } } package shape { Shape extends Node { '-fx-fill' default 'BLACK' { }, boolean '-fx-smooth' default true, '-fx-stroke' default 'null' { }, enum '-fx-stroke-type' default 'centered' { 'inside','outside','centered' }, '-fx-stroke-dash-array' default 'null' { [ ]+ }, number '-fx-stroke-dash-offset' default 0d, enum '-fx-stroke-line-cap' default 'square' { 'square','butt','round' }, enum '-fx-stroke-line-join' default 'miter' { 'miter','bevel','round' }, number '-fx-stroke-miter-limit' default 10d, '-fx-stroke-width' default '1' { } }, Arc extends Shape { }, Circle extends Shape { }, CubicCurve extends Shape { }, Ellipse extends Shape { }, Line extends Shape { }, Path extends Shape { }, Polygon extends Shape { }, QuadCurve extends Shape { }, Rectangle extends Shape { '-fx-arc-height' default '0' { }, '-fx-arc-width' default '0' { } }, SVGPath extends Shape { } } package text { Text extends shape.Shape { '-fx-font' default 'Font.DEFAULT' { }, enum '-fx-font-smoothing-type' default 'gray' { 'gray','lcd' }, boolean '-fx-strikethrough' default false, enum '-fx-text-alignment' default 'left' { 'left','center','right','justify' }, enum '-fx-text-origin' default 'baseline' { 'baseline','top','bottom' }, boolean '-fx-underline' default false } } package control { Control extends Parent { string '-fx-skin' default 'null' }, Labeled extends Control { enum '-fx-alignment' default 'top-left' { 'top-left', 'top-center', 'top-right', 'center-left', 'center', 'center-right', 'bottom-left', 'bottom-center', 'bottom-right', 'baseline-left','baseline-center', 'baseline-right' }, enum '-fx-text-alignment' default 'left' { 'left','center','right','justify' }, enum '-fx-text-overrun' default 'ellipsis' { 'center-ellipsis', 'center-word-ellipsis', 'clip', 'ellipsis', 'leading-ellipsis', 'leading-word-ellipsis', 'word-ellipsis' }, boolean '-fx-wrap-text' default false, '-fx-font' default 'null' { }, boolean '-fx-underline' default false, '-fx-graphic' default 'null' { }, enum '-fx-content-display' default 'left' { 'top', 'right', 'bottom', 'left', 'center', 'right', 'graphic-only', 'text-only' }, '-fx-graphic-text-gap' default '4' { }, '-fx-label-padding' default '0,0,0,0' { | }, '-fx-text-fill' default 'BLACK' { } }, ButtonBase extends Labeled { pseudoclass 'armed' }, Accordion extends Control { }, Button extends ButtonBase { pseudoclass 'cancel', pseudoclass 'default' }, Cell extends Labeled { '-fx-cell-size' default '15' { } pseudoclass 'empty', pseudoclass 'filled', pseudoclass 'selected' substructure Labeled 'text' }, CheckBox extends ButtonBase { pseudoclass 'selected', pseudoclass 'determinate', pseudoclass 'indeterminate' substructure layout.StackPane 'box' { substructure layout.StackPane 'mark' } }, CheckMenuItem extends Control { pseudoclass 'selected' }, ChoiceBox extends Control { substructure layout.Region 'open-button' { substructure layout.Region 'arrow' } }, ComboBoxBase extends Control { pseudoclass 'editable', pseudoclass 'showing', pseudoclass 'armed' substructure layout.StackPane 'arrow-button' { substructure layout.StackPane 'arrow' } }, ComboBox extends ComboBoxBase { substructure ListCell 'list-cell', substructure TextField 'text-input', substructure PopupControl 'combo-box-popup' { substructure ListView 'list-view' { substructure ListCell 'list-cell' } } }, Hyperlink extends ButtonBase { pseudoclass 'visited' substructure Label 'label' }, IndexedCell extends Cell { pseudoclass 'even', pseudoclass 'odd' }, Label extends Labeled { }, ListCell extends IndexedCell { }, ListView extends Control { enum '-fx-orientation' default 'horizontal' { 'horizontal','vertical' } pseudoclass 'horizontal', pseudoclass 'vertical' }, Menu extends MenuItem { pseudoclass 'showing' }, MenuBar extends Control { boolean '-fx-use-system-menu-bar' default false substructure Menu 'menu' }, MenuButton extends ButtonBase { pseudoclass 'openvertically', pseudoclass 'showing' }, MenuItem extends Control { }, PasswordField extends TextField { }, PopupControl extends stage.PopupWindow { }, ProgressBar extends ProgressIndicator { }, ProgressIndicator extends Control { '-fx-progress-color' default 'dodgerblue' { } pseudoclass 'determinate', pseudoclass 'indetermindate', substructure layout.StackPane 'indicator', substructure layout.StackPane 'progress', substructure text.Text 'percentage', substructure layout.StackPane 'tick' }, RadioButton extends ToggleButton { substructure layout.Region 'radio' { substructure layout.Region 'dot' }, substructure Label 'label' }, RadioMenuItem extends MenuItem { pseudoclass 'selected' }, ScrollBar extends Control { enum '-fx-orientation' default 'horizontal' { 'horizontal','vertical' }, number '-fx-block-increment' default 10d, number '-fx-unit-increment' default 1d pseudoclass 'vertical', pseudoclass 'horizontal' substructure layout.StackPane 'decrement-button' { substructure layout.StackPane 'decrement-arrow' }, substructure layout.StackPane 'track', substructure layout.StackPane 'thumb', substructure layout.StackPane 'increment-button' { substructure layout.StackPane 'increment-arrow' } }, ScrollPane extends Control { boolean '-fx-fit-to-width' default false, boolean '-fx-fit-to-height' default false, boolean '-fx-pannable' default false, enum '-fx-hbar-policy' default 'always' { 'never','always','as-needed' }, enum '-fx-vbar-policy' default 'always' { 'never','always','as-needed' } pseudoclass 'pannable', pseudoclass 'fitToWidth', pseudoclass 'fitToHeight' substructure ScrollBar 'scroll-bar:vertical', substructure ScrollBar 'scroll-bar:horizontal', substructure layout.StackPane 'corner' }, Separator extends Control { enum '-fx-orientation' default 'horizontal' { 'horizontal','vertical' }, enum '-fx-halignment' default 'center' { 'left','center','right' }, enum '-fx-valignment' default 'center' { 'top','center','baseline','bottom' } pseudoclass 'horizontal', pseudoclass 'vertical' substructure layout.Region 'line' }, Slider extends Control { enum '-fx-orientation' default 'horizontal' { 'horizontal','vertical' }, boolean '-fx-show-tick-labels' default false, boolean '-fx-show-tick-marks' default false, number '-fx-major-tick-unit' default 25d, integer '-fx-minor-tick-count' default 3, boolean '-fx-show-tick-labels' default false, boolean '-fx-snap-to-ticks' default false, integer '-fx-block-increment' default 10 pseudoclass 'horizontal', pseudoclass 'vertical' substructure chart.NumberAxis 'axis', substructure layout.Region 'track', substructure layout.Region 'thumb' }, SplitMenuButton extends MenuButton { }, SplitPane extends Control { enum '-fx-orientation' default '' { 'horizontal','vertical' } pseudoclass 'horizontal', pseudoclass 'vertical' substructure layout.StackPane 'split-pane-divider' { substructure layout.StackPane 'vertical-grabber', substructure layout.StackPane 'horizontal-grabber' } }, Tab { }, TabPane extends Control { number '-fx-tab-min-width' default 0d, number '-fx-tab-max-width' default 100000000d, //TODO Double.MAX number '-fx-tab-min-height' default 0d, number '-fx-tab-max-height' default 100000000d, //TODO Double.MAX pseudoclass 'top', pseudoclass 'right', pseudoclass 'bottom', pseudoclass 'left' substructure layout.StackPane 'tab-header-area' { substructure layout.StackPane 'headers-region', substructure layout.StackPane 'tab-header-background', substructure layout.StackPane 'control-buttons-tab' { substructure layout.Pane 'tab-down-button' { substructure layout.StackPane 'arrow' } }, substructure Tab 'tab' { substructure Label 'tab-label', substructure layout.StackPane 'tab-close-button' } }, substructure layout.StackPane 'tab-content-area' }, TableView extends Control { pseudoclass 'cell-selection', pseudoclass 'row-selection' substructure layout.Region 'column-resize-line', substructure layout.Region 'column-overlay', substructure layout.StackPane 'placeholder', substructure layout.StackPane 'column-header-background' { substructure layout.StackPane 'nested-column-header' { substructure Label 'column-header' // Not documented!! }, substructure layout.Region 'filler', substructure layout.StackPane 'show-hide-columns-button' { substructure layout.StackPane 'show-hide-column-image' }, substructure layout.StackPane 'column-drag-header' { substructure Label 'label' } } }, TextArea extends TextInputControl { substructure ScrollPane 'scroll-pane' { substructure layout.Region 'content' } }, TextInputControl extends Control { '-fx-font' default 'null' { }, '-fx-text-fill' default 'black' { }, '-fx-prompt-text-fill' default 'gray' { }, '-fx-highlight-fill' default 'dodgerblue' { }, '-fx-highlight-text-fill' default 'white' { }, boolean '-fx-display-caret' default true pseudoclass 'readonly' }, TextField extends TextInputControl { enum '-fx-alignment' default 'center-left' { 'top-left','top-center','top-right','center-left', 'center','center-right','bottom-left', 'bottom-center','bottom-right', 'baseline-left','baseline-center','baseline-right' } }, TitledPane extends Labeled { boolean '-fx-animated' default true, boolean '-fx-collapsible' default true pseudoclass 'expanded', pseudoclass 'collapsed' substructure layout.HBox 'title' { substructure Label 'text', substructure layout.StackPane 'arrow-button' { substructure layout.StackPane 'arrow' } }, substructure layout.StackPane 'content' }, ToggleButton extends ButtonBase { pseudoclass 'selected' }, ToolBar extends Control { enum '-fx-orientation' default 'horizontal' { 'horizontal','vertical' } pseudoclass 'horizontal', pseudoclass 'vertical' substructure layout.StackPane 'tool-bar-overflow-button' { substructure layout.StackPane 'arrow' } }, Tooltip extends PopupControl { enum '-fx-text-alignment' default 'left' { 'left','center','right','justify' }, enum '-fx-text-overrun' default 'ellipsis' { 'center-ellipsis','center-word-ellipsis','clip', 'ellipsis','leading-ellipsis','leading-word-ellipsis', 'word-ellipsis' }, boolean '-fx-wrap-text' default false, '-fx-graphic' default 'null' { }, enum '-fx-content-display' default 'left' { 'top','right','bottom','left','center','right','graphic-only', 'text-only' }, '-fx-graphic-text-gap' default '4' { }, '-fx-font' default 'Font.DEFAULT' { } substructure Label 'label', substructure layout.StackPane 'page-corner' }, TreeCell extends IndexedCell { '-fx-indent' default '10' { } pseudoclass 'expanded', pseudoclass 'collapsed' }, TreeView extends Control { } } package chart { // com.sun.javafx.chart.LegendItem LegendItem { }, AreaChart extends XYChart { substructure Node 'chart-series-area-line series default-color', substructure shape.Path 'chart-series-area-fill series default-color', substructure shape.Path 'chart-area-symbol series data default-color', substructure LegendItem 'chart-area-symbol series area-legend-symbol default-color' }, BarChart extends XYChart { number '-fx-bar-gap' default 4d, number '-fx-category-gap' default 10d // substructure 'bar-chart', substructure Node 'chart-bar series data default-color', substructure LegendItem 'chart-bar series bar-legend-symbol default-color' }, BubbleChart extends XYChart { substructure Node 'chart-bubble series data default-color', substructure LegendItem 'chart-bubble series bubble-legend-symbol default-color' }, Chart extends layout.Region { enum '-fx-legend-side' default 'bottom' { 'top','left','bottom','right' //TODO Not documented }, boolean '-fx-legend-visible' default true, enum '-fx-title-side' default 'top' { 'top','left','bottom','right' //TODO Not documented } substructure control.Label 'chart-title', substructure layout.Pane 'chart-content' }, LineChart extends XYChart { boolean '-fx-symbol-visible' default true substructure Node 'chart-series-line series default-color', substructure Node 'chart-line-symbol series data default-color', substructure LegendItem 'chart-line-symbol series default-color' }, ScatterChart extends XYChart { substructure Node 'chart-symbol series data default-color', substructure LegendItem 'chart-symbol series default-color' }, PieChart extends Chart { boolean '-fx-clockwise' default true, boolean '-fx-pie-label-visible' default true, '-fx-label-line-length' default '20' { }, number '-fx-start-angle' default 0d substructure Node 'chart-pie data default-color', substructure shape.Path 'chart-pie-label-line', substructure text.Text 'chart-pie-label', substructure LegendItem 'pie-legend-symbol' }, XYChart extends Chart { boolean '-fx-alternative-column-fill-visible' default true, boolean '-fx-alternative-row-fill-visible' default true, boolean '-fx-horizontal-grid-lines-visible' default true, boolean '-fx-horizontal-zero-line-visible' default true, boolean '-fx-vertical-grid-lines-visible' default true, boolean '-fx-vertical-zero-line-visible' default true substructure Group 'plot-content', substructure layout.Region 'chart-plot-background', substructure shape.Path 'chart-alternative-column-fill', substructure shape.Path 'chart-alternative-row-fill', substructure shape.Path 'chart-vertical-grid-lines', substructure shape.Path 'chart-horizontal-grid-lines', substructure shape.Line 'chart-vertical-zero-line', substructure shape.Line 'chart-horizontal-zero-line' }, Axis extends layout.Region { enum '-fx-side' default 'null' { 'top','left','bottom','right' //TODO Not documented }, '-fx-tick-length' default '8' { }, '-fx-tick-label-font' default '8 system' { }, '-fx-tick-label-fill' default '8 system' { }, '-fx-tick-label-gap' default '8 system' { }, boolean '-fx-tick-mark-visible' default true, boolean '-fx-tick-labels-visible' default true substructure text.Text 'axis-label', substructure shape.Path 'axis-tick-mark', substructure text.Text 'tick-mark' }, ValueAxis extends Axis { '-fx-minor-tick-length' default '5' { }, '-fx-minor-tick-count' default '5' { }, boolean '-fx-minor-tick-visible' default true substructure shape.Path 'axis-minor-tick-mark' }, NumberAxis extends ValueAxis { number '-fx-tick-unit' default 5d }, CategoryAxis extends Axis { number '-fx-start-margin' default 5d, number '-fx-end-margin' default 5d, boolean '-fx-gap-start-and-end' default true }, Legend extends layout.Region { substructure control.Label 'chart-legend-item', substructure Node 'chart-legend-item-symbol' } } } } -------------- next part -------------- grammar at.bestsolution.efxclipse.tooling.css.Definition with org.eclipse.xtext.xbase.Xbase // hidden(WS, SL_COMMENT) generate definition "http://www.bestsolution.at/efxclipse/tooling/css/Definition" CSSDefs: imports+=Import* packageDef=PackageDeclaration ; Import: 'import' importedNamespace=QualifiedNameWithWildCard; PackageDeclaration: 'package' name=QualifiedName '{' typDefs+=TypeDef? (',' typDefs+=TypeDef)* elementDefs+=ElementDef? (',' elementDefs+=ElementDef)* subpackages+=PackageDeclaration* '}'; enum PrimTypes: STRING | INT | DOUBLE | BOOL ; TypeDef: GenericTypeDef | EnumTypeDef ; GenericTypeDef: doc=DOCU? 'type' name=ValidID '{' typeDef=TypeValue '}' ; EnumTypeDef: doc=DOCU? 'enumtype' name=ValidID '{' values+=EnumValue (',' values+=EnumValue)+ '}' ; TypeValue: TypeDefValue | PrimValue ; TypeDefValue: typeRule=TypeRule ; PrimValue: v=PrimTypes ; ElementDef: doc=DOCU? name=ValidID ('extends' superElements+=[ElementDef|QualifiedName] (',' superElements+=[ElementDef|QualifiedName])*)? '{' properties+=Property? (',' properties+=Property)* pseudoClasses+=PseudoClass? (',' pseudoClasses+=PseudoClass)* subelements+=SubElement? (',' subelements+=SubElement)* '}' ; SubElement: doc=DOCU? 'substructure' type=[ElementDef|QualifiedName] name=STRING ('{' subelements+=SubElement? (',' subelements+=SubElement)* '}')? ; Property: GenericProperty | EnumProperty | NumberProperty | BooleanProperty | StringProperty | IntegerProperty ; PseudoClass: doc=DOCU? 'pseudoclass' name=STRING ; GenericProperty: doc=DOCU? name=STRING 'default' defaultValue=STRING '{' typeRule=TypeRule '}' ; TypeRule: segment=Segment typeSegment+=SubRule* ; SubRule: TypeRuleSegment | TypeGroupSegment | TypeKeySegment ; TypeRuleSegment: op=('||'|'|') segment=Segment ; Segment: TypeSegment | TypeFunctionSegment | TypeGroupSegment ; TypeSegment: ('<' type+=[TypeDef|ValidID]'>')+ ; TypeKeySegment: keyword=STRING ('?')? ; TypeFunctionSegment: function=ValidID '(' type=[TypeDef|ValidID] ')' ; TypeGroupSegment: '[' sep=STRING? rule=TypeRule ']' ('*'|'+'|'?'|('{' min=INT (','max=INT)?'}'))? ; EnumProperty: doc=DOCU? 'enum' name=STRING 'default' defaultValue=STRING '{' values+=EnumValue (',' values+=EnumValue)+ '}' ; EnumValue: doc=DOCU? value=STRING ; NumberProperty: doc=DOCU? unsigned?='unsigned'? 'number' name=STRING 'default' defaultValue=DECIMAL ('range' min=DECIMAL 'to' max=DECIMAL)? ; IntegerProperty: doc=DOCU? unsigned?='unsigned'? 'integer' name=STRING 'default' defaultValue=INT ('range' min=INT 'to' max=INT)? ; BooleanProperty: doc=DOCU? 'boolean' name=STRING 'default' defaultValue=('true'|'false') ; StringProperty: doc=DOCU? 'string' name=STRING 'default' defaultValue=STRING ; QualifiedNameWithWildCard : QualifiedName ('.' '*')?; terminal DOCU: '/#' -> '#/'; /*Operation: 'op' name=ValidID '(' (params+=FullJvmFormalParameter (',' params+=FullJvmFormalParameter)*)? ')' ':' type=JvmTypeReference body=XBlockExpression;*/ terminal ID: '^'? ('a'..'z'|'A'..'Z'|'$'|'_') ('a'..'z'|'A'..'Z'|'$'|'_'|'0'..'9')*; From richard.bair at oracle.com Wed Jul 11 09:16:51 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 11 Jul 2012 09:16:51 -0700 Subject: State of OpenJFX In-Reply-To: References: Message-ID: <2C0ED682-E3F4-4609-9A90-1716089D6453@oracle.com> Hi Mario, Yes it is true a lot of the code is still internal (specifically Glass and Prism) but a lot of the core APIs are all open source now (scene graph and controls and charts), as well as the modifications to gstreamer and webkit for our media & web engines. We've also released the JemmyFX testing framework and hope to release more of the SQE tests which rely on it. Hoping to get the rest out there soon. Thanks Richard On Jul 11, 2012, at 1:02 AM, Mario Torre wrote: > Hi all! > > It has been a bit that I don't follow the development of JavaFX, so I > would like if possible to get a small overview of the state of the > code. > > I see from the development page that we still need quite some bits > from the closed repository to be able to build OpenJFX. > > What is the state of that, and how much closed code we still need to > get the JFX experience? Any estimation when the rest will released? > > Thanks a lot! > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From pavel.safrata at oracle.com Wed Jul 11 09:31:57 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 11 Jul 2012 18:31:57 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFD9E47.7040403@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFD9E47.7040403@geomatys.fr> Message-ID: <4FFDAA7D.2000800@oracle.com> On 11.7.2012 17:39, Martin Desruisseaux wrote: > Le 11/07/12 16:57, Pavel Safrata a ?crit : >> If we are going this way, shouldn't we do also this? >> * Rename 'concatenate' as 'prepend' >> * Rename 'preConcatenate' as 'append' > Yes, I think it would bring more uniformity in the method naming. > >> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) > I missed that method... What would its function? Or are we are talking > about something like a 'getTransformCoefficients()' method? This method is similar to concatenate (prepend) except that it is defined on parent Transform class and returns the result in a new Transform instance (allows for multiplicating arbitrary - possibly immutable - transfroms). > > >> As a black-box transformation composing this makes sense. As a matrix >> algebra, it may be also confusing: tA.append(tB) means matrix >> multiplication 'B x A', does it sound good? Maybe yes, I'm not sure. >> Anyway, so far the best proposal I think. > Yes, I realize that a risk of confusion may exist. We may need to > stress out in the javadoc that "append" is not "multiply". Indeed, if > the "append" method was defined in the parent Transform class and if > that parent was the base class of generic transformations (not just > linear transformations), then the "append" method would actually not > be implemented as a matrix multiplication except in the special case > of linear transformations. I don't have any better idea. Writing a clear javadoc is probably the only thing we can do. As the methods will be defined only on Affine class, we should probably mention specifically the relationship with multiplication, maybe even a warning for J2D developers that this may work the other way than they're used to.. > > >>> I don't have experience in this area. But naively, it seems to we >>> that it would be better to be notified only after the full matrix >>> has been updated... >> Yes, I would also pick this option. It's just that it would mean >> writing much more complicated (and a bit less effective) code so the >> question is whether or not you think it is important. > I don't have a use case where I would like to listen to individual > coefficient changes. It seems to me that I would rather listen to > whatever property contains the Transform object as a whole. > Consequently, I don't think that the atomicity of Affine operations > would have much incidence (assuming that there is some way - other > than listening to individual coefficients - to be informed that the > matrix as a whole has changed). Unfortunately I don't think there is a way to listen for changes on an object other than listening on all its properties. In my opinion this is quite a big issue and it's been bothering me for some time already. I've heard that some utilities are planned for that but still I want to file a feature request for some better mechanism, hopefully this email gives me the impulse to finally do it. Anyway, I should probably not give up on the (quite obviously) better API just because of implementation complexity. Will try to make the changes atomic. Thanks, Pavel > > Martin > From eva.krejcirova at oracle.com Wed Jul 11 09:43:08 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 11 Jul 2012 18:43:08 +0200 Subject: Extending builders: PathBuilder Message-ID: <4FFDAD1C.2010501@oracle.com> Hi, based on RT-19266, I would like to add following methods into PathBuilder: public PathBuilder moveTo(double x, double y) public PathBuilder lineTo(double x, double y) public PathBuilder hLineTo(double x) public PathBuilder vLineTo(double y) public PathBuilder arcTo(double radiusX, double radiusY, double xAxisRotation, double x, double y, boolean largeArcFlag, boolean sweepFlag) public PathBuilder cubicCurveTo(double controlX1, double controlY1, double controlX2, double controlY2, double x, double y) public PathBuilder quadCurveTo(double controlX, double controlY, double x, double y) public PathBuilder closePath() 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. However, this means, that even PathBuilder.create().elements(new MoveTo(10,10)).elements(new LineTo(100,100)).elemens(new ClosePath()).build(); creates this same path too. This unfortunately changes the current behavior (currently the path would only contain closePath element), and it is not consistent with our other methods in builders which take collection/vararg as an argument which only remember the collection which was added as last: Group g = GroupBuilder.create().children(new Rectangle(200,200,100,100)).children(new Circle(300,300,20, Color.RED)).build(); The group contains only Circle, not the Rectangle. 2.) Same as 1.), but only the last elements() call would be taken into account e.g. PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); will contain MoveTo, LineTo, ClosePath in that order PathBuilder.create().elements(new MoveTo(10,10)).lineTo(100,100).elemens(new ClosePath()).build(); will contain LineTo, ClosePath 3.) The approach suggested in the bug which first adds path elements from elements() call, then everything else regardless when the elements() was called e.g. e.g. PathBuilder.create().moveTo(10,10).lineTo(100,100).elemens(new ClosePath()).build(); will contain ClosePath, MoveTo, LineTo in this order 4.) Another suggested option is that 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 This is the option which I tend to lean towards now. What's the public opinion on this? Thanks, Eva From hang.vo at oracle.com Wed Jul 11 12:28:43 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 11 Jul 2012 19:28:43 +0000 Subject: hg: openjfx/2.2/master/rt: 53 new changesets Message-ID: <20120711192929.88AAA47F91@hg.openjdk.java.net> Changeset: 9a2b4524a317 Author: David Grieve Date: 2012-06-26 12:20 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9a2b4524a317 RT-22565: parent stylesheets may be in the default stylesheet container ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 385a5b779565 Author: David Grieve Date: 2012-06-27 18:52 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/385a5b779565 Backed out changeset 9a2b4524a317 ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: d20976d5d10f Author: Paru Somashekar Date: 2012-06-28 10:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d20976d5d10f [TEST ONLY] remove @ignore for some chart tests - they pass now. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java Changeset: 9ed69f9a93bb Author: jgiles Date: 2012-06-27 16:03 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9ed69f9a93bb [DOC ONLY] Update to cells package documentation. ! javafx-ui-controls/src/javafx/scene/control/cell/package.html Changeset: a42d594cef37 Author: jgiles Date: 2012-06-29 09:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a42d594cef37 RT-22676: Embedded: Ensemble sample throws an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 4484722efef7 Author: jgiles Date: 2012-06-29 09:39 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4484722efef7 RT-2295: Non-editable ComboBox does not show prompt text when it should ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 0d6d4249cce9 Author: jgiles Date: 2012-06-29 09:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0d6d4249cce9 RT-22908: Column width of data rows does not align with header column width ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: d17e7e409769 Author: jgiles Date: 2012-06-29 09:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d17e7e409769 RT-22875: CheckBoxTreeItem: indeterminate state does not affect rendering ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java Changeset: 480b6f9324a7 Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/480b6f9324a7 RT-22954: PieChart with rollover has picking issues ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: a81a3544722e Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a81a3544722e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 29a0e209d81f Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/29a0e209d81f RT-22937: Selection issue on editors based on ComboBox with dynamic item list ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: 2d7d2be9cdb7 Author: Kinsley Wong Date: 2012-06-28 14:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2d7d2be9cdb7 RT-22928: ClassCastException in TilePane while using the CSS style -fx-pref-columns ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java Changeset: feb33f9ce89b Author: Kinsley Wong Date: 2012-06-28 14:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/feb33f9ce89b RT-22925: When closing a Tab inside a TabPane, the selection model does not return the correct Tab. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: f90f6b0e27a4 Author: jgiles Date: 2012-06-29 09:47 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/f90f6b0e27a4 RT-22076: CSS: Treat style class as a bit mask in Selector for better performance on selector matching. ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 90b96294241a Author: jgiles Date: 2012-06-29 09:49 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/90b96294241a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 68f2523b8433 Author: David Grieve Date: 2012-06-28 18:21 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/68f2523b8433 RT-22076: backout patch pushed by jgiles in favor of updated patch ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 29a95b63c732 Author: David Grieve Date: 2012-06-28 18:21 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/29a95b63c732 RT-22076: create a bitmask from style class strings to speed up SimpleSelector.isSubsetOf method. ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: ad5af91935ff Author: David Grieve Date: 2012-06-29 13:18 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ad5af91935ff RT-22565: parent stylesheets may be in the default stylesheet container ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 121a87ea1d97 Author: David Grieve Date: 2012-07-02 14:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/121a87ea1d97 RT-22076: backout patch for RT-22076 until after integration ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: 80668368c867 Author: David Grieve Date: 2012-07-02 14:16 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/80668368c867 RT-23140: NPE in getStyleHelper if stylesheet fails to load. Check if stylesheet is null and also check if stylesheet List is null or empty. If so, move on to next stylesheet. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StylesheetTest.java Changeset: 3e1c680c584d Author: Kinsley Wong Date: 2012-07-02 12:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3e1c680c584d [DOC-ONLY] Pagination control has no entry in cssref.html doc. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: 5b9ab0325414 Author: Kinsley Wong Date: 2012-07-02 12:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/5b9ab0325414 [DOC ONLY] RT-21293: Typos in the API docs. ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java Changeset: dffc6988a9ab Author: Kinsley Wong Date: 2012-07-02 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/dffc6988a9ab Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: 40d9b78ba945 Author: Pavel Safrata Date: 2012-07-02 14:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/40d9b78ba945 RT-22747, RT-22749: marked additional SB dependencies. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.java Changeset: b27852b420e2 Author: "Joseph Andresen" Date: 2012-07-02 06:08 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b27852b420e2 RT-21828 Canvas Screen Lock ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 6b0866a7c08c Author: Yao Wang Date: 2012-07-03 10:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6b0866a7c08c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: 7f0d5537b52a Author: mfang Date: 2012-06-29 21:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7f0d5537b52a RT-23080: NLS: javafx2.2 message drop 20 integration ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_de.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_es.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_fr.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_it.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ja.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ko.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_pt_BR.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_sv.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_CN.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_TW.properties Changeset: bc2e7244d877 Author: igor Date: 2012-07-03 16:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/bc2e7244d877 Merge Changeset: 554e78523bab Author: hudson Date: 2012-07-05 12:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/554e78523bab Added tag 2.2-b16 for changeset bc2e7244d877 ! .hgtags Changeset: 9bcfd0822e48 Author: David Grieve Date: 2012-07-03 14:35 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9bcfd0822e48 RT-22559: address isUserSetProperty and getAllPseudoClassStates causing bottleneck in StyleHelper.transitionToState ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.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/Scene.java Changeset: c74fc98bb9d4 Author: jgiles Date: 2012-07-03 12:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c74fc98bb9d4 RT-23008: TextFieldListCell throws NPE on Enter ! javafx-ui-controls/src/javafx/scene/control/cell/CellUtils.java Changeset: 587765f2009d Author: jgiles Date: 2012-07-03 12:22 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/587765f2009d [DOC ONLY] RT-23154: TextField Cells Javadoc doesn't specify clearly that StringConverter has to be set for them to work ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: e26d0e3bfcb3 Author: jgiles Date: 2012-07-03 15:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e26d0e3bfcb3 [DOC ONLY] RT-22874: CheckBoxTreeItem: javadoc is incomplete ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java Changeset: ea0e80ad3933 Author: jgiles Date: 2012-07-04 07:36 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ea0e80ad3933 [DOC ONLY] Fixes for a number of JavaDoc errors and warnings. ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java ! javafx-ui-common/src/javafx/scene/input/InputMethodEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/MapValueFactory.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: b06e3fb7dd1a Author: jgiles Date: 2012-07-04 07:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b06e3fb7dd1a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 53c9087d14fb Author: Kinsley Wong Date: 2012-07-03 13:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/53c9087d14fb RT-22929 [Not bug court approved pushing so qa and can run tests] SplitPane: issue with position setting ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java Changeset: 279dc6b31ebd Author: David Grieve Date: 2012-07-03 20:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/279dc6b31ebd RT-22076: reinsert patch ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: 907808cece4e Author: Kinsley Wong Date: 2012-07-05 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/907808cece4e RT-22866 Pagination control does not handle swipe gesture events. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 9d0660e793f6 Author: Kinsley Wong Date: 2012-07-05 11:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9d0660e793f6 RT-23084: Calling "setSelected(true)" on CheckBox fires ActionEvent. ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java Changeset: d48861b45651 Author: Kinsley Wong Date: 2012-07-05 13:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d48861b45651 RT-23063: Nested SplitPand rendering issue. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java Changeset: 330911490952 Author: jgiles Date: 2012-07-09 10:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/330911490952 RT-21684: TableView with hidden/invisible columns: resizing of columns gets confused ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: e3ddeb5fe157 Author: jgiles Date: 2012-07-09 10:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e3ddeb5fe157 RT-23067: AIOOBE when expand one of selected nodes in TreeView ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: 2e3e8a90f8c0 Author: jgiles Date: 2012-07-09 16:49 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2e3e8a90f8c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 0122996d25d3 Author: David Grieve Date: 2012-07-09 12:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0122996d25d3 RT-22076: backout patch. Fix deferred to 3.0 ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java Changeset: 5b3e02e4f23b Author: David Grieve Date: 2012-07-09 12:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/5b3e02e4f23b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: a88de67241de Author: David Grieve Date: 2012-07-09 12:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a88de67241de RT-21594: If the style cache for a node is null, then tell the node to reapply CSS because the StyleHelper is no good in this case. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 18f3884957e7 Author: David Grieve Date: 2012-07-09 12:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/18f3884957e7 RT-23184: adding same UA stylesheet should not cause styles to be obliterated ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: f3bb020babab Author: mickf Date: 2012-07-09 18:12 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/f3bb020babab RT-23033 : Label with setFocusTraversable(true) breaks focus traversing ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: a8bd152f64ad Author: mickf Date: 2012-07-09 18:17 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a8bd152f64ad RT-20222 : Ensemble - Controls on the right side are not reachable via keyboard ! javafx-ui-common/src/com/sun/javafx/scene/traversal/ContainerTabOrder.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java Changeset: 1eadff96bc2b Author: Kinsley Wong Date: 2012-07-09 13:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1eadff96bc2b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 64f2c821ab4e Author: "Joseph Andresen" Date: 2012-07-09 14:22 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/64f2c821ab4e [javadoc] RT-22593 Effects: some treat as private docs missing ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java Changeset: 1d8c6251f243 Author: kcr Date: 2012-07-10 06:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1d8c6251f243 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: f28a395961d2 Author: hudson Date: 2012-07-11 12:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/f28a395961d2 Added tag 2.2-b17 for changeset 1d8c6251f243 ! .hgtags From kirill.prazdnikov at oracle.com Wed Jul 11 12:35:27 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Wed, 11 Jul 2012 23:35:27 +0400 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFD946B.1070905@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> Message-ID: <4FFDD57F.5070109@oracle.com> Hi Pavel, I`m not sure, but many time times I found the following conversions as very useful: public float [] asArray(float data[12]); public Affine(float data[]); along with 12-arguments ctor. Thanks -Kirill On 7/11/2012 6:57 PM, Pavel Safrata wrote: > Hi Martin, > thank you for your input. > > On 10.7.2012 18:36, Martin Desruisseaux wrote: >> Hello Pavel >> >> Many thanks for taking care of this task! >> >> >> Le 10/07/12 17:00, Pavel Safrata a ?crit : >>> On Transform class: >>> public Transform getConcatenation(Transform transform) // >>> multiplication >>> public Transform getInverse() throws >>> NoninvertibleTransformException // negation >>> public Transform copy() >> Sound fine to me, while I'm not sure why a 'copy' method instead than >> overriding the 'clone()' method? > > Good point, we can use clone(). > >> >> >>> Constructors: >>> public Affine(Transform transform) >>> public Affine(double mxx, double mxy, double mxz, double tx, >>> double myx, double myy, double myz, double ty, >>> double mzx, double mzy, double mzz, double tz) >> Look fine. >> >> >>> Setters of the entire matrix: >>> (...snip...) >> I don't know for JavaFX, but in my experience with Java2D, I wasn't >> using the setter methods often, except 'setToIdentity' and >> 'setToTransform'. For example rather than invoking >> 'setToTranslation', I strongly push our developers to use 'translate' >> (or 'concatWithTranslation' in this proposal) instead. If a developer >> really wants the functionality of 'setToTranslation', he can get it >> by invoking 'setToIdentity()' followed by 'concatWithTranslation'. Or >> yet better, 'setToTransform(...)' instead than 'setToIdentity' with >> the coefficients of some previous state that the user saved. > > I don't insist on having the setters, anybody wants them? > >> >> The rational is that in many cases, the affine transform is already >> initialized to some important value. For example in Java2D, >> AffineTransform is initialized to the transform from 'dot' to >> whatever units the underlying device uses. When rendering on screen, >> this is the identity transform. But when printing, this is something >> different that depends on the printer resolution. In GIS >> applications, it depends on the zoom level. Other applications may >> use magnifier glass over some areas. Because the initial transform is >> often (but not always) the identity one, developers with limited >> experience with affine transforms often use 'setTranslate' or >> 'setScale' in situations where they should really use 'translate' or >> 'scale', and do not realize their bug before late in the development >> process. For this reason, I would be inclined to discourage every >> setter methods except 'setToIdentity()' and 'setToTransform'. Keeping >> in mind that it is often easier to fill a hole later than to fix >> something broken, I think it would be safer to leave out all other >> setter methods for now, and revisit later if experience show that >> they are really needed. >> > > While I don't think our Affine class will ever have varying initial > values I'm ok with keeping only setToIdentity() and setToTransform() > if there is no demand for the other setters right now. > >> >>> Operations on the matrix (modifying it in place): >>> (...snip...) >> Sound good, minus the unfortunate 'concatWith*' naming :-(. >> >> >>> Instead of "concatWithTranslation" it would be more natural to use >>> just "translate" (and similarly for the others), but unfortunately >>> these method names are already taken by the static factory methods >>> on Transform class. This is unpleasant but we need to be backward >>> compatible so we have to introduce different names. We'll be happy >>> to hear better naming suggestions than the concatWith* (which is >>> pretty descriptive I think but not really nice). >> Hard to say... A consistency with "preTranslate" would be nice, but >> "postTranslate" doesn't look very nice... What about the following? >> >> * Rename "preTranslate" as "appendTranslation" >> * Rename "concatWithTranslation" as "prependTranslation" >> >> The "preConcatenate(Tx)" name in Java2D was actually misleading to >> some developers, because it works as if points were first transformed >> by the original transform, then transformed by 'Tx'. Maybe >> "appendTranslation(Tx)" would make clear that the translation is >> applied after the original transform. This would also make operation >> order clearer. The following code using Java2D API: >> >> tr.translate(...) >> tr.scale(...) >> tr.rotate(...) >> >> must be read from bottom to up: it is as if points were rotated >> first, then scaled, then translated. So maybe the above proposition >> would make that more obvious: >> >> tr.prependTranslation(....) >> tr.prependScale(...) >> tr.prependRotate(...) >> tr.appendTranslation(...) // Just for fun. >> > > These names indeed sound way better. > > If we are going this way, shouldn't we do also this? > * Rename 'concatenate' as 'prepend' > * Rename 'preConcatenate' as 'append' > * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) > > As a black-box transformation composing this makes sense. As a matrix > algebra, it may be also confusing: tA.append(tB) means matrix > multiplication 'B x A', does it sound good? Maybe yes, I'm not sure. > Anyway, so far the best proposal I think. > >> >>> Would you want static factory methods on Affine (creating Affine >>> instances with the simple transforms)? >> I don't think it is necessary. I found the static factory methods of >> Java2D AffineTransform rarely used. >> >>> Would it be important to you whether or not matrix changes are >>> atomic? If you call one of the methods that modify the entire >>> matrix, can be listeners for each member called immediately as the >>> members are set, or do they need to be called after all the members >>> are updated? >> I don't have experience in this area. But naively, it seems to we >> that it would be better to be notified only after the full matrix has >> been updated... > > Yes, I would also pick this option. It's just that it would mean > writing much more complicated (and a bit less effective) code so the > question is whether or not you think it is important. > > Thanks, > Pavel > >> >> Regards, >> >> Martin >> > > From pavel.safrata at oracle.com Wed Jul 11 13:17:40 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 11 Jul 2012 22:17:40 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFDD57F.5070109@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> Message-ID: <4FFDDF64.7020902@oracle.com> Hi Kirill, what is the use-case? I suspect that if you want the raw matrix to do some math with it we are rather missing some operations doing the math directly. Thanks, Pavel On 11.7.2012 21:35, Kirill.Prazdnikov wrote: > Hi Pavel, > > I`m not sure, but many time times I found the following conversions > as very useful: > > public float [] asArray(float data[12]); > public Affine(float data[]); > > along with 12-arguments ctor. > > Thanks > -Kirill > > On 7/11/2012 6:57 PM, Pavel Safrata wrote: >> Hi Martin, >> thank you for your input. >> >> On 10.7.2012 18:36, Martin Desruisseaux wrote: >>> Hello Pavel >>> >>> Many thanks for taking care of this task! >>> >>> >>> Le 10/07/12 17:00, Pavel Safrata a ?crit : >>>> On Transform class: >>>> public Transform getConcatenation(Transform transform) // >>>> multiplication >>>> public Transform getInverse() throws >>>> NoninvertibleTransformException // negation >>>> public Transform copy() >>> Sound fine to me, while I'm not sure why a 'copy' method instead >>> than overriding the 'clone()' method? >> >> Good point, we can use clone(). >> >>> >>> >>>> Constructors: >>>> public Affine(Transform transform) >>>> public Affine(double mxx, double mxy, double mxz, double tx, >>>> double myx, double myy, double myz, double ty, >>>> double mzx, double mzy, double mzz, double tz) >>> Look fine. >>> >>> >>>> Setters of the entire matrix: >>>> (...snip...) >>> I don't know for JavaFX, but in my experience with Java2D, I wasn't >>> using the setter methods often, except 'setToIdentity' and >>> 'setToTransform'. For example rather than invoking >>> 'setToTranslation', I strongly push our developers to use >>> 'translate' (or 'concatWithTranslation' in this proposal) instead. >>> If a developer really wants the functionality of 'setToTranslation', >>> he can get it by invoking 'setToIdentity()' followed by >>> 'concatWithTranslation'. Or yet better, 'setToTransform(...)' >>> instead than 'setToIdentity' with the coefficients of some previous >>> state that the user saved. >> >> I don't insist on having the setters, anybody wants them? >> >>> >>> The rational is that in many cases, the affine transform is already >>> initialized to some important value. For example in Java2D, >>> AffineTransform is initialized to the transform from 'dot' to >>> whatever units the underlying device uses. When rendering on screen, >>> this is the identity transform. But when printing, this is something >>> different that depends on the printer resolution. In GIS >>> applications, it depends on the zoom level. Other applications may >>> use magnifier glass over some areas. Because the initial transform >>> is often (but not always) the identity one, developers with limited >>> experience with affine transforms often use 'setTranslate' or >>> 'setScale' in situations where they should really use 'translate' or >>> 'scale', and do not realize their bug before late in the development >>> process. For this reason, I would be inclined to discourage every >>> setter methods except 'setToIdentity()' and 'setToTransform'. >>> Keeping in mind that it is often easier to fill a hole later than to >>> fix something broken, I think it would be safer to leave out all >>> other setter methods for now, and revisit later if experience show >>> that they are really needed. >>> >> >> While I don't think our Affine class will ever have varying initial >> values I'm ok with keeping only setToIdentity() and setToTransform() >> if there is no demand for the other setters right now. >> >>> >>>> Operations on the matrix (modifying it in place): >>>> (...snip...) >>> Sound good, minus the unfortunate 'concatWith*' naming :-(. >>> >>> >>>> Instead of "concatWithTranslation" it would be more natural to use >>>> just "translate" (and similarly for the others), but unfortunately >>>> these method names are already taken by the static factory methods >>>> on Transform class. This is unpleasant but we need to be backward >>>> compatible so we have to introduce different names. We'll be happy >>>> to hear better naming suggestions than the concatWith* (which is >>>> pretty descriptive I think but not really nice). >>> Hard to say... A consistency with "preTranslate" would be nice, but >>> "postTranslate" doesn't look very nice... What about the following? >>> >>> * Rename "preTranslate" as "appendTranslation" >>> * Rename "concatWithTranslation" as "prependTranslation" >>> >>> The "preConcatenate(Tx)" name in Java2D was actually misleading to >>> some developers, because it works as if points were first >>> transformed by the original transform, then transformed by 'Tx'. >>> Maybe "appendTranslation(Tx)" would make clear that the translation >>> is applied after the original transform. This would also make >>> operation order clearer. The following code using Java2D API: >>> >>> tr.translate(...) >>> tr.scale(...) >>> tr.rotate(...) >>> >>> must be read from bottom to up: it is as if points were rotated >>> first, then scaled, then translated. So maybe the above proposition >>> would make that more obvious: >>> >>> tr.prependTranslation(....) >>> tr.prependScale(...) >>> tr.prependRotate(...) >>> tr.appendTranslation(...) // Just for fun. >>> >> >> These names indeed sound way better. >> >> If we are going this way, shouldn't we do also this? >> * Rename 'concatenate' as 'prepend' >> * Rename 'preConcatenate' as 'append' >> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) >> >> As a black-box transformation composing this makes sense. As a matrix >> algebra, it may be also confusing: tA.append(tB) means matrix >> multiplication 'B x A', does it sound good? Maybe yes, I'm not sure. >> Anyway, so far the best proposal I think. >> >>> >>>> Would you want static factory methods on Affine (creating Affine >>>> instances with the simple transforms)? >>> I don't think it is necessary. I found the static factory methods of >>> Java2D AffineTransform rarely used. >>> >>>> Would it be important to you whether or not matrix changes are >>>> atomic? If you call one of the methods that modify the entire >>>> matrix, can be listeners for each member called immediately as the >>>> members are set, or do they need to be called after all the members >>>> are updated? >>> I don't have experience in this area. But naively, it seems to we >>> that it would be better to be notified only after the full matrix >>> has been updated... >> >> Yes, I would also pick this option. It's just that it would mean >> writing much more complicated (and a bit less effective) code so the >> question is whether or not you think it is important. >> >> Thanks, >> Pavel >> >>> >>> Regards, >>> >>> Martin >>> >> >> > From kirill.prazdnikov at oracle.com Wed Jul 11 16:20:14 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Thu, 12 Jul 2012 03:20:14 +0400 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFDDF64.7020902@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> Message-ID: <4FFE0A2E.7030009@oracle.com> Hi Pavel, My typical use-case was to transfer matrix data between JavaFX and different libraries like 3D or physics. Use of one array with 12 (16) elements is by far simpler then passing 12 (16) arguments. And performance of one getter is better then 16 separate martix elements getters. Thanks -Kirill On 7/12/2012 12:17 AM, Pavel Safrata wrote: > Hi Kirill, > what is the use-case? I suspect that if you want the raw matrix to do > some math with it we are rather missing some operations doing the math > directly. > Thanks, > Pavel > > On 11.7.2012 21:35, Kirill.Prazdnikov wrote: >> Hi Pavel, >> >> I`m not sure, but many time times I found the following conversions >> as very useful: >> >> public float [] asArray(float data[12]); >> public Affine(float data[]); >> >> along with 12-arguments ctor. >> >> Thanks >> -Kirill >> >> On 7/11/2012 6:57 PM, Pavel Safrata wrote: >>> Hi Martin, >>> thank you for your input. >>> >>> On 10.7.2012 18:36, Martin Desruisseaux wrote: >>>> Hello Pavel >>>> >>>> Many thanks for taking care of this task! >>>> >>>> >>>> Le 10/07/12 17:00, Pavel Safrata a ?crit : >>>>> On Transform class: >>>>> public Transform getConcatenation(Transform transform) // >>>>> multiplication >>>>> public Transform getInverse() throws >>>>> NoninvertibleTransformException // negation >>>>> public Transform copy() >>>> Sound fine to me, while I'm not sure why a 'copy' method instead >>>> than overriding the 'clone()' method? >>> >>> Good point, we can use clone(). >>> >>>> >>>> >>>>> Constructors: >>>>> public Affine(Transform transform) >>>>> public Affine(double mxx, double mxy, double mxz, double tx, >>>>> double myx, double myy, double myz, double ty, >>>>> double mzx, double mzy, double mzz, double tz) >>>> Look fine. >>>> >>>> >>>>> Setters of the entire matrix: >>>>> (...snip...) >>>> I don't know for JavaFX, but in my experience with Java2D, I wasn't >>>> using the setter methods often, except 'setToIdentity' and >>>> 'setToTransform'. For example rather than invoking >>>> 'setToTranslation', I strongly push our developers to use >>>> 'translate' (or 'concatWithTranslation' in this proposal) instead. >>>> If a developer really wants the functionality of >>>> 'setToTranslation', he can get it by invoking 'setToIdentity()' >>>> followed by 'concatWithTranslation'. Or yet better, >>>> 'setToTransform(...)' instead than 'setToIdentity' with the >>>> coefficients of some previous state that the user saved. >>> >>> I don't insist on having the setters, anybody wants them? >>> >>>> >>>> The rational is that in many cases, the affine transform is already >>>> initialized to some important value. For example in Java2D, >>>> AffineTransform is initialized to the transform from 'dot' to >>>> whatever units the underlying device uses. When rendering on >>>> screen, this is the identity transform. But when printing, this is >>>> something different that depends on the printer resolution. In GIS >>>> applications, it depends on the zoom level. Other applications may >>>> use magnifier glass over some areas. Because the initial transform >>>> is often (but not always) the identity one, developers with limited >>>> experience with affine transforms often use 'setTranslate' or >>>> 'setScale' in situations where they should really use 'translate' >>>> or 'scale', and do not realize their bug before late in the >>>> development process. For this reason, I would be inclined to >>>> discourage every setter methods except 'setToIdentity()' and >>>> 'setToTransform'. Keeping in mind that it is often easier to fill a >>>> hole later than to fix something broken, I think it would be safer >>>> to leave out all other setter methods for now, and revisit later if >>>> experience show that they are really needed. >>>> >>> >>> While I don't think our Affine class will ever have varying initial >>> values I'm ok with keeping only setToIdentity() and setToTransform() >>> if there is no demand for the other setters right now. >>> >>>> >>>>> Operations on the matrix (modifying it in place): >>>>> (...snip...) >>>> Sound good, minus the unfortunate 'concatWith*' naming :-(. >>>> >>>> >>>>> Instead of "concatWithTranslation" it would be more natural to use >>>>> just "translate" (and similarly for the others), but unfortunately >>>>> these method names are already taken by the static factory methods >>>>> on Transform class. This is unpleasant but we need to be backward >>>>> compatible so we have to introduce different names. We'll be happy >>>>> to hear better naming suggestions than the concatWith* (which is >>>>> pretty descriptive I think but not really nice). >>>> Hard to say... A consistency with "preTranslate" would be nice, but >>>> "postTranslate" doesn't look very nice... What about the following? >>>> >>>> * Rename "preTranslate" as "appendTranslation" >>>> * Rename "concatWithTranslation" as "prependTranslation" >>>> >>>> The "preConcatenate(Tx)" name in Java2D was actually misleading to >>>> some developers, because it works as if points were first >>>> transformed by the original transform, then transformed by 'Tx'. >>>> Maybe "appendTranslation(Tx)" would make clear that the translation >>>> is applied after the original transform. This would also make >>>> operation order clearer. The following code using Java2D API: >>>> >>>> tr.translate(...) >>>> tr.scale(...) >>>> tr.rotate(...) >>>> >>>> must be read from bottom to up: it is as if points were rotated >>>> first, then scaled, then translated. So maybe the above proposition >>>> would make that more obvious: >>>> >>>> tr.prependTranslation(....) >>>> tr.prependScale(...) >>>> tr.prependRotate(...) >>>> tr.appendTranslation(...) // Just for fun. >>>> >>> >>> These names indeed sound way better. >>> >>> If we are going this way, shouldn't we do also this? >>> * Rename 'concatenate' as 'prepend' >>> * Rename 'preConcatenate' as 'append' >>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) >>> >>> As a black-box transformation composing this makes sense. As a >>> matrix algebra, it may be also confusing: tA.append(tB) means matrix >>> multiplication 'B x A', does it sound good? Maybe yes, I'm not sure. >>> Anyway, so far the best proposal I think. >>> >>>> >>>>> Would you want static factory methods on Affine (creating Affine >>>>> instances with the simple transforms)? >>>> I don't think it is necessary. I found the static factory methods >>>> of Java2D AffineTransform rarely used. >>>> >>>>> Would it be important to you whether or not matrix changes are >>>>> atomic? If you call one of the methods that modify the entire >>>>> matrix, can be listeners for each member called immediately as the >>>>> members are set, or do they need to be called after all the >>>>> members are updated? >>>> I don't have experience in this area. But naively, it seems to we >>>> that it would be better to be notified only after the full matrix >>>> has been updated... >>> >>> Yes, I would also pick this option. It's just that it would mean >>> writing much more complicated (and a bit less effective) code so the >>> question is whether or not you think it is important. >>> >>> Thanks, >>> Pavel >>> >>>> >>>> Regards, >>>> >>>> Martin >>>> >>> >>> >> > > From hang.vo at oracle.com Wed Jul 11 21:33:41 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 12 Jul 2012 04:33:41 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-23079: CacheEntry in StyleHelper should weakly reference the shared cache from StylesheetContainer styleCache Message-ID: <20120712043343.70AF247FAA@hg.openjdk.java.net> Changeset: 2e6dd4d24206 Author: David Grieve Date: 2012-07-12 00:28 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2e6dd4d24206 RT-23079: CacheEntry in StyleHelper should weakly reference the shared cache from StylesheetContainer styleCache ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java From pavel.safrata at oracle.com Wed Jul 11 23:35:16 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 08:35:16 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFE0A2E.7030009@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> Message-ID: <4FFE7024.2090603@oracle.com> Hi Kirill, you are not right with the performance, the elements are (possibly invalid) properties so we need to call all the getters anyway, plus construct the array, so the performance is actually worse. But the use-case seems to be valid, especially if the other libraries support such conversion. I just wouldn't call it 'asArray' which suggests that the array will keep updating with the matrix changes but rather 'toArray'. To be consistent we need to use doubles instead of floats and we should also add a similar setter. So I propose: public double[] toArray() public double[] toArray(double[] a) public Affine(double[] matrix) public void setTransform(double[] matrix) Where the first two will behave similarly as if it was a List of 12 doubles, the latter two will throw IllegalArgumentException if length of the array is not 12. Regards, Pavel On 12.7.2012 1:20, Kirill.Prazdnikov wrote: > Hi Pavel, > > My typical use-case was to transfer matrix data between JavaFX and > different libraries like 3D or physics. > Use of one array with 12 (16) elements is by far simpler then passing > 12 (16) arguments. > And performance of one getter is better then 16 separate martix > elements getters. > > Thanks > -Kirill > > On 7/12/2012 12:17 AM, Pavel Safrata wrote: >> Hi Kirill, >> what is the use-case? I suspect that if you want the raw matrix to do >> some math with it we are rather missing some operations doing the >> math directly. >> Thanks, >> Pavel >> >> On 11.7.2012 21:35, Kirill.Prazdnikov wrote: >>> Hi Pavel, >>> >>> I`m not sure, but many time times I found the following >>> conversions as very useful: >>> >>> public float [] asArray(float data[12]); >>> public Affine(float data[]); >>> >>> along with 12-arguments ctor. >>> >>> Thanks >>> -Kirill >>> >>> On 7/11/2012 6:57 PM, Pavel Safrata wrote: >>>> Hi Martin, >>>> thank you for your input. >>>> >>>> On 10.7.2012 18:36, Martin Desruisseaux wrote: >>>>> Hello Pavel >>>>> >>>>> Many thanks for taking care of this task! >>>>> >>>>> >>>>> Le 10/07/12 17:00, Pavel Safrata a ?crit : >>>>>> On Transform class: >>>>>> public Transform getConcatenation(Transform transform) // >>>>>> multiplication >>>>>> public Transform getInverse() throws >>>>>> NoninvertibleTransformException // negation >>>>>> public Transform copy() >>>>> Sound fine to me, while I'm not sure why a 'copy' method instead >>>>> than overriding the 'clone()' method? >>>> >>>> Good point, we can use clone(). >>>> >>>>> >>>>> >>>>>> Constructors: >>>>>> public Affine(Transform transform) >>>>>> public Affine(double mxx, double mxy, double mxz, double tx, >>>>>> double myx, double myy, double myz, double ty, >>>>>> double mzx, double mzy, double mzz, double tz) >>>>> Look fine. >>>>> >>>>> >>>>>> Setters of the entire matrix: >>>>>> (...snip...) >>>>> I don't know for JavaFX, but in my experience with Java2D, I >>>>> wasn't using the setter methods often, except 'setToIdentity' and >>>>> 'setToTransform'. For example rather than invoking >>>>> 'setToTranslation', I strongly push our developers to use >>>>> 'translate' (or 'concatWithTranslation' in this proposal) instead. >>>>> If a developer really wants the functionality of >>>>> 'setToTranslation', he can get it by invoking 'setToIdentity()' >>>>> followed by 'concatWithTranslation'. Or yet better, >>>>> 'setToTransform(...)' instead than 'setToIdentity' with the >>>>> coefficients of some previous state that the user saved. >>>> >>>> I don't insist on having the setters, anybody wants them? >>>> >>>>> >>>>> The rational is that in many cases, the affine transform is >>>>> already initialized to some important value. For example in >>>>> Java2D, AffineTransform is initialized to the transform from 'dot' >>>>> to whatever units the underlying device uses. When rendering on >>>>> screen, this is the identity transform. But when printing, this is >>>>> something different that depends on the printer resolution. In GIS >>>>> applications, it depends on the zoom level. Other applications may >>>>> use magnifier glass over some areas. Because the initial transform >>>>> is often (but not always) the identity one, developers with >>>>> limited experience with affine transforms often use 'setTranslate' >>>>> or 'setScale' in situations where they should really use >>>>> 'translate' or 'scale', and do not realize their bug before late >>>>> in the development process. For this reason, I would be inclined >>>>> to discourage every setter methods except 'setToIdentity()' and >>>>> 'setToTransform'. Keeping in mind that it is often easier to fill >>>>> a hole later than to fix something broken, I think it would be >>>>> safer to leave out all other setter methods for now, and revisit >>>>> later if experience show that they are really needed. >>>>> >>>> >>>> While I don't think our Affine class will ever have varying initial >>>> values I'm ok with keeping only setToIdentity() and >>>> setToTransform() if there is no demand for the other setters right >>>> now. >>>> >>>>> >>>>>> Operations on the matrix (modifying it in place): >>>>>> (...snip...) >>>>> Sound good, minus the unfortunate 'concatWith*' naming :-(. >>>>> >>>>> >>>>>> Instead of "concatWithTranslation" it would be more natural to >>>>>> use just "translate" (and similarly for the others), but >>>>>> unfortunately these method names are already taken by the static >>>>>> factory methods on Transform class. This is unpleasant but we >>>>>> need to be backward compatible so we have to introduce different >>>>>> names. We'll be happy to hear better naming suggestions than the >>>>>> concatWith* (which is pretty descriptive I think but not really >>>>>> nice). >>>>> Hard to say... A consistency with "preTranslate" would be nice, >>>>> but "postTranslate" doesn't look very nice... What about the >>>>> following? >>>>> >>>>> * Rename "preTranslate" as "appendTranslation" >>>>> * Rename "concatWithTranslation" as "prependTranslation" >>>>> >>>>> The "preConcatenate(Tx)" name in Java2D was actually misleading to >>>>> some developers, because it works as if points were first >>>>> transformed by the original transform, then transformed by 'Tx'. >>>>> Maybe "appendTranslation(Tx)" would make clear that the >>>>> translation is applied after the original transform. This would >>>>> also make operation order clearer. The following code using Java2D >>>>> API: >>>>> >>>>> tr.translate(...) >>>>> tr.scale(...) >>>>> tr.rotate(...) >>>>> >>>>> must be read from bottom to up: it is as if points were rotated >>>>> first, then scaled, then translated. So maybe the above >>>>> proposition would make that more obvious: >>>>> >>>>> tr.prependTranslation(....) >>>>> tr.prependScale(...) >>>>> tr.prependRotate(...) >>>>> tr.appendTranslation(...) // Just for fun. >>>>> >>>> >>>> These names indeed sound way better. >>>> >>>> If we are going this way, shouldn't we do also this? >>>> * Rename 'concatenate' as 'prepend' >>>> * Rename 'preConcatenate' as 'append' >>>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) >>>> >>>> As a black-box transformation composing this makes sense. As a >>>> matrix algebra, it may be also confusing: tA.append(tB) means >>>> matrix multiplication 'B x A', does it sound good? Maybe yes, I'm >>>> not sure. Anyway, so far the best proposal I think. >>>> >>>>> >>>>>> Would you want static factory methods on Affine (creating Affine >>>>>> instances with the simple transforms)? >>>>> I don't think it is necessary. I found the static factory methods >>>>> of Java2D AffineTransform rarely used. >>>>> >>>>>> Would it be important to you whether or not matrix changes are >>>>>> atomic? If you call one of the methods that modify the entire >>>>>> matrix, can be listeners for each member called immediately as >>>>>> the members are set, or do they need to be called after all the >>>>>> members are updated? >>>>> I don't have experience in this area. But naively, it seems to we >>>>> that it would be better to be notified only after the full matrix >>>>> has been updated... >>>> >>>> Yes, I would also pick this option. It's just that it would mean >>>> writing much more complicated (and a bit less effective) code so >>>> the question is whether or not you think it is important. >>>> >>>> Thanks, >>>> Pavel >>>> >>>>> >>>>> Regards, >>>>> >>>>> Martin >>>>> >>>> >>>> >>> >> >> > From martin.desruisseaux at geomatys.fr Thu Jul 12 02:05:01 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 11:05:01 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFE7024.2090603@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> Message-ID: <4FFE933D.2060009@geomatys.fr> The array methods may also be useful for working on matrix coefficients using indices rather than hard-coded access to the mxx, mxy, etc. properties. For example: when the affine may contain scale, rotation, flip and translation but no shear, at least in the 2D case (I think it works in 3D too), we can compute the scale factors "as if there were no flip or rotation" by computing the square root of the sum of the square of all values (except translation) on a row or a column. Whatever we compute on rows or on columns depend on whatever we want the scale factors to be expressed relative to the axes of the source coordinate system or the target coordinate system (this is not the same if there is a rotation). For this kind of computation, looping over an array using indices - or alternatively providing a Matrix.get(row, column) method - is convenient. Martin Le 12/07/12 08:35, Pavel Safrata a ?crit : > Hi Kirill, > you are not right with the performance, the elements are (possibly > invalid) properties so we need to call all the getters anyway, plus > construct the array, so the performance is actually worse. But the > use-case seems to be valid, especially if the other libraries support > such conversion. I just wouldn't call it 'asArray' which suggests that > the array will keep updating with the matrix changes but rather > 'toArray'. To be consistent we need to use doubles instead of floats > and we should also add a similar setter. So I propose: > > public double[] toArray() > public double[] toArray(double[] a) > public Affine(double[] matrix) > public void setTransform(double[] matrix) > > Where the first two will behave similarly as if it was a List of 12 > doubles, the latter two will throw IllegalArgumentException if length > of the array is not 12. > > Regards, > Pavel From pavel.safrata at oracle.com Thu Jul 12 02:28:15 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 11:28:15 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFDAA7D.2000800@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFD9E47.7040403@geomatys.fr> <4FFDAA7D.2000800@oracle.com> Message-ID: <4FFE98AF.1090403@oracle.com> On 11.7.2012 18:31, Pavel Safrata wrote: > > On 11.7.2012 17:39, Martin Desruisseaux wrote: >> Le 11/07/12 16:57, Pavel Safrata a ?crit : >>> If we are going this way, shouldn't we do also this? >>> * Rename 'concatenate' as 'prepend' >>> * Rename 'preConcatenate' as 'append' >> Yes, I think it would bring more uniformity in the method naming. >> >>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) >> I missed that method... What would its function? Or are we are >> talking about something like a 'getTransformCoefficients()' method? > > This method is similar to concatenate (prepend) except that it is > defined on parent Transform class and returns the result in a new > Transform instance (allows for multiplicating arbitrary - possibly > immutable - transfroms). What about something like getCompound(Transform)? Probably switching its meaning so that a.getCompound(b) returns equivalent transform to a.append(b). >>>> I don't have experience in this area. But naively, it seems to we >>>> that it would be better to be notified only after the full matrix >>>> has been updated... >>> Yes, I would also pick this option. It's just that it would mean >>> writing much more complicated (and a bit less effective) code so the >>> question is whether or not you think it is important. >> I don't have a use case where I would like to listen to individual >> coefficient changes. It seems to me that I would rather listen to >> whatever property contains the Transform object as a whole. >> Consequently, I don't think that the atomicity of Affine operations >> would have much incidence (assuming that there is some way - other >> than listening to individual coefficients - to be informed that the >> matrix as a whole has changed). > > > Unfortunately I don't think there is a way to listen for changes on an > object other than listening on all its properties. In my opinion this > is quite a big issue and it's been bothering me for some time already. > I've heard that some utilities are planned for that but still I want > to file a feature request for some better mechanism, hopefully this > email gives me the impulse to finally do it. I've filed http://javafx-jira.kenai.com/browse/RT-23388 Regards, Pavel > > Anyway, I should probably not give up on the (quite obviously) better > API just because of implementation complexity. Will try to make the > changes atomic. > > Thanks, > Pavel > >> >> Martin >> > > From martin.desruisseaux at geomatys.fr Thu Jul 12 02:50:27 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 11:50:27 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFE98AF.1090403@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFD9E47.7040403@geomatys.fr> <4FFDAA7D.2000800@oracle.com> <4FFE98AF.1090403@oracle.com> Message-ID: <4FFE9DE3.2040407@geomatys.fr> Le 12/07/12 11:28, Pavel Safrata a ?crit : >>>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) >>> I missed that method... What would its function? Or are we are >>> talking about something like a 'getTransformCoefficients()' method? >> This method is similar to concatenate (prepend) except that it is >> defined on parent Transform class and returns the result in a new >> Transform instance (allows for multiplicating arbitrary - possibly >> immutable - transfroms). > What about something like getCompound(Transform)? Probably switching > its meaning so that a.getCompound(b) returns equivalent transform to > a.append(b). I'm not sure if this is relevant to JavaFX Affine, but in the vocabulary used by the ISO 19111 international standard (Geographic information ? Spatial referencing by coordinates), "compound" and "concatenated" are slightly different concepts. We have "compound" coordinate systems, but "concatenated" transforms. If consistency with ISO 19111 was considered a worthy bonus, then "concatenate" or "getConcatenation" would be quite appropriate vocabulary. Not exactly ISO 19111 but closely related, the Open Geospatial Consortium defined this method: http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/operation/MathTransformFactory.html#createConcatenatedTransform%28org.opengis.referencing.operation.MathTransform,%20org.opengis.referencing.operation.MathTransform%29 Martin From martin.desruisseaux at geomatys.fr Thu Jul 12 02:57:00 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 11:57:00 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFE98AF.1090403@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFD9E47.7040403@geomatys.fr> <4FFDAA7D.2000800@oracle.com> <4FFE98AF.1090403@oracle.com> Message-ID: <4FFE9F6C.3020002@geomatys.fr> Le 12/07/12 11:28, Pavel Safrata a ?crit : > I've filed > http://javafx-jira.kenai.com/browse/RT-23388 Thanks!! Martin From pavel.safrata at oracle.com Thu Jul 12 04:23:26 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 13:23:26 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFE933D.2060009@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> Message-ID: <4FFEB3AE.1010906@oracle.com> I like the get(row, col) method, I think we can introduce it in addition to the array conversions. Similarly we can add set(row, col, value). Both just convenience methods internally calling the actual property getters/setters. Pavel On 12.7.2012 11:05, Martin Desruisseaux wrote: > The array methods may also be useful for working on matrix > coefficients using indices rather than hard-coded access to the mxx, > mxy, etc. properties. For example: when the affine may contain scale, > rotation, flip and translation but no shear, at least in the 2D case > (I think it works in 3D too), we can compute the scale factors "as if > there were no flip or rotation" by computing the square root of the > sum of the square of all values (except translation) on a row or a > column. Whatever we compute on rows or on columns depend on whatever > we want the scale factors to be expressed relative to the axes of the > source coordinate system or the target coordinate system (this is not > the same if there is a rotation). For this kind of computation, > looping over an array using indices - or alternatively providing a > Matrix.get(row, column) method - is convenient. > > Martin > > > Le 12/07/12 08:35, Pavel Safrata a ?crit : >> Hi Kirill, >> you are not right with the performance, the elements are (possibly >> invalid) properties so we need to call all the getters anyway, plus >> construct the array, so the performance is actually worse. But the >> use-case seems to be valid, especially if the other libraries support >> such conversion. I just wouldn't call it 'asArray' which suggests >> that the array will keep updating with the matrix changes but rather >> 'toArray'. To be consistent we need to use doubles instead of floats >> and we should also add a similar setter. So I propose: >> >> public double[] toArray() >> public double[] toArray(double[] a) >> public Affine(double[] matrix) >> public void setTransform(double[] matrix) >> >> Where the first two will behave similarly as if it was a List of 12 >> doubles, the latter two will throw IllegalArgumentException if length >> of the array is not 12. >> >> Regards, >> Pavel > From martin.desruisseaux at geomatys.fr Thu Jul 12 04:40:26 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 13:40:26 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEB3AE.1010906@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> <4FFEB3AE.1010906@oracle.com> Message-ID: <4FFEB7AA.4040908@geomatys.fr> Le 12/07/12 13:23, Pavel Safrata a ?crit : > I like the get(row, col) method, I think we can introduce it in > addition to the array conversions. Similarly we can add set(row, col, > value). Both just convenience methods internally calling the actual > property getters/setters. Yes, I think those methods would be useful. Would it be worth to make a special case in the getter method like below? if (row == 3) { return (column == 3) ? 1 : 0; } The setter method would throw an exception on attempt to write a different value in that row (i.e., the last matrix row would be a virtual read-only row). The intend is to simulate a complete 4x4 matrix, which can make mathematical operations more natural, especially when working on arbitrary row/column indices unknown at compile time. Martin From pavel.safrata at oracle.com Thu Jul 12 04:46:51 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 13:46:51 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFE9DE3.2040407@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFD9E47.7040403@geomatys.fr> <4FFDAA7D.2000800@oracle.com> <4FFE98AF.1090403@oracle.com> <4FFE9DE3.2040407@geomatys.fr> Message-ID: <4FFEB92B.8040509@oracle.com> On 12.7.2012 11:50, Martin Desruisseaux wrote: > Le 12/07/12 11:28, Pavel Safrata a ?crit : >>>>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) >>>> I missed that method... What would its function? Or are we are >>>> talking about something like a 'getTransformCoefficients()' method? >>> This method is similar to concatenate (prepend) except that it is >>> defined on parent Transform class and returns the result in a new >>> Transform instance (allows for multiplicating arbitrary - possibly >>> immutable - transfroms). >> What about something like getCompound(Transform)? Probably switching >> its meaning so that a.getCompound(b) returns equivalent transform to >> a.append(b). > > I'm not sure if this is relevant to JavaFX Affine, but in the > vocabulary used by the ISO 19111 international standard (Geographic > information ? Spatial referencing by coordinates), "compound" and > "concatenated" are slightly different concepts. We have "compound" > coordinate systems, but "concatenated" transforms. If consistency with > ISO 19111 was considered a worthy bonus, then "concatenate" or > "getConcatenation" would be quite appropriate vocabulary. > > Not exactly ISO 19111 but closely related, the Open Geospatial > Consortium defined this method: > > http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/operation/MathTransformFactory.html#createConcatenatedTransform%28org.opengis.referencing.operation.MathTransform,%20org.opengis.referencing.operation.MathTransform%29 > > > Martin > Ok, thanks. We need to be consistent at least in scope our transforms, so let's pick from 1) createConcatenatedTransform, createInvertedTransform 2) getConcatenatedTransform, getInvertedTransform 3) createConcatenatenation, createInverse 4) getConcatenation, getInverse I'd probably vote for #3. Any other votes/suggestions? Thanks, Pavel From martin.desruisseaux at geomatys.fr Thu Jul 12 04:46:55 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 13:46:55 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEB7AA.4040908@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> <4FFEB3AE.1010906@oracle.com> <4FFEB7AA.4040908@geomatys.fr> Message-ID: <4FFEB92F.70806@geomatys.fr> Le 12/07/12 13:40, Martin Desruisseaux a ?crit : > Yes, I think those methods would be useful. Would it be worth to make > a special case in the getter method like below? > > if (row == 3) { > return (column == 3) ? 1 : 0; > } > > The setter method would throw an exception on attempt to write a > different value in that row (i.e., the last matrix row would be a > virtual read-only row). The intend is to simulate a complete 4x4 > matrix, which can make mathematical operations more natural, > especially when working on arbitrary row/column indices unknown at > compile time. Actually such getter method could be placed in the parent Transform class, since every subclasses can return appropriate hard-coded values for any (row,column) indices not associated to one of their fields (omitting the [0 ... 3] range check in this discussion for simplicity). This would allow the users to perform their own matrix calculation on every kind of Transform object. Martin From pavel.safrata at oracle.com Thu Jul 12 04:47:26 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 13:47:26 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEB7AA.4040908@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> <4FFEB3AE.1010906@oracle.com> <4FFEB7AA.4040908@geomatys.fr> Message-ID: <4FFEB94E.8090704@oracle.com> On 12.7.2012 13:40, Martin Desruisseaux wrote: > Le 12/07/12 13:23, Pavel Safrata a ?crit : >> I like the get(row, col) method, I think we can introduce it in >> addition to the array conversions. Similarly we can add set(row, col, >> value). Both just convenience methods internally calling the actual >> property getters/setters. > > Yes, I think those methods would be useful. Would it be worth to make > a special case in the getter method like below? > > if (row == 3) { > return (column == 3) ? 1 : 0; > } > > The setter method would throw an exception on attempt to write a > different value in that row (i.e., the last matrix row would be a > virtual read-only row). The intend is to simulate a complete 4x4 > matrix, which can make mathematical operations more natural, > especially when working on arbitrary row/column indices unknown at > compile time. I completely agree. Thanks, Pavel > > Martin > From pavel.safrata at oracle.com Thu Jul 12 04:58:03 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 13:58:03 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEB92F.70806@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> <4FFEB3AE.1010906@oracle.com> <4FFEB7AA.4040908@geomatys.fr> <4FFEB92F.70806@geomatys.fr> Message-ID: <4FFEBBCB.4080005@oracle.com> On 12.7.2012 13:46, Martin Desruisseaux wrote: > Le 12/07/12 13:40, Martin Desruisseaux a ?crit : >> Yes, I think those methods would be useful. Would it be worth to make >> a special case in the getter method like below? >> >> if (row == 3) { >> return (column == 3) ? 1 : 0; >> } >> >> The setter method would throw an exception on attempt to write a >> different value in that row (i.e., the last matrix row would be a >> virtual read-only row). The intend is to simulate a complete 4x4 >> matrix, which can make mathematical operations more natural, >> especially when working on arbitrary row/column indices unknown at >> compile time. > > Actually such getter method could be placed in the parent Transform > class, since every subclasses can return appropriate hard-coded values > for any (row,column) indices not associated to one of their fields > (omitting the [0 ... 3] range check in this discussion for > simplicity). This would allow the users to perform their own matrix > calculation on every kind of Transform object. Correct. All the element getters are already on Transform class so this convenient getter definitely belongs there (unlike the setter). Thanks, Pavel > > Martin > From martin.desruisseaux at geomatys.fr Thu Jul 12 05:08:16 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 14:08:16 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEB92B.8040509@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFD9E47.7040403@geomatys.fr> <4FFDAA7D.2000800@oracle.com> <4FFE98AF.1090403@oracle.com> <4FFE9DE3.2040407@geomatys.fr> <4FFEB92B.8040509@oracle.com> Message-ID: <4FFEBE30.8000807@geomatys.fr> Le 12/07/12 13:46, Pavel Safrata a ?crit : > Ok, thanks. We need to be consistent at least in scope our transforms, > so let's pick from > > 1) createConcatenatedTransform, createInvertedTransform > 2) getConcatenatedTransform, getInvertedTransform > 3) createConcatenatenation, createInverse > 4) getConcatenation, getInverse > > I'd probably vote for #3. Any other votes/suggestions? Both #1 and #3 look fine to me. Thanks, Martin From Kirill.Prazdnikov at oracle.com Thu Jul 12 05:08:18 2012 From: Kirill.Prazdnikov at oracle.com (Kirill Prazdnikov) Date: Thu, 12 Jul 2012 16:08:18 +0400 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEB3AE.1010906@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> <4FFEB3AE.1010906@oracle.com> Message-ID: <4FFEBE32.9060701@oracle.com> Transformation matrix consist of four vectors. In case of affine, it is coordinates of local orts + translation. Accessing this vectors is the most get/set use-case. I can not imagine where accessing individual matrix values could be used (useful) at all. Does anybody uses it ? -Kirill On 12-Jul-12 15:23, Pavel Safrata wrote: > I like the get(row, col) method, I think we can introduce it in > addition to the array conversions. Similarly we can add set(row, col, > value). Both just convenience methods internally calling the actual > property getters/setters. > > Pavel > > On 12.7.2012 11:05, Martin Desruisseaux wrote: >> The array methods may also be useful for working on matrix >> coefficients using indices rather than hard-coded access to the mxx, >> mxy, etc. properties. For example: when the affine may contain scale, >> rotation, flip and translation but no shear, at least in the 2D case >> (I think it works in 3D too), we can compute the scale factors "as if >> there were no flip or rotation" by computing the square root of the >> sum of the square of all values (except translation) on a row or a >> column. Whatever we compute on rows or on columns depend on whatever >> we want the scale factors to be expressed relative to the axes of the >> source coordinate system or the target coordinate system (this is not >> the same if there is a rotation). For this kind of computation, >> looping over an array using indices - or alternatively providing a >> Matrix.get(row, column) method - is convenient. >> >> Martin >> >> >> Le 12/07/12 08:35, Pavel Safrata a ?crit : >>> Hi Kirill, >>> you are not right with the performance, the elements are (possibly >>> invalid) properties so we need to call all the getters anyway, plus >>> construct the array, so the performance is actually worse. But the >>> use-case seems to be valid, especially if the other libraries >>> support such conversion. I just wouldn't call it 'asArray' which >>> suggests that the array will keep updating with the matrix changes >>> but rather 'toArray'. To be consistent we need to use doubles >>> instead of floats and we should also add a similar setter. So I >>> propose: >>> >>> public double[] toArray() >>> public double[] toArray(double[] a) >>> public Affine(double[] matrix) >>> public void setTransform(double[] matrix) >>> >>> Where the first two will behave similarly as if it was a List of 12 >>> doubles, the latter two will throw IllegalArgumentException if >>> length of the array is not 12. >>> >>> Regards, >>> Pavel >> > > From pavel.safrata at oracle.com Thu Jul 12 05:11:12 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 14:11:12 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEBE32.9060701@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> <4FFEB3AE.1010906@oracle.com> <4FFEBE32.9060701@oracle.com> Message-ID: <4FFEBEE0.8040402@oracle.com> Kirill, we don't really need to discuss this because the element properties are already there (for years) so we cannot change that anyway. Regards, Pavel On 12.7.2012 14:08, Kirill Prazdnikov wrote: > > Transformation matrix consist of four vectors. In case of affine, it > is coordinates of local orts + translation. > Accessing this vectors is the most get/set use-case. > I can not imagine where accessing individual matrix values could be > used (useful) at all. > > Does anybody uses it ? > > -Kirill > > On 12-Jul-12 15:23, Pavel Safrata wrote: >> I like the get(row, col) method, I think we can introduce it in >> addition to the array conversions. Similarly we can add set(row, col, >> value). Both just convenience methods internally calling the actual >> property getters/setters. >> >> Pavel >> >> On 12.7.2012 11:05, Martin Desruisseaux wrote: >>> The array methods may also be useful for working on matrix >>> coefficients using indices rather than hard-coded access to the mxx, >>> mxy, etc. properties. For example: when the affine may contain >>> scale, rotation, flip and translation but no shear, at least in the >>> 2D case (I think it works in 3D too), we can compute the scale >>> factors "as if there were no flip or rotation" by computing the >>> square root of the sum of the square of all values (except >>> translation) on a row or a column. Whatever we compute on rows or on >>> columns depend on whatever we want the scale factors to be expressed >>> relative to the axes of the source coordinate system or the target >>> coordinate system (this is not the same if there is a rotation). For >>> this kind of computation, looping over an array using indices - or >>> alternatively providing a Matrix.get(row, column) method - is >>> convenient. >>> >>> Martin >>> >>> >>> Le 12/07/12 08:35, Pavel Safrata a ?crit : >>>> Hi Kirill, >>>> you are not right with the performance, the elements are (possibly >>>> invalid) properties so we need to call all the getters anyway, plus >>>> construct the array, so the performance is actually worse. But the >>>> use-case seems to be valid, especially if the other libraries >>>> support such conversion. I just wouldn't call it 'asArray' which >>>> suggests that the array will keep updating with the matrix changes >>>> but rather 'toArray'. To be consistent we need to use doubles >>>> instead of floats and we should also add a similar setter. So I >>>> propose: >>>> >>>> public double[] toArray() >>>> public double[] toArray(double[] a) >>>> public Affine(double[] matrix) >>>> public void setTransform(double[] matrix) >>>> >>>> Where the first two will behave similarly as if it was a List of 12 >>>> doubles, the latter two will throw IllegalArgumentException if >>>> length of the array is not 12. >>>> >>>> Regards, >>>> Pavel >>> >> >> > From martin.desruisseaux at geomatys.fr Thu Jul 12 05:20:35 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 14:20:35 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEBE32.9060701@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> <4FFEB3AE.1010906@oracle.com> <4FFEBE32.9060701@oracle.com> Message-ID: <4FFEC113.2010906@geomatys.fr> Le 12/07/12 14:08, Kirill Prazdnikov a ?crit : > Transformation matrix consist of four vectors. In case of affine, it > is coordinates of local orts + translation. > Accessing this vectors is the most get/set use-case. > I can not imagine where accessing individual matrix values could be > used (useful) at all. > > Does anybody uses it ? Well, then intend is to access the vectors by looping over (row,column) indices. In the current API, we can only access individual matrix values through named properties. This means that we can not use loops neither parametrized methods. For example in order to compute the magnitude of a vector (my previous email about "square root of the sum of ..." was a complicated way to said exactly that), we have to: * explicitly sum every terms as in sqrt(mxx*mxx + mxy*mxy + mxz*mxz); * duplicate the above code for every rows. While I admit that a loop doesn't save much in this example, some other use case are a bit more complicated. And the problem of duplicated code for every vector (row) remain. If a 'get(row, column)' method is provided, then a user can compute a vector magnitude in a single method where the vector number (row index) is given as a method argument. Martin From Kirill.Prazdnikov at oracle.com Thu Jul 12 06:00:02 2012 From: Kirill.Prazdnikov at oracle.com (Kirill Prazdnikov) Date: Thu, 12 Jul 2012 17:00:02 +0400 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEC113.2010906@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFE933D.2060009@geomatys.fr> <4FFEB3AE.1010906@oracle.com> <4FFEBE32.9060701@oracle.com> <4FFEC113.2010906@geomatys.fr> Message-ID: <4FFECA52.7000904@oracle.com> Hi Martin, I perfectly understand the value of indexed access. And I agree with you. Thanks -Kirill On 12-Jul-12 16:20, Martin Desruisseaux wrote: > Le 12/07/12 14:08, Kirill Prazdnikov a ?crit : >> Transformation matrix consist of four vectors. In case of affine, it >> is coordinates of local orts + translation. >> Accessing this vectors is the most get/set use-case. >> I can not imagine where accessing individual matrix values could be >> used (useful) at all. >> >> Does anybody uses it ? > > Well, then intend is to access the vectors by looping over > (row,column) indices. In the current API, we can only access > individual matrix values through named properties. This means that we > can not use loops neither parametrized methods. For example in order > to compute the magnitude of a vector (my previous email about "square > root of the sum of ..." was a complicated way to said exactly that), > we have to: > > * explicitly sum every terms as in sqrt(mxx*mxx + mxy*mxy + mxz*mxz); > * duplicate the above code for every rows. > > > While I admit that a loop doesn't save much in this example, some > other use case are a bit more complicated. And the problem of > duplicated code for every vector (row) remain. If a 'get(row, column)' > method is provided, then a user can compute a vector magnitude in a > single method where the vector number (row index) is given as a method > argument. > > Martin > From eva.krejcirova at oracle.com Thu Jul 12 07:20:43 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Thu, 12 Jul 2012 16:20:43 +0200 Subject: Extending Builders: Layout Builders Message-ID: <4FFEDD3B.6030109@oracle.com> 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 mp at jugs.org Thu Jul 12 07:24:27 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Thu, 12 Jul 2012 16:24:27 +0200 Subject: Extending Builders: Layout Builders In-Reply-To: <4FFEDD3B.6030109@oracle.com> References: <4FFEDD3B.6030109@oracle.com> Message-ID: <4FFEDE1B.1020601@jugs.org> Great - These are exactly the convenience methods I had in mind when I wrote the original request. I just did not have the time to sort this all out :-) One more question. Will this work be part of the 2.2 release or will it come later in the 3.0 release? Michael Am 12.07.2012 16:20, schrieb Eva Krejcirova: > 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 -- -------------------------------------------------------------------------------------- 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 Thu Jul 12 07:41:32 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Thu, 12 Jul 2012 16:41:32 +0200 Subject: Extending Builders: Layout Builders In-Reply-To: <4FFEDE1B.1020601@jugs.org> References: <4FFEDD3B.6030109@oracle.com> <4FFEDE1B.1020601@jugs.org> Message-ID: <4FFEE21C.8000103@oracle.com> This is change to the API so it will need to go to 3.0. We are in high resistance mode for 2.2 and it is not possible to add new features there anymore. I will also need to get approval for this API change first (even for 3.0) :-) Eva On 7/12/2012 4:24 PM, Dr. Michael Paus wrote: > Great - These are exactly the convenience methods I had in mind when I > wrote the original request. > I just did not have the time to sort this all out :-) > > One more question. Will this work be part of the 2.2 release or will > it come later in the 3.0 release? > > Michael > > Am 12.07.2012 16:20, schrieb Eva Krejcirova: >> 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 mp at jugs.org Thu Jul 12 07:40:10 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Thu, 12 Jul 2012 16:40:10 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFC437E.2070505@oracle.com> References: <4FFC437E.2070505@oracle.com> Message-ID: <4FFEE1CA.4050301@jugs.org> I am not sure whether this has already been discussed but would it be possible to have a special variant of all constructors and methods, which currently take the full set of matrix elements, which only deal with the 2D subset of matrix elements? This would reduce the number of parameters that you have to specify in most cases. It would also prevent an issue which I had some time ago where I specified all elements of a matrix explicitly and when I used that matrix I lost all anti-aliasing. Don't know if this is still an issue and what the exact circumstances were. Michael Am 10.07.2012 17:00, schrieb Pavel Safrata: > Hello, > based on previous discussions, we're going to propose a set of new > methods to our transforms. > > Tracking Jira issue: http://javafx-jira.kenai.com/browse/RT-17942 > > I hope the names are self-explanatory, otherwise please let me know > and I'll provide some description. > > > On Transform class: > public Transform getConcatenation(Transform transform) // > multiplication > public Transform getInverse() throws > NoninvertibleTransformException // negation > public Transform copy() > > Note: in subclasses these methods will be overridden and will return > more specific types where possible. > > > On Affine class: > > Constructors: > public Affine(Transform transform) > public Affine(double mxx, double mxy, double mxz, double tx, > double myx, double myy, double myz, double ty, > double mzx, double mzy, double mzz, double tz) > > Setters of the entire matrix: > public void setToTransform(Transform t) > public void setToTransform(double mxx, double mxy, double mxz, > double mxt, > double myx, double myy, double myz, > double myt, > double mzx, double mzy, double mzz, > double mzt) > public void setToIdentity() > public void setToTranslation(double tx, double ty) > public void setToTranslation(double tx, double ty, double tz) > public void setToScale(double sx, double sy) > public void setToScale(double sx, double sy, double pivotX, double > pivotY) > public void setToScale(double sx, double sy, double sz) > public void setToScale(double sx, double sy, double sz, > double pivotX, double pivotY, double pivotZ) > public void setToRotation(double theta) > public void setToRotation(double theta, double pivotX, double pivotY) > public void setToRotation(double theta, > double axisX, double axisY, double axisZ, > double pivotX, double pivotY, double > pivotZ) > public void setToShear(double shx, double shy) > public void setToShear(double shx, double shy, double pivotX, > double pivotY) > > Operations on the matrix (modifying it in place): > public void invert() throws NoninvertibleTransformException > public void concatenate(Transform t) > public void concatenate(double Txx, double Txy, double Txz, double > Txt, > double Tyx, double Tyy, double Tyz, double > Tyt, > double Tzx, double Tzy, double Tzz, double > Tzt) > public void preConcatenate(Transform t) // left multiplication > public void preConcatenate(double Txx, double Txy, double Txz, > double Txt, > double Tyx, double Tyy, double Tyz, double Tyt, > double Tzx, double Tzy, double Tzz, double Tzt) > public void concatWithTranslation(double tx, double ty) > public void concatWithTranslation(double tx, double ty, double tz) > public void concatWithScale(double sx, double sy) > public void concatWithScale(double sx, double sy, double pivotX, > double pivotY) > public void concatWithScale(double sx, double sy, double sz) > public void concatWithScale(double sx, double sy, double sz, > double pivotX, double pivotY, double > pivotZ) > public void concatWithRotation(double theta) > public void concatWithRotation(double theta, double pivotX, double > pivotY) > public void concatWithRotation(double theta, > double axisX, double axisY, double axisZ, > double pivotX, double pivotY, double > pivotZ) > public void concatWithShear(double shx, double shy) > public void concatWithShear(double shx, double shy, double pivotX, > double pivotY) > public void preTranslate(double mxt, double myt) > public void preTranslate(double mxt, double myt, double mzt) > > Other methods: > public double getDeterminant() > > > Notes: > > Instead of "concatWithTranslation" it would be more natural to use > just "translate" (and similarly for the others), but unfortunately > these method names are already taken by the static factory methods on > Transform class. This is unpleasant but we need to be backward > compatible so we have to introduce different names. We'll be happy to > hear better naming suggestions than the concatWith* (which is pretty > descriptive I think but not really nice). > > To avoid even bigger method explosion this proposal doesn't contain > all the convenience "preConcatWith*" methods. However, we added > preTranslate, because it is needed quite often (and > preConcatWithTranslation looks quite horrible). Any comments to that? > > Should rotation axis be passed as Point3D (rather than the three > doubles), consistently with Rotate transform? > > Would you want static factory methods on Affine (creating Affine > instances with the simple transforms)? > > Would it be important to you whether or not matrix changes are atomic? > If you call one of the methods that modify the entire matrix, can be > listeners for each member called immediately as the members are set, > or do they need to be called after all the members are updated? > > Any missing operations? > > Thanks, > Pavel -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From pavel.safrata at oracle.com Thu Jul 12 08:14:07 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 17:14:07 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEE1CA.4050301@jugs.org> References: <4FFC437E.2070505@oracle.com> <4FFEE1CA.4050301@jugs.org> Message-ID: <4FFEE9BF.8050305@oracle.com> Sounds good. We already proposed 2D variants for all the methods using directly the simple transformations so this goes along with the proposal. It means: public Affine(double mxx, double mxy, double tx, double myx, double myy, double ty) Methods setToTransform, append and prepend with the same arguments. Thanks, Pavel On 12.7.2012 16:40, Dr. Michael Paus wrote: > I am not sure whether this has already been discussed but would it be > possible > to have a special variant of all constructors and methods, which > currently take > the full set of matrix elements, which only deal with the 2D subset of > matrix > elements? This would reduce the number of parameters that you have to > specify in most cases. It would also prevent an issue which I had some > time > ago where I specified all elements of a matrix explicitly and when I used > that matrix I lost all anti-aliasing. Don't know if this is still an > issue and what > the exact circumstances were. > > Michael > > Am 10.07.2012 17:00, schrieb Pavel Safrata: >> Hello, >> based on previous discussions, we're going to propose a set of new >> methods to our transforms. >> >> Tracking Jira issue: http://javafx-jira.kenai.com/browse/RT-17942 >> >> I hope the names are self-explanatory, otherwise please let me know >> and I'll provide some description. >> >> >> On Transform class: >> public Transform getConcatenation(Transform transform) // >> multiplication >> public Transform getInverse() throws >> NoninvertibleTransformException // negation >> public Transform copy() >> >> Note: in subclasses these methods will be overridden and will return >> more specific types where possible. >> >> >> On Affine class: >> >> Constructors: >> public Affine(Transform transform) >> public Affine(double mxx, double mxy, double mxz, double tx, >> double myx, double myy, double myz, double ty, >> double mzx, double mzy, double mzz, double tz) >> >> Setters of the entire matrix: >> public void setToTransform(Transform t) >> public void setToTransform(double mxx, double mxy, double mxz, >> double mxt, >> double myx, double myy, double myz, >> double myt, >> double mzx, double mzy, double mzz, >> double mzt) >> public void setToIdentity() >> public void setToTranslation(double tx, double ty) >> public void setToTranslation(double tx, double ty, double tz) >> public void setToScale(double sx, double sy) >> public void setToScale(double sx, double sy, double pivotX, >> double pivotY) >> public void setToScale(double sx, double sy, double sz) >> public void setToScale(double sx, double sy, double sz, >> double pivotX, double pivotY, double pivotZ) >> public void setToRotation(double theta) >> public void setToRotation(double theta, double pivotX, double >> pivotY) >> public void setToRotation(double theta, >> double axisX, double axisY, double axisZ, >> double pivotX, double pivotY, double >> pivotZ) >> public void setToShear(double shx, double shy) >> public void setToShear(double shx, double shy, double pivotX, >> double pivotY) >> >> Operations on the matrix (modifying it in place): >> public void invert() throws NoninvertibleTransformException >> public void concatenate(Transform t) >> public void concatenate(double Txx, double Txy, double Txz, >> double Txt, >> double Tyx, double Tyy, double Tyz, >> double Tyt, >> double Tzx, double Tzy, double Tzz, >> double Tzt) >> public void preConcatenate(Transform t) // left multiplication >> public void preConcatenate(double Txx, double Txy, double Txz, >> double Txt, >> double Tyx, double Tyy, double Tyz, double Tyt, >> double Tzx, double Tzy, double Tzz, double Tzt) >> public void concatWithTranslation(double tx, double ty) >> public void concatWithTranslation(double tx, double ty, double tz) >> public void concatWithScale(double sx, double sy) >> public void concatWithScale(double sx, double sy, double pivotX, >> double pivotY) >> public void concatWithScale(double sx, double sy, double sz) >> public void concatWithScale(double sx, double sy, double sz, >> double pivotX, double pivotY, double >> pivotZ) >> public void concatWithRotation(double theta) >> public void concatWithRotation(double theta, double pivotX, >> double pivotY) >> public void concatWithRotation(double theta, >> double axisX, double axisY, double axisZ, >> double pivotX, double pivotY, double >> pivotZ) >> public void concatWithShear(double shx, double shy) >> public void concatWithShear(double shx, double shy, double >> pivotX, double pivotY) >> public void preTranslate(double mxt, double myt) >> public void preTranslate(double mxt, double myt, double mzt) >> >> Other methods: >> public double getDeterminant() >> >> >> Notes: >> >> Instead of "concatWithTranslation" it would be more natural to use >> just "translate" (and similarly for the others), but unfortunately >> these method names are already taken by the static factory methods on >> Transform class. This is unpleasant but we need to be backward >> compatible so we have to introduce different names. We'll be happy to >> hear better naming suggestions than the concatWith* (which is pretty >> descriptive I think but not really nice). >> >> To avoid even bigger method explosion this proposal doesn't contain >> all the convenience "preConcatWith*" methods. However, we added >> preTranslate, because it is needed quite often (and >> preConcatWithTranslation looks quite horrible). Any comments to that? >> >> Should rotation axis be passed as Point3D (rather than the three >> doubles), consistently with Rotate transform? >> >> Would you want static factory methods on Affine (creating Affine >> instances with the simple transforms)? >> >> Would it be important to you whether or not matrix changes are >> atomic? If you call one of the methods that modify the entire matrix, >> can be listeners for each member called immediately as the members >> are set, or do they need to be called after all the members are updated? >> >> Any missing operations? >> >> Thanks, >> Pavel > > > From pavel.safrata at oracle.com Thu Jul 12 08:15:45 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 17:15:45 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFE7024.2090603@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> Message-ID: <4FFEEA21.2050907@oracle.com> Should the array-accepting methods accept also arrays of length 6 (containing only 2D-relevant elements)? Should the array-returning methods return 12 elements or 16? Thanks, Pavel On 12.7.2012 8:35, Pavel Safrata wrote: > Hi Kirill, > you are not right with the performance, the elements are (possibly > invalid) properties so we need to call all the getters anyway, plus > construct the array, so the performance is actually worse. But the > use-case seems to be valid, especially if the other libraries support > such conversion. I just wouldn't call it 'asArray' which suggests that > the array will keep updating with the matrix changes but rather > 'toArray'. To be consistent we need to use doubles instead of floats > and we should also add a similar setter. So I propose: > > public double[] toArray() > public double[] toArray(double[] a) > public Affine(double[] matrix) > public void setTransform(double[] matrix) > > Where the first two will behave similarly as if it was a List of 12 > doubles, the latter two will throw IllegalArgumentException if length > of the array is not 12. > > Regards, > Pavel > > On 12.7.2012 1:20, Kirill.Prazdnikov wrote: >> Hi Pavel, >> >> My typical use-case was to transfer matrix data between JavaFX and >> different libraries like 3D or physics. >> Use of one array with 12 (16) elements is by far simpler then passing >> 12 (16) arguments. >> And performance of one getter is better then 16 separate martix >> elements getters. >> >> Thanks >> -Kirill >> >> On 7/12/2012 12:17 AM, Pavel Safrata wrote: >>> Hi Kirill, >>> what is the use-case? I suspect that if you want the raw matrix to >>> do some math with it we are rather missing some operations doing the >>> math directly. >>> Thanks, >>> Pavel >>> >>> On 11.7.2012 21:35, Kirill.Prazdnikov wrote: >>>> Hi Pavel, >>>> >>>> I`m not sure, but many time times I found the following >>>> conversions as very useful: >>>> >>>> public float [] asArray(float data[12]); >>>> public Affine(float data[]); >>>> >>>> along with 12-arguments ctor. >>>> >>>> Thanks >>>> -Kirill >>>> >>>> On 7/11/2012 6:57 PM, Pavel Safrata wrote: >>>>> Hi Martin, >>>>> thank you for your input. >>>>> >>>>> On 10.7.2012 18:36, Martin Desruisseaux wrote: >>>>>> Hello Pavel >>>>>> >>>>>> Many thanks for taking care of this task! >>>>>> >>>>>> >>>>>> Le 10/07/12 17:00, Pavel Safrata a ?crit : >>>>>>> On Transform class: >>>>>>> public Transform getConcatenation(Transform transform) // >>>>>>> multiplication >>>>>>> public Transform getInverse() throws >>>>>>> NoninvertibleTransformException // negation >>>>>>> public Transform copy() >>>>>> Sound fine to me, while I'm not sure why a 'copy' method instead >>>>>> than overriding the 'clone()' method? >>>>> >>>>> Good point, we can use clone(). >>>>> >>>>>> >>>>>> >>>>>>> Constructors: >>>>>>> public Affine(Transform transform) >>>>>>> public Affine(double mxx, double mxy, double mxz, double tx, >>>>>>> double myx, double myy, double myz, double ty, >>>>>>> double mzx, double mzy, double mzz, double tz) >>>>>> Look fine. >>>>>> >>>>>> >>>>>>> Setters of the entire matrix: >>>>>>> (...snip...) >>>>>> I don't know for JavaFX, but in my experience with Java2D, I >>>>>> wasn't using the setter methods often, except 'setToIdentity' and >>>>>> 'setToTransform'. For example rather than invoking >>>>>> 'setToTranslation', I strongly push our developers to use >>>>>> 'translate' (or 'concatWithTranslation' in this proposal) >>>>>> instead. If a developer really wants the functionality of >>>>>> 'setToTranslation', he can get it by invoking 'setToIdentity()' >>>>>> followed by 'concatWithTranslation'. Or yet better, >>>>>> 'setToTransform(...)' instead than 'setToIdentity' with the >>>>>> coefficients of some previous state that the user saved. >>>>> >>>>> I don't insist on having the setters, anybody wants them? >>>>> >>>>>> >>>>>> The rational is that in many cases, the affine transform is >>>>>> already initialized to some important value. For example in >>>>>> Java2D, AffineTransform is initialized to the transform from >>>>>> 'dot' to whatever units the underlying device uses. When >>>>>> rendering on screen, this is the identity transform. But when >>>>>> printing, this is something different that depends on the printer >>>>>> resolution. In GIS applications, it depends on the zoom level. >>>>>> Other applications may use magnifier glass over some areas. >>>>>> Because the initial transform is often (but not always) the >>>>>> identity one, developers with limited experience with affine >>>>>> transforms often use 'setTranslate' or 'setScale' in situations >>>>>> where they should really use 'translate' or 'scale', and do not >>>>>> realize their bug before late in the development process. For >>>>>> this reason, I would be inclined to discourage every setter >>>>>> methods except 'setToIdentity()' and 'setToTransform'. Keeping in >>>>>> mind that it is often easier to fill a hole later than to fix >>>>>> something broken, I think it would be safer to leave out all >>>>>> other setter methods for now, and revisit later if experience >>>>>> show that they are really needed. >>>>>> >>>>> >>>>> While I don't think our Affine class will ever have varying >>>>> initial values I'm ok with keeping only setToIdentity() and >>>>> setToTransform() if there is no demand for the other setters right >>>>> now. >>>>> >>>>>> >>>>>>> Operations on the matrix (modifying it in place): >>>>>>> (...snip...) >>>>>> Sound good, minus the unfortunate 'concatWith*' naming :-(. >>>>>> >>>>>> >>>>>>> Instead of "concatWithTranslation" it would be more natural to >>>>>>> use just "translate" (and similarly for the others), but >>>>>>> unfortunately these method names are already taken by the static >>>>>>> factory methods on Transform class. This is unpleasant but we >>>>>>> need to be backward compatible so we have to introduce different >>>>>>> names. We'll be happy to hear better naming suggestions than the >>>>>>> concatWith* (which is pretty descriptive I think but not really >>>>>>> nice). >>>>>> Hard to say... A consistency with "preTranslate" would be nice, >>>>>> but "postTranslate" doesn't look very nice... What about the >>>>>> following? >>>>>> >>>>>> * Rename "preTranslate" as "appendTranslation" >>>>>> * Rename "concatWithTranslation" as "prependTranslation" >>>>>> >>>>>> The "preConcatenate(Tx)" name in Java2D was actually misleading >>>>>> to some developers, because it works as if points were first >>>>>> transformed by the original transform, then transformed by 'Tx'. >>>>>> Maybe "appendTranslation(Tx)" would make clear that the >>>>>> translation is applied after the original transform. This would >>>>>> also make operation order clearer. The following code using >>>>>> Java2D API: >>>>>> >>>>>> tr.translate(...) >>>>>> tr.scale(...) >>>>>> tr.rotate(...) >>>>>> >>>>>> must be read from bottom to up: it is as if points were rotated >>>>>> first, then scaled, then translated. So maybe the above >>>>>> proposition would make that more obvious: >>>>>> >>>>>> tr.prependTranslation(....) >>>>>> tr.prependScale(...) >>>>>> tr.prependRotate(...) >>>>>> tr.appendTranslation(...) // Just for fun. >>>>>> >>>>> >>>>> These names indeed sound way better. >>>>> >>>>> If we are going this way, shouldn't we do also this? >>>>> * Rename 'concatenate' as 'prepend' >>>>> * Rename 'preConcatenate' as 'append' >>>>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-) >>>>> >>>>> As a black-box transformation composing this makes sense. As a >>>>> matrix algebra, it may be also confusing: tA.append(tB) means >>>>> matrix multiplication 'B x A', does it sound good? Maybe yes, I'm >>>>> not sure. Anyway, so far the best proposal I think. >>>>> >>>>>> >>>>>>> Would you want static factory methods on Affine (creating Affine >>>>>>> instances with the simple transforms)? >>>>>> I don't think it is necessary. I found the static factory methods >>>>>> of Java2D AffineTransform rarely used. >>>>>> >>>>>>> Would it be important to you whether or not matrix changes are >>>>>>> atomic? If you call one of the methods that modify the entire >>>>>>> matrix, can be listeners for each member called immediately as >>>>>>> the members are set, or do they need to be called after all the >>>>>>> members are updated? >>>>>> I don't have experience in this area. But naively, it seems to we >>>>>> that it would be better to be notified only after the full matrix >>>>>> has been updated... >>>>> >>>>> Yes, I would also pick this option. It's just that it would mean >>>>> writing much more complicated (and a bit less effective) code so >>>>> the question is whether or not you think it is important. >>>>> >>>>> Thanks, >>>>> Pavel >>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From lehmann at media-interactive.de Thu Jul 12 08:32:42 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 12 Jul 2012 17:32:42 +0200 Subject: Scene Builder and Message-ID: <4FFEEE1A.1050608@media-interactive.de> Hi, today I tested the setRoot method on FXMLLoader, introduced with 2.2. After some trial and error (the docs do not seem to be updated) this seems to work fine, at least for my simple test. See below for some excerpts. However, I am wondering how this is intended to integrate with Scene Builder. Maybe as follows? 1. Create some FXML in scene builder. 2. Load in IDE and manually wrap root element (e.g. BorderPane) into a new element with namespace and type attribute. This will of course correspond to the pre-instantiated root class of that type, as opposed to an FXMLLoader instantiated controller. 3. Continue editing in scene builder. The last step does not work currently, using the latest FX 2.2 and Scene Builder versions. Scene Builder will throw NullPointerException on the line of the added element. I am guessing it does not know the class specified in the type attribute. This prevents further work the FXML in Scene Builder. I suppose Scene Builder could safely ignore that type and just continue to work with the child element (starting with BorderPane in my example). Otherwise, how shall I inform Scene Builder about my root class? The same question presents itself also for custom controls which are to be used somewhere in the FXML - so Scene Builder must know about them. Rgds Werner MintBackgroundJobsDialog.java: > public class MintBackgroundJobsDialog extends BorderPane > { > @FXML private Button bClearList; > > public MintBackgroundJobsDialog() throws IOException > { > FXMLLoader loader = new FXMLLoader(); > loader.setRoot(this); > loader.setController(this); > Object root = loader.load(getClass().getResource("MintBackgroundJobsDialog.fxml").openStream()); > System.out.println(root == this); > System.out.println(bClearList.getText()); > } > > public static void main(String[] args) throws IOException > { > new MintBackgroundJobsDialog(); > } > > @FXML > protected void clearListClicked() {} > } MintBackgroundJobsDialog.fxml: > > > > ... > > From greg.x.brown at oracle.com Thu Jul 12 09:10:30 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Thu, 12 Jul 2012 12:10:30 -0400 Subject: Scene Builder and In-Reply-To: <4FFEEE1A.1050608@media-interactive.de> References: <4FFEEE1A.1050608@media-interactive.de> Message-ID: <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> > today I tested the setRoot method on FXMLLoader, introduced with 2.2. After some trial and error (the docs do not seem to be updated) The docs were updated fairly recently. If they haven't made it into the latest beta, they should definitely be there for the final release. > However, I am wondering how this is intended to integrate with Scene Builder. Maybe as follows? > > 1. Create some FXML in scene builder. > > 2. Load in IDE and manually wrap root element (e.g. BorderPane) into a new element with namespace and type attribute. I'm not sure what level of support SB offers for fx:root right now, but the idea is that you would use it as follows: ? The fx:type attribute tells SB what type of element to expect. Later, when you load the document using FXMLLoader, you'll provide a concrete subclass of the specified type. G From daniel.fuchs at oracle.com Thu Jul 12 09:28:08 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Jul 2012 18:28:08 +0200 Subject: Scene Builder and In-Reply-To: <4FFEF98C.5080209@oracle.com> References: <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> <4FFEF98C.5080209@oracle.com> Message-ID: <4FFEFB18.7040707@oracle.com> > Subject: Re: Scene Builder and > Date: Thu, 12 Jul 2012 12:10:30 -0400 > From: Greg Brown > To: Werner Lehmann > CC: openjfx-dev at openjdk.java.net > Hi, As Greg says - you will need to provide a value for the fx:type attribute in fx:root - and you should be able to load that in SceneBuilder. SceneBuilder does not allow you to set fx:root from within SceneBuilder itself (I mean, if you create an FXML from within SceneBuilder it will not have the fx:root element) - but if you load an FXML whose root element is fx:root then SceneBuilder should be able to load it, and will preserve it. Hope this helps, -- daniel > >> today I tested the setRoot method on FXMLLoader, introduced with 2.2. After some trial and error (the docs do not seem to be updated) > > The docs were updated fairly recently. If they haven't made it into the latest beta, they should definitely be there for the final release. > >> However, I am wondering how this is intended to integrate with Scene Builder. Maybe as follows? >> >> 1. Create some FXML in scene builder. >> >> 2. Load in IDE and manually wrap root element (e.g. BorderPane) into a new element with namespace and type attribute. > > I'm not sure what level of support SB offers for fx:root right now, but the idea is that you would use it as follows: > > > ? > > > The fx:type attribute tells SB what type of element to expect. Later, when you load the document using FXMLLoader, you'll provide a concrete subclass of the specified type. > > G > > > > > From lehmann at media-interactive.de Thu Jul 12 09:58:26 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 12 Jul 2012 18:58:26 +0200 Subject: Scene Builder and In-Reply-To: <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> References: <4FFEEE1A.1050608@media-interactive.de> <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> Message-ID: <4FFF0232.5070508@media-interactive.de> On 12.07.2012 18:10, Greg Brown wrote: > The docs were updated fairly recently. If they haven't made it into > the latest beta, they should definitely be there for the final > release. I was referring to the FXML introduction which is (of course) still on 2.1 level. If there is an updated document for 2.2 I did not see it (and also cannot check now because of network problems). > I'm not sure what level of support SB offers for fx:root right now, > but the idea is that you would use it as follows: > > ? > > The fx:type attribute tells SB what type of element to expect. Later, > when you load the document using FXMLLoader, you'll provide a > concrete subclass of the specified type. Thank you - that works perfectly. My error was to use the custom type for fx:type, not BorderPane (etc). But then I could only guess what to use ;-) Werner From tom.schindl at bestsolution.at Thu Jul 12 10:00:00 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 12 Jul 2012 19:00:00 +0200 Subject: Scene Builder and In-Reply-To: <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> References: <4FFEEE1A.1050608@media-interactive.de> <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> Message-ID: <4FFF0290.7080804@bestsolution.at> Am 12.07.12 18:10, schrieb Greg Brown: >> today I tested the setRoot method on FXMLLoader, introduced with 2.2. After some trial and error (the docs do not seem to be updated) > > The docs were updated fairly recently. If they haven't made it into the latest beta, they should definitely be there for the final release. > >> However, I am wondering how this is intended to integrate with Scene Builder. Maybe as follows? >> >> 1. Create some FXML in scene builder. >> >> 2. Load in IDE and manually wrap root element (e.g. BorderPane) into a new element with namespace and type attribute. > > I'm not sure what level of support SB offers for fx:root right now, but the idea is that you would use it as follows: > > > ? > Is it possible that the attribute has to be named "type" and not "fx:type"? 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 greg.x.brown at oracle.com Thu Jul 12 10:07:34 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Thu, 12 Jul 2012 13:07:34 -0400 Subject: Scene Builder and In-Reply-To: <4FFF0232.5070508@media-interactive.de> References: <4FFEEE1A.1050608@media-interactive.de> <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> <4FFF0232.5070508@media-interactive.de> Message-ID: > I was referring to the FXML introduction which is (of course) still on 2.1 level. If there is an updated document for 2.2 I did not see it This doc has been updated for 2.2. However, I'm not sure if the updates made it into the latest beta or not. From lehmann at media-interactive.de Thu Jul 12 10:08:37 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 12 Jul 2012 19:08:37 +0200 Subject: Scene Builder and In-Reply-To: <4FFEFB18.7040707@oracle.com> References: <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> <4FFEF98C.5080209@oracle.com> <4FFEFB18.7040707@oracle.com> Message-ID: <4FFF0495.3010202@media-interactive.de> Daniel, On 12.07.2012 18:28, Daniel Fuchs wrote: > As Greg says - you will need to provide a value for the > fx:type attribute in fx:root - and you should be able > to load that in SceneBuilder. > > SceneBuilder does not allow you to set fx:root from within > SceneBuilder itself (I mean, if you create an FXML from > within SceneBuilder it will not have the fx:root element) - but > if you load an FXML whose root element is fx:root then > SceneBuilder should be able to load it, and will preserve it. that works indeed. I just had to use "BorderPane" as fx:root type attribute value instead of my derived class which SB cannot know about. What about my other question as to how custom controls can be used in Scene Builder? Can I add them to the library, and would it pick up any new properties on the right hand side of the SB window? Or, is it possible to just manually edit that part of the FXML but still use SB for the rest of it? Werner From lehmann at media-interactive.de Thu Jul 12 10:12:29 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 12 Jul 2012 19:12:29 +0200 Subject: Scene Builder and In-Reply-To: <4FFF0290.7080804@bestsolution.at> References: <4FFEEE1A.1050608@media-interactive.de> <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> <4FFF0290.7080804@bestsolution.at> Message-ID: <4FFF057D.2040106@media-interactive.de> Tom, On 12.07.2012 19:00, Tom Schindl wrote: > Is it possible that the attribute has to be named "type" and not "fx:type"? Correct but I was using it like that anyway. Apparently SB fails to (re)load the FXML when it contains "fx:type" - it has to be "type". Werner From greg.x.brown at oracle.com Thu Jul 12 10:16:43 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Thu, 12 Jul 2012 13:16:43 -0400 Subject: Scene Builder and In-Reply-To: <4FFF0290.7080804@bestsolution.at> References: <4FFEEE1A.1050608@media-interactive.de> <862E9A47-6A1F-43AC-96C9-747C303DF1EC@oracle.com> <4FFF0290.7080804@bestsolution.at> Message-ID: > Is it possible that the attribute has to be named "type" and not "fx:type"? Yes, my mistake - it is type, not fx:type. From martin.desruisseaux at geomatys.fr Thu Jul 12 10:22:57 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 19:22:57 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFEEA21.2050907@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> Message-ID: <4FFF07F1.2050108@geomatys.fr> Le 12/07/12 17:15, Pavel Safrata a ?crit : > Should the array-accepting methods accept also arrays of length 6 > (containing only 2D-relevant elements)? I don't see any objection. > Should the array-returning methods return 12 elements or 16? I don't see an obvious answer... Maybe the following method: > public double[] toArray(double[] a) could accept both. But I'm not sure what should be the default behavior when no destination array is given. Or maybe we could avoid the question by making the destination array mandatory. Martin From pavel.safrata at oracle.com Thu Jul 12 10:42:00 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 19:42:00 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFF07F1.2050108@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> Message-ID: <4FFF0C68.6020707@oracle.com> On 12.7.2012 19:22, Martin Desruisseaux wrote: > Le 12/07/12 17:15, Pavel Safrata a ?crit : >> Should the array-accepting methods accept also arrays of length 6 >> (containing only 2D-relevant elements)? > I don't see any objection. Me neither unless we know that it's completely useless and would only complicate the doc. > >> Should the array-returning methods return 12 elements or 16? > I don't see an obvious answer... Maybe the following method: > >> public double[] toArray(double[] a) > > could accept both. But I'm not sure what should be the default > behavior when no destination array is given. Or maybe we could avoid > the question by making the destination array mandatory. Even in this case I don't really like the inconsistency with List which allocates new array if the given one is not sufficient. I think we either need to choose one of the numbers or do public double[] toArray(MatrixArrayType type[, double[] a) where MatrixArrayType is an enum with values MAT_2D, MAT_3D, MAT_Full, requesting 6, 12, 16 numbers respectively. How does that sound? Thanks, Pavel > > Martin > From lehmann at media-interactive.de Thu Jul 12 11:06:24 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 12 Jul 2012 20:06:24 +0200 Subject: JFrame as Stage.owner? Message-ID: <4FFF1220.6090801@media-interactive.de> Hi, Stage can have an owner which is important for modality and z-order between windows. Is there a way to use a Swing JFrame as owner with similar or same semantics? This is for a Swing app whose parts are to be replaced with new JavaFX code, usually with JFXPanel. Now I would like to replace a modeless Swing dialog window with its FX counterpart. But how would that Stage be always on top of its "owner" - the Swing mainframe / JFrame? The only alternative I am seeing is to continue using JDialog etc with embedded JFXPanels until the whole application (the mainframe!) is converted to FX. This will take years and may never happen because there is at least one highly specialized 3rd party Swing control which I cannot put into a FX Scene node graph. Werner From daniel.fuchs at oracle.com Thu Jul 12 12:01:54 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Jul 2012 21:01:54 +0200 Subject: openjfx-dev Digest, Vol 8, Issue 25 In-Reply-To: References: Message-ID: <4FFF1F22.204@oracle.com> On 7/12/12 7:22 PM, openjfx-dev-request at openjdk.java.net wrote: > Date: Thu, 12 Jul 2012 19:08:37 +0200 > From: Werner Lehmann > Subject: Re: Scene Builder and > To:openjfx-dev at openjdk.java.net > Message-ID:<4FFF0495.3010202 at media-interactive.de> > Content-Type: text/plain; charset="windows-1252"; format=flowed Hi Werner, > Daniel, > > On 12.07.2012 18:28, Daniel Fuchs wrote: >> > As Greg says - you will need to provide a value for the >> > fx:type attribute in fx:root - and you should be able >> > to load that in SceneBuilder. >> > >> > SceneBuilder does not allow you to set fx:root from within >> > SceneBuilder itself (I mean, if you create an FXML from >> > within SceneBuilder it will not have the fx:root element) - but >> > if you load an FXML whose root element is fx:root then >> > SceneBuilder should be able to load it, and will preserve it. > that works indeed. I just had to use "BorderPane" as fx:root type > attribute value instead of my derived class which SB cannot know about. > > What about my other question as to how custom controls can be used in > Scene Builder? Can I add them to the library, and would it pick up any > new properties on the right hand side of the SB window? Or, is it > possible to just manually edit that part of the FXML but still use SB > for the rest of it? So several questions here: 1. No you cannot add your own controls to the Library with SceneBuilder 1.0. 2. However if your FXML already contains your own controls, SceneBuilder should be able to load it, unless they require specific builders/builder factory. At first load SceneBuilder will recognize that your FXML contains types that it does not know about - and will pop up dialog allowing you to enter a classpath. In some cases, SceneBuilder might be able to load the file even if you choose to not provide a classpath - but in that case - the unknown types will not be displayed - neither on the content view - nor in the hierarchy panel. Their FXML elements will be preserved however. If you choose to provide a classpath however, SceneBuilder should be able to render your custom controls, and you will be able to manipulate them. The properties that are specific to your controls will appear in a 'Miscellaneous' category in the inspector. Since SceneBuilder doesn't know about your custom types - it might not be able to display their subnodes in the Hierarchy Panel. For instance - if your control extends Pane, then SceneBuilder will assume that the children are to be found in the Pane.getChildren() property. However - if it extends Region directly - then the children will not be manipulable. In other words SceneBuilder sees the scenegraph through the lens of the javafx classes it knows about. 3. If you have provided a classpath - then copy/paste should work also for your custom types. So if you have an instance of "FooControl" you should be able to use copy/paste to create another one. 4. Be also aware that if your custom control behave badly - then anything could happen - for instance if one of your custom controls enters in an infinite loop during layout it can block the UI. So in practice - if you wish to add your own controls and work with them in SceneBuilder you could: a. create a skeleton FXML using SceneBuilder b. at the place where you would like to insert your own control, insert instead a place holder instance of its closest JavaFX super class. c. save and close the file. d. In NetBeans or Eclipse (or emacs ;-)) change the name of the place holder element, replace the name of the javafx class with your own custom class. Don't forget to add the appropriate clause at the beginning e. From File > Open Recent > - open your file again. You will get the pop up asking for a classpath. Provide the classpath and you should be able to load the file. hope this helps, -- daniel > > Werner From martin.desruisseaux at geomatys.fr Thu Jul 12 13:07:44 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 22:07:44 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFF0C68.6020707@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> Message-ID: <4FFF2E90.8080004@geomatys.fr> Le 12/07/12 19:42, Pavel Safrata a ?crit : > Even in this case I don't really like the inconsistency with List > which allocates new array if the given one is not sufficient. I think > we either need to choose one of the numbers or do > > public double[] toArray(MatrixArrayType type[, double[] a) > > where MatrixArrayType is an enum with values MAT_2D, MAT_3D, MAT_Full, > requesting 6, 12, 16 numbers respectively. How does that sound? Maybe I lack a little bit of JavaFX knowledge here, but how do we known for which axes are the 2D-relevant elements? Do the (x,y) plane is special enough in the JavaFX infrastructure for stating that the Affine 2D elements will never be (x,z) or (y,z)? Otherwise instead of MAT_2D we could define MAT_XY, MAT_XZ and MAT_YZ. But maybe there is an other issue: when I look at the matrices documented in the javadoc of every Transform subclasses except Affine (and maybe Rotate when the axis of rotation is not Z), I see X and Y axes that are independent of Z (i.e. the coefficients in the third column are zero for the first (X) and second (Y) rows). It make sense for those Transforms to extract a sub-transform for only the (x,y) plane, because transformations on that plane do not depend on the z value. But in the Affine class, the mxz and myz coefficients can be anything. Consequently the transformations on the (x,y) plane may not be independent of z. If we extract the 2D part of that matrix, we would need to specify in the javadoc that this two-dimensional transform is valid only for z=0. For other values of z, the translation terms of the two-dimensional transform may be different. Do we really want to afford this additional complexity? Martin From hang.vo at oracle.com Thu Jul 12 13:33:51 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 12 Jul 2012 20:33:51 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120712203357.8F0C447FD5@hg.openjdk.java.net> Changeset: a844e4fd4abf Author: David Grieve Date: 2012-07-12 16:20 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a844e4fd4abf RT-23256: ScrollPane with large content using mouse wheel is useless ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: eca72eaec20d Author: David Grieve Date: 2012-07-12 16:27 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/eca72eaec20d RT-22941 [ScrollBar, touch] knob is moving in wrong direction, when finger swipe is used. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java From pavel.safrata at oracle.com Thu Jul 12 13:48:54 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 22:48:54 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFF2E90.8080004@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> Message-ID: <4FFF3836.8080704@oracle.com> On 12.7.2012 22:07, Martin Desruisseaux wrote: > Le 12/07/12 19:42, Pavel Safrata a ?crit : >> Even in this case I don't really like the inconsistency with List >> which allocates new array if the given one is not sufficient. I think >> we either need to choose one of the numbers or do >> >> public double[] toArray(MatrixArrayType type[, double[] a) >> >> where MatrixArrayType is an enum with values MAT_2D, MAT_3D, >> MAT_Full, requesting 6, 12, 16 numbers respectively. How does that >> sound? > > Maybe I lack a little bit of JavaFX knowledge here, but how do we > known for which axes are the 2D-relevant elements? Do the (x,y) plane > is special enough in the JavaFX infrastructure for stating that the > Affine 2D elements will never be (x,z) or (y,z)? Otherwise instead of > MAT_2D we could define MAT_XY, MAT_XZ and MAT_YZ. In JavaFX the (x,y) plane is very special. If you use the scene in 2D you always work with the (x,y) plane. Any transform along z axis is considered 3D. > > But maybe there is an other issue: when I look at the matrices > documented in the javadoc of every Transform subclasses except Affine > (and maybe Rotate when the axis of rotation is not Z), I see X and Y > axes that are independent of Z (i.e. the coefficients in the third > column are zero for the first (X) and second (Y) rows). It make sense > for those Transforms to extract a sub-transform for only the (x,y) > plane, because transformations on that plane do not depend on the z > value. > > But in the Affine class, the mxz and myz coefficients can be anything. > Consequently the transformations on the (x,y) plane may not be > independent of z. If we extract the 2D part of that matrix, we would > need to specify in the javadoc that this two-dimensional transform is > valid only for z=0. For other values of z, the translation terms of > the two-dimensional transform may be different. Do we really want to > afford this additional complexity? I would probably leave responsibility on users. I think we could even throw an exception when user tries to obtain 2D matrix from a 3D transform. Pavel > > Martin > From pavel.safrata at oracle.com Thu Jul 12 14:00:59 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 12 Jul 2012 23:00:59 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFF3836.8080704@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> Message-ID: <4FFF3B0B.2070909@oracle.com> Better names might be MAT_2x3, MAT_3x4, MAT_4x4. Pavel On 12.7.2012 22:48, Pavel Safrata wrote: > > On 12.7.2012 22:07, Martin Desruisseaux wrote: >> Le 12/07/12 19:42, Pavel Safrata a ?crit : >>> Even in this case I don't really like the inconsistency with List >>> which allocates new array if the given one is not sufficient. I >>> think we either need to choose one of the numbers or do >>> >>> public double[] toArray(MatrixArrayType type[, double[] a) >>> >>> where MatrixArrayType is an enum with values MAT_2D, MAT_3D, >>> MAT_Full, requesting 6, 12, 16 numbers respectively. How does that >>> sound? >> >> Maybe I lack a little bit of JavaFX knowledge here, but how do we >> known for which axes are the 2D-relevant elements? Do the (x,y) plane >> is special enough in the JavaFX infrastructure for stating that the >> Affine 2D elements will never be (x,z) or (y,z)? Otherwise instead of >> MAT_2D we could define MAT_XY, MAT_XZ and MAT_YZ. > > In JavaFX the (x,y) plane is very special. If you use the scene in 2D > you always work with the (x,y) plane. Any transform along z axis is > considered 3D. > >> >> But maybe there is an other issue: when I look at the matrices >> documented in the javadoc of every Transform subclasses except Affine >> (and maybe Rotate when the axis of rotation is not Z), I see X and Y >> axes that are independent of Z (i.e. the coefficients in the third >> column are zero for the first (X) and second (Y) rows). It make sense >> for those Transforms to extract a sub-transform for only the (x,y) >> plane, because transformations on that plane do not depend on the z >> value. >> >> But in the Affine class, the mxz and myz coefficients can be >> anything. Consequently the transformations on the (x,y) plane may not >> be independent of z. If we extract the 2D part of that matrix, we >> would need to specify in the javadoc that this two-dimensional >> transform is valid only for z=0. For other values of z, the >> translation terms of the two-dimensional transform may be different. >> Do we really want to afford this additional complexity? > > I would probably leave responsibility on users. I think we could even > throw an exception when user tries to obtain 2D matrix from a 3D > transform. > > Pavel > >> >> Martin >> > > From martin.desruisseaux at geomatys.fr Thu Jul 12 14:19:09 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 12 Jul 2012 23:19:09 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFF3836.8080704@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> Message-ID: <4FFF3F4D.1010203@geomatys.fr> Le 12/07/12 22:48, Pavel Safrata a ?crit : > In JavaFX the (x,y) plane is very special. If you use the scene in 2D > you always work with the (x,y) plane. Any transform along z axis is > considered 3D. Thanks. I was suspecting that but wasn't completely sure. >> But in the Affine class, the mxz and myz coefficients can be >> anything. Consequently the transformations on the (x,y) plane may not >> be independent of z. If we extract the 2D part of that matrix, we >> would need to specify in the javadoc that this two-dimensional >> transform is valid only for z=0. For other values of z, the >> translation terms of the two-dimensional transform may be different. >> Do we really want to afford this additional complexity? > I would probably leave responsibility on users. I think we could even > throw an exception when user tries to obtain 2D matrix from a 3D > transform. I support the proposal of throwing an exception in such case. > Better names might be MAT_2x3, MAT_3x4, MAT_4x4. I agree, those names look quite clear to me. Martin From hang.vo at oracle.com Thu Jul 12 14:33:44 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 12 Jul 2012 21:33:44 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-21826 ImagePattern exception/background image load Message-ID: <20120712213348.C01B647FD7@hg.openjdk.java.net> Changeset: 802e47751653 Author: "Joseph Andresen" Date: 2012-07-12 14:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/802e47751653 RT-21826 ImagePattern exception/background image load ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java From hang.vo at oracle.com Thu Jul 12 15:58:15 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 12 Jul 2012 22:58:15 +0000 Subject: hg: openjfx/2.2/controls/rt: 6 new changesets Message-ID: <20120712225824.E576547FDB@hg.openjdk.java.net> Changeset: 32a2ac15cc0e Author: Kinsley Wong Date: 2012-07-12 15:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/32a2ac15cc0e [DOC ONLY] RT-20847: some css properties are not covered in cssref. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: dcc106432347 Author: Paru Somashekar Date: 2012-07-12 15:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/dcc106432347 fix RT-23057 PieChart draws garbage when at min size ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 74b5a4b24935 Author: Paru Somashekar Date: 2012-07-12 15:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/74b5a4b24935 fix RT-21295 Setting chart data to null disables chart animation ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 6c543a637228 Author: Paru Somashekar Date: 2012-07-12 15:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6c543a637228 fix RT-21164 BarChart: Adding several bars in a row produces upside down bars. ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java Changeset: 231378f0f928 Author: Paru Somashekar Date: 2012-07-12 15:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/231378f0f928 fix RT-19903 Call ObservableList#clear() for LineChart result on IndexOutOfBoundsException. ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java Changeset: 374f5352788f Author: Paru Somashekar Date: 2012-07-12 16:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/374f5352788f fix RT-18985 Slider labels disappear too eagerly ! javafx-ui-controls/src/javafx/scene/chart/Axis.java From hang.vo at oracle.com Thu Jul 12 16:36:31 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 12 Jul 2012 23:36:31 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120712233635.45B9347FDF@hg.openjdk.java.net> Changeset: 64f2c821ab4e Author: "Joseph Andresen" Date: 2012-07-09 14:22 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/64f2c821ab4e [javadoc] RT-22593 Effects: some treat as private docs missing ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java Changeset: 1d8c6251f243 Author: kcr Date: 2012-07-10 06:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1d8c6251f243 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: f28a395961d2 Author: hudson Date: 2012-07-11 12:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/f28a395961d2 Added tag 2.2-b17 for changeset 1d8c6251f243 ! .hgtags Changeset: aa283b2f20ad Author: Kinsley Wong Date: 2012-07-12 16:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/aa283b2f20ad Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt From daniel.fuchs at oracle.com Fri Jul 13 01:02:47 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 13 Jul 2012 10:02:47 +0200 Subject: Scene Builder and In-Reply-To: References: Message-ID: <4FFFD627.4090105@oracle.com> On 7/12/12 7:22 PM, openjfx-dev-request at openjdk.java.net wrote: > Date: Thu, 12 Jul 2012 19:08:37 +0200 > From: Werner Lehmann > Subject: Re: Scene Builder and > To:openjfx-dev at openjdk.java.net > Message-ID:<4FFF0495.3010202 at media-interactive.de> > Content-Type: text/plain; charset="windows-1252"; format=flowed Hi Werner, (sorry if this is a duplicate - I replied yesterday but forgot to fix the subject line - left (Re: openjfx-dev Digest, Vol 8, Issue 25) so I think my reply was lost) > Daniel, > > On 12.07.2012 18:28, Daniel Fuchs wrote: >> > As Greg says - you will need to provide a value for the >> > fx:type attribute in fx:root - and you should be able >> > to load that in SceneBuilder. >> > >> > SceneBuilder does not allow you to set fx:root from within >> > SceneBuilder itself (I mean, if you create an FXML from >> > within SceneBuilder it will not have the fx:root element) - but >> > if you load an FXML whose root element is fx:root then >> > SceneBuilder should be able to load it, and will preserve it. > that works indeed. I just had to use "BorderPane" as fx:root type > attribute value instead of my derived class which SB cannot know about. > > What about my other question as to how custom controls can be used in > Scene Builder? Can I add them to the library, and would it pick up any > new properties on the right hand side of the SB window? Or, is it > possible to just manually edit that part of the FXML but still use SB > for the rest of it? I see several questions here: 1. No you cannot add your own controls to the Library with SceneBuilder 1.0. 2. However if your FXML already contains your own controls, SceneBuilder should be able to load it, unless they require specific builders/builder factory. At first load SceneBuilder will recognize that your FXML contains types that it does not know about - and will pop up dialog allowing you to enter a classpath. In some cases, SceneBuilder might be able to load the file even if you choose to not provide a classpath - but in that case - the unknown types will not be displayed - neither on the content view - nor in the hierarchy panel. Their FXML elements will be preserved however. If you choose to provide a classpath however, SceneBuilder should be able to render your custom controls, and you will be able to manipulate them. The properties that are specific to your controls will appear in a 'Miscellaneous' category in the inspector on the right hand side. Since SceneBuilder doesn't know about your custom types - it might not be able to display their subnodes in the Hierarchy Panel. For instance - if your control extends Pane, then SceneBuilder will assume that the children are to be found in the Pane.getChildren() property. However - if it extends Region directly - then the children will not be displayed in the hierarchy. In other words SceneBuilder sees the scenegraph through the lens of the javafx classes it knows about. 3. If you have provided a classpath - then copy/paste should work also for your custom types. So if you have an instance of "FooControl" you should be able to use copy/paste to create another one. 4. Be also aware that if your custom control behave badly - then anything could happen - for instance if one of your custom controls enters in an infinite loop during layout it can block the UI. In practice - if you wish to add your own controls and work with them in SceneBuilder you could: a. create a skeleton FXML using SceneBuilder b. at the place where you would like to insert your own control, insert instead a place holder instance of its closest JavaFX super class. c. save and close the file. d. In NetBeans or Eclipse (or emacs ;-)) change the name of the place holder element, replace the name of the javafx class with your own custom class. Don't forget to add the appropriate clause at the beginning of the FXML file. e. From File > Open Recent > - open your file again. You will get the popup asking for a classpath. Provide the classpath and you should be able to load the file. hope this helps, -- daniel > > Werner From hang.vo at oracle.com Fri Jul 13 01:34:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Jul 2012 08:34:39 +0000 Subject: hg: openjfx/2.2/graphics/rt: Approved fix for RT-23062: Scene not getting garbage collected Message-ID: <20120713083443.9D8E14701C@hg.openjdk.java.net> Changeset: 2ca0c5dc56ee Author: Lubomir Nerad Date: 2012-07-13 10:25 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2ca0c5dc56ee Approved fix for RT-23062: Scene not getting garbage collected ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/scene/Scene.java From matthieu at brouillard.fr Fri Jul 13 01:56:28 2012 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Fri, 13 Jul 2012 10:56:28 +0200 Subject: Extending builders: PathBuilder In-Reply-To: <4FFDAD1C.2010501@oracle.com> References: <4FFDAD1C.2010501@oracle.com> Message-ID: Hello all, For me the strength of builder is that the user of the builder might not ask himself what the methods are doing, they have to be self explaining and there should be no ambiguity when using them. >From this then I would say that all the "final" methods in a builder should return not the builder itself but the built object. For example, if closePath() marks the end of the Path being built then just return the built Path and not the builder. For elements(), I have no strong arguments that either it should : - contribute by adding path elements in the current path (like Michael Paus suggests in the last comment of the issue) - be a full replacement of everything done before and then probably be a final builder method - be splitted in addElements(...) & replaceElements(...) which are more self explaining Personnaly, I would prefer the first one as it seems more natural to me. Another way also to clean the builders API in general can be to use some more interfaces. PathBuilder as filled in the Jira allows 2 categories of methods, the ones adding path elements and the ones modifying the graphical properties of the path being built. Saying that we could have it turned into: PathBuilder implements PathPropertyBuilder { ... PathBuilder lineTo(int x, int y); PathBuilder addElements(PathElement ... elements); PathPropertyBuilder replaceElements(PathElement ... elements); PathPropertyBuilder closePath(); ... } PathPropertyBuilder { .... strokeWidth(int width); strokeColor(Color c); .... Path build(); } Perhaps my suggestions does not help you directly to take a decision, but as you asked for opinions, I give mine :-) Matthieu Brouillard From eva.krejcirova at oracle.com Fri Jul 13 03:44:39 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Fri, 13 Jul 2012 12:44:39 +0200 Subject: Extending builders: PathBuilder In-Reply-To: References: <4FFDAD1C.2010501@oracle.com> Message-ID: <4FFFFC17.7070908@oracle.com> Hi Matthieu, Thanks for your feedback! Please see my comments inline. On 7/13/2012 10:56 AM, Matthieu BROUILLARD wrote: > Hello all, > > For me the strength of builder is that the user of the builder might not > ask himself what the methods are doing, they have to be self explaining and > there should be no ambiguity when using them. > > From this then I would say that all the "final" methods in a builder should > return not the builder itself but the built object. > For example, if closePath() marks the end of the Path being built then just > return the built Path and not the builder. I think that it might be a little confusing - all builders have the same behavior: their methods just store the state and the built object is created when build() method is called and we would break this. Also, you can continue building path even after closePath - moveTo(10,10).lineTo(20,20).lineTo(10,20).closePath().moveTo(30,30).lineTo(40,40).lineTo(30,40).closePath() is a valid path. > For elements(), I have no strong arguments that either it should : > > - contribute by adding path elements in the current path (like Michael > Paus suggests in the last comment of the issue) I agree that this would be user-friendly, but unfortunately this would change current behavior of elements() and might break already existing apps. We should not break backwards compatibility if possible. > - be a full replacement of everything done before and then probably be a > final builder method This is how I think it should behave (except for it being final builder method - even if we wanted it, we can't change the return type of elements(), it would break backwards compatibility). > - be splitted in addElements(...)& replaceElements(...) which are more > self explaining We could add such methods, but existing elements() method must remain there (backwards compatibility again :-) > Personnaly, I would prefer the first one as it seems more natural to me. > > Another way also to clean the builders API in general can be to use some > more interfaces. PathBuilder as filled in the Jira allows 2 categories of > methods, the ones adding path elements and the ones modifying the graphical > properties of the path being built. > Saying that we could have it turned into: > > PathBuilder implements PathPropertyBuilder { > ... > PathBuilder lineTo(int x, int y); > PathBuilder addElements(PathElement ... elements); > PathPropertyBuilder replaceElements(PathElement ... elements); > PathPropertyBuilder closePath(); > ... > } > > PathPropertyBuilder { > .... > strokeWidth(int width); > strokeColor(Color c); > .... > Path build(); > } Interesting idea! (Would be really hard to implement, though. The builders are generated automatically by our custom annotation processor, they are not written by hand) > > Perhaps my suggestions does not help you directly to take a decision, but > as you asked for opinions, I give mine :-) > > Matthieu Brouillard Thanks, there were some really interesting ideas! Eva From anthony.petrov at oracle.com Fri Jul 13 03:58:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jul 2012 14:58:49 +0400 Subject: JFrame as Stage.owner? In-Reply-To: <4FFF1220.6090801@media-interactive.de> References: <4FFF1220.6090801@media-interactive.de> Message-ID: <4FFFFF69.2050407@oracle.com> Hi Werner, This is not currently possible. The solution you describe at the end of your message is the way to go (ie using a JFXPanel embedded into a JDialog). -- best regards, Anthony On 7/12/2012 10:06 PM, Werner Lehmann wrote: > Stage can have an owner which is important for modality and z-order > between windows. Is there a way to use a Swing JFrame as owner with > similar or same semantics? > > This is for a Swing app whose parts are to be replaced with new JavaFX > code, usually with JFXPanel. Now I would like to replace a modeless > Swing dialog window with its FX counterpart. But how would that Stage be > always on top of its "owner" - the Swing mainframe / JFrame? > > The only alternative I am seeing is to continue using JDialog etc with > embedded JFXPanels until the whole application (the mainframe!) is > converted to FX. This will take years and may never happen because there > is at least one highly specialized 3rd party Swing control which I > cannot put into a FX Scene node graph. From lehmann at media-interactive.de Fri Jul 13 06:08:40 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 13 Jul 2012 15:08:40 +0200 Subject: JFrame as Stage.owner? In-Reply-To: <4FFFFF69.2050407@oracle.com> References: <4FFF1220.6090801@media-interactive.de> <4FFFFF69.2050407@oracle.com> Message-ID: <50001DD8.5050409@media-interactive.de> Hi Anthony, thanks for the clarification. Maybe I should file an RFE. Werner On 13.07.2012 12:58, Anthony Petrov wrote: > This is not currently possible. The solution you describe at the end of > your message is the way to go (ie using a JFXPanel embedded into a JDialog). From lehmann at media-interactive.de Fri Jul 13 06:28:25 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 13 Jul 2012 15:28:25 +0200 Subject: Classpath-relative URLs in CSS In-Reply-To: <4FC7AD6D.1040308@media-interactive.de> References: <4F956E01.9090701@oracle.com> <4F9580D4.60201@media-interactive.de> <81E70E8B-BA83-4FEB-846E-3E3199F6B5B7@oracle.com> <4FC7AD6D.1040308@media-interactive.de> Message-ID: <50002279.3070502@media-interactive.de> Hi, here is another problem with image url resolving in CSS. I observed this before as quoted below but would like to give it a little more focus now. Consider the following project structure (in Eclipse): Project 1 src/images/logo.jpg src/javafx/sheet1.css Project 2 (inherits classpath from Project 1) src/javafx/sheet2.css In sheet1.css I can access the image with something like url("../images/logo.jpg"). The problem is, I cannot do the same in sheet2.css: the image won't be found. As a consequence it is hard or impossible to share resources with other projects. I am guessing that the relative URL is processed with URI.resolve or something like that. Is it possible to use the classloader instead, or will this be included anyway with RT-21967? Thanks... Rgds Werner On 31.05.2012 19:42, Werner Lehmann wrote: > Also, it does not seem to work with resources inherited from a > dependency project (might be an Eclipse issue but I suppose it would > work if the class loader was used). From hang.vo at oracle.com Fri Jul 13 10:19:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Jul 2012 17:19:22 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120713171925.BCD824702F@hg.openjdk.java.net> Changeset: d12adf6ea5d5 Author: David Grieve Date: 2012-07-13 13:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d12adf6ea5d5 RT-21894: unit test ! javafx-ui-controls/test/javafx/scene/control/MenuButtonTest.java Changeset: 8b3da2148b1b Author: David Grieve Date: 2012-07-13 13:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8b3da2148b1b RT-21894: LabeledImpl needs to track the origin of the Labeled properites it does not mirror. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java From hang.vo at oracle.com Fri Jul 13 15:04:04 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Jul 2012 22:04:04 +0000 Subject: hg: openjfx/2.2/controls/rt: [DOC ONLY] added some comments to EmbeddedTextContextMenuContent. Message-ID: <20120713220407.438E147034@hg.openjdk.java.net> Changeset: d3c8bd0df966 Author: Kinsley Wong Date: 2012-07-13 14:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d3c8bd0df966 [DOC ONLY] added some comments to EmbeddedTextContextMenuContent. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/EmbeddedTextContextMenuContent.java From jmartine_1026 at yahoo.com Sat Jul 14 20:45:37 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Sat, 14 Jul 2012 20:45:37 -0700 (PDT) Subject: onMouseMoved problem i'm having Message-ID: <1342323937.39852.YahooMailNeo@web160906.mail.bf1.yahoo.com> Hello, If I move my mouse on a node a MouseMoved event is triggered. ?If I then press a button and the mouse is moved then its a MouseDragged event that is triggered. ?While having the button pressed, if I then press the other button then the MouseDragged event is still triggered. ?So far so good. ?But then if I release any of the buttons, either the first one pressed or the second one, then neither MouseDragged nor MouseMoved events are generated any more. ?If I proceed to press the released button or release the pressed one then the events are generated again. Is this a bug? ?It is a causing a problem for me. ?I have a situation where the primary button is pressed and I then rely on the MouseDragged event. ?The user could still press (and release) the secondary button but when they do the MouseDragged (and MouseMoved) stop being generated. I have test code for this if anyone wants to see it. ?https://s3.amazonaws.com/turretmaster/testing/MouseMoved.java thanks jose From Eli.Tsikel at sandisk.com Sun Jul 15 04:32:49 2012 From: Eli.Tsikel at sandisk.com (Eli Tsikel) Date: Sun, 15 Jul 2012 11:32:49 +0000 Subject: Embed VLC video output into a Scene Graph Message-ID: Hello, I'm trying to embed a VLC player in a JavaFX 2.2 application. For that I'm using the libvlc.dll library's API. VLC provided two ways to render a video: 1. Call API function that takes HWND: libvlc_media_player_set_hwnd (libvlc_media_player_t *p_mi, void *drawable) Set a Win32/Win64 API window handle (HWND) where the media player should render its video output. 2. Register a callback that gets called every time a frame should be rendered: libvlc_video_display_cb (void *opaque, void *picture) Callback prototype to display a picture. With the HWND approach, I managed to extract an HWND pointer of the Scene using Glass framework, causing the video to render on the whole scene, no other nodes are visible. With the Callback approach, and by using JavaFX 2.2 new javafx.scene.canvas.Canvas node, I was able to throw pixels at the canvas, but it turns to be very inefficient in terms of memory and thread usage. I would love to have a solution as with AWT + JNA: the HWND can be extracted from java.awt.Canvas component (using JNA), and be given to libvlc API function. This canvas can be placed anywhere in the frame, not occupying all the entire window. Hard Guidelines: 1. Integrating AWT/Swing with FX application is not an option, I want it to be a pure JavaFX application. 2. Using JavaFX Media API for playback is not an option, since I have a requirement to modify the media player's source code. 3. The video must not occupy the entire window, allowing other components to be visible. Possible solution is to create my own node or control that will wrap Glass component View that has a HWND but I don't know how to bind and make it work with other Glass components. Any help would be appreciated. Thank you. Eli. ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). From hang.vo at oracle.com Sun Jul 15 17:04:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Jul 2012 00:04:40 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120716000449.06FA347077@hg.openjdk.java.net> Changeset: b9a7024c3450 Author: jgiles Date: 2012-07-10 08:32 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b9a7024c3450 RT-23275: Editable combobox throws StackOverflowError when press ESC key ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 58bea6c6decc Author: jgiles Date: 2012-07-13 12:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/58bea6c6decc [DOC ONLY] RT-23308: All impl_* methods must be hidden from javadoc and marked as deprecated ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: e848c165aaa9 Author: jgiles Date: 2012-07-16 11:18 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/e848c165aaa9 RT-22972: ComboBox with dynamic item list : issue with the "Empty" label ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 5ba93f3d48b7 Author: jgiles Date: 2012-07-16 11:57 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/5ba93f3d48b7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From pavel.safrata at oracle.com Mon Jul 16 00:28:28 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 16 Jul 2012 09:28:28 +0200 Subject: onMouseMoved problem i'm having In-Reply-To: <1342323937.39852.YahooMailNeo@web160906.mail.bf1.yahoo.com> References: <1342323937.39852.YahooMailNeo@web160906.mail.bf1.yahoo.com> Message-ID: <5003C29C.4030206@oracle.com> Hello Jose, this is a bug, even a regression. I've just filed it: http://javafx-jira.kenai.com/browse/RT-23442 Thanks, Pavel On 15.7.2012 5:45, Jose Martinez wrote: > Hello, > > If I move my mouse on a node a MouseMoved event is triggered. If I then press a button and the mouse is moved then its a MouseDragged event that is triggered. While having the button pressed, if I then press the other button then the MouseDragged event is still triggered. So far so good. But then if I release any of the buttons, either the first one pressed or the second one, then neither MouseDragged nor MouseMoved events are generated any more. If I proceed to press the released button or release the pressed one then the events are generated again. > > Is this a bug? It is a causing a problem for me. I have a situation where the primary button is pressed and I then rely on the MouseDragged event. The user could still press (and release) the secondary button but when they do the MouseDragged (and MouseMoved) stop being generated. > > I have test code for this if anyone wants to see it. https://s3.amazonaws.com/turretmaster/testing/MouseMoved.java > > thanks > jose From neugens.limasoftware at gmail.com Mon Jul 16 02:21:13 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 16 Jul 2012 11:21:13 +0200 Subject: Embed VLC video output into a Scene Graph In-Reply-To: References: Message-ID: 2012/7/15 Eli Tsikel : > Hello, > > I'm trying to embed a VLC player in a JavaFX 2.2 application. > For that I'm using the libvlc.dll library's API. > > VLC provided two ways to render a video: > 1. Call API function that takes HWND: libvlc_media_player_set_hwnd (libvlc_media_player_t *p_mi, void *drawable) Set a Win32/Win64 API window handle (HWND) where the media player should render its video output. > 2. Register a callback that gets called every time a frame should be rendered: libvlc_video_display_cb (void *opaque, void *picture) Callback prototype to display a picture. > > With the HWND approach, I managed to extract an HWND pointer of the Scene using Glass framework, causing the video to render on the whole scene, no other nodes are visible. > With the Callback approach, and by using JavaFX 2.2 new javafx.scene.canvas.Canvas node, I was able to throw pixels at the canvas, but it turns to be very inefficient in terms of memory and thread usage. > > I would love to have a solution as with AWT + JNA: the HWND can be extracted from java.awt.Canvas component (using JNA), and be given to libvlc API function. This canvas can be placed anywhere in the frame, not occupying all the entire window. I'm not the right person to suggest an approach since it's quite some time I don't use JavaFX and I don't know what additions have been made the the 2.2 API to facilitate custom rendering, however, we did something similar for our ThingFX project to allow Swing inside JavaFX (the other way around what it's usually possible). We render the Swing components as "snapshots" inside a JavaFX Image node. Image didn't offer us a way to update a specific portion of the underlying buffered image, but I don't think this is an issue for a video since the video will likely render the full frame each time. Here is the example: https://github.com/thingsfx/ThingsFX/blob/master/src/main/java/com/thingsfx/widget/swing/BufferedImageView.java As you see is pretty straightforward. Here is an example of the things we did: http://www.jroller.com/neugens/entry/jfreechartfx http://www.jroller.com/neugens/entry/javafx_as_image_processing_library Btw, I'm not suggesting to use Swing BufferedImages (which would be very useful if you need to perform some custom rendering outside what JavaFX allows you to do already on the nodes) but to exploit JavaFX Images. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From pavel.safrata at oracle.com Mon Jul 16 04:00:41 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 16 Jul 2012 13:00:41 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <4FFF3F4D.1010203@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> Message-ID: <5003F459.7030304@oracle.com> Thanks guys for all the suggestions. Here is the updated complete proposal. On Transform class: public Transform createConcatenation(Transform transform) // Creates new concatenated transform that is equivalent to // this transform applied first and the given transform second // Means multiplication on the left by the given transform public Transform createInverse() throws NoninvertibleTransformException // Creates a negated transform public double get(int col, int row) // Convenience getter for the individual elements // Accepts both params in range 0..3, throws IllegalArgument otherwise public double[] toArray(MatrixArrayType type) // Transform.MatrixArrayType is an enum { MAT_2x3, MAT_3x4, MAT_4x4 } // Returns array of length 6, 12, 16, respectively // Throws IllegalArgument if 2x3 is requested for a 3D transform public double[] toArray(MatrixArrayType type, double[] array) // Similar to the above, just uses the passed array if it is big enough public Transform clone() // Of course Transform implementing Cloneable // in subclasses the methods returning Transform will be overridden and // will return more specific types where possible. On Affine class: Constructors: public Affine(Transform transform) public Affine(double mxx, double mxy, double tx, double myx, double myy, double ty) public Affine(double mxx, double mxy, double mxz, double tx, double myx, double myy, double myz, double ty, double mzx, double mzy, double mzz, double tz) public Affine(double[] matrix) // accepts arrays of length 6, 12 and 16. // In case of 16 members the last four numbers must be 0, 0, 0, 1 // throws IllegalArgument if the above conditions are not met Setters of the entire matrix: public void setToTransform(Transform t) public void setToTransform(double mxx, double mxy, double tx, double myx, double myy, double ty) public void setToTransform(double mxx, double mxy, double mxz, double mxt, double myx, double myy, double myz, double myt, double mzx, double mzy, double mzz, double mzt) public void setToTransform(double[] matrix) // the same acceptance criteria as the constructor public void setToIdentity() Operations on the matrix (modifying it in place): public void invert() throws NoninvertibleTransformException public void append(Transform t) public void append(double mxx, double mxy, double tx, double myx, double myy, double ty) public void append(double Txx, double Txy, double Txz, double Txt, double Tyx, double Tyy, double Tyz, double Tyt, double Tzx, double Tzy, double Tzz, double Tzt) public void append(double[] matrix) public void appendTranslation(double tx, double ty) public void appendTranslation(double tx, double ty, double tz) public void appendScale(double sx, double sy) public void appendScale(double sx, double sy, double pivotX, double pivotY) public void appendScale(double sx, double sy, double sz) public void appendScale(double sx, double sy, double sz, double pivotX, double pivotY, double pivotZ) public void appendRotation(double theta) public void appendRotation(double theta, double pivotX, double pivotY) public void appendRotation(double theta, double axisX, double axisY, double axisZ, double pivotX, double pivotY, double pivotZ) public void appendShear(double shx, double shy) public void appendShear(double shx, double shy, double pivotX, double pivotY) // "append" means "add the transformation after the existing one", so // "append" means multiply this matrix on the left by the given matrix public void prepend* // 15 methods // Every append* method has its prepend* companion, // adding the transformation before the existing one, // multiplying on the right Other methods: public void set(int row, int col, double value) // convenience setter for the individual elements // accepts row and col in range 0..3 // allows to set the last row only to 0, 0, 0, 1 // throws IllegalArgument if the above conditions are not met public double getDeterminant() Regards, Pavel From martin.desruisseaux at geomatys.fr Mon Jul 16 04:17:28 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Mon, 16 Jul 2012 13:17:28 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5003F459.7030304@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> Message-ID: <5003F848.7070502@geomatys.fr> Hello Pavel Thanks for the update. All the methods sound fine to me :-). There is some very minor observations: Le 16/07/12 13:00, Pavel Safrata a ?crit : > public double get(int col, int row) Should the parameter order follows the convention in matrix indices, which is (row, column)? > public double[] toArray(MatrixArrayType type) > // Transform.MatrixArrayType is an enum { MAT_2x3, MAT_3x4, > MAT_4x4 } > // Returns array of length 6, 12, 16, respectively Should we provide also a MAT_3x3 enum (array of length 9) for consistency with MAT_4x4? > public double[] toArray(MatrixArrayType type, double[] array) > // Similar to the above, just uses the passed array if it is > big enough If this method accept null array, maybe we could omit toArray(MatrixArrayType type) in order to simplify a little bit the API? Martin From pavel.safrata at oracle.com Mon Jul 16 04:26:30 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 16 Jul 2012 13:26:30 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5003F459.7030304@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> Message-ID: <5003FA66.3030102@oracle.com> One more idea: we should probably add type MAT_3x3 and accept arrays of length 9 (for 2D transforms only, with the last row always 0, 0, 1). Pavel On 16.7.2012 13:00, Pavel Safrata wrote: > Thanks guys for all the suggestions. Here is the updated complete > proposal. > > On Transform class: > public Transform createConcatenation(Transform transform) > // Creates new concatenated transform that is equivalent to > // this transform applied first and the given transform second > // Means multiplication on the left by the given transform > public Transform createInverse() throws > NoninvertibleTransformException > // Creates a negated transform > public double get(int col, int row) > // Convenience getter for the individual elements > // Accepts both params in range 0..3, throws IllegalArgument > otherwise > public double[] toArray(MatrixArrayType type) > // Transform.MatrixArrayType is an enum { MAT_2x3, MAT_3x4, > MAT_4x4 } > // Returns array of length 6, 12, 16, respectively > // Throws IllegalArgument if 2x3 is requested for a 3D transform > public double[] toArray(MatrixArrayType type, double[] array) > // Similar to the above, just uses the passed array if it is > big enough > public Transform clone() > // Of course Transform implementing Cloneable > > // in subclasses the methods returning Transform will be > overridden and > // will return more specific types where possible. > > On Affine class: > > Constructors: > public Affine(Transform transform) > public Affine(double mxx, double mxy, double tx, > double myx, double myy, double ty) > public Affine(double mxx, double mxy, double mxz, double tx, > double myx, double myy, double myz, double ty, > double mzx, double mzy, double mzz, double tz) > public Affine(double[] matrix) > // accepts arrays of length 6, 12 and 16. > // In case of 16 members the last four numbers must be 0, 0, 0, 1 > // throws IllegalArgument if the above conditions are not met > > Setters of the entire matrix: > public void setToTransform(Transform t) > public void setToTransform(double mxx, double mxy, double tx, > double myx, double myy, double ty) > public void setToTransform(double mxx, double mxy, double mxz, > double mxt, > double myx, double myy, double myz, > double myt, > double mzx, double mzy, double mzz, > double mzt) > public void setToTransform(double[] matrix) > // the same acceptance criteria as the constructor > public void setToIdentity() > > Operations on the matrix (modifying it in place): > public void invert() throws NoninvertibleTransformException > public void append(Transform t) > public void append(double mxx, double mxy, double tx, > double myx, double myy, double ty) > public void append(double Txx, double Txy, double Txz, double Txt, > double Tyx, double Tyy, double Tyz, double Tyt, > double Tzx, double Tzy, double Tzz, double Tzt) > public void append(double[] matrix) > > public void appendTranslation(double tx, double ty) > public void appendTranslation(double tx, double ty, double tz) > public void appendScale(double sx, double sy) > public void appendScale(double sx, double sy, double pivotX, > double pivotY) > public void appendScale(double sx, double sy, double sz) > public void appendScale(double sx, double sy, double sz, > double pivotX, double pivotY, double pivotZ) > public void appendRotation(double theta) > public void appendRotation(double theta, double pivotX, double > pivotY) > public void appendRotation(double theta, > double axisX, double axisY, double axisZ, > double pivotX, double pivotY, double > pivotZ) > public void appendShear(double shx, double shy) > public void appendShear(double shx, double shy, double pivotX, > double pivotY) > > // "append" means "add the transformation after the existing one", so > // "append" means multiply this matrix on the left by the given > matrix > > public void prepend* // 15 methods > // Every append* method has its prepend* companion, > // adding the transformation before the existing one, > // multiplying on the right > > > Other methods: > public void set(int row, int col, double value) > // convenience setter for the individual elements > // accepts row and col in range 0..3 > // allows to set the last row only to 0, 0, 0, 1 > // throws IllegalArgument if the above conditions are not met > > public double getDeterminant() > > Regards, > Pavel > > From kirill.prazdnikov at oracle.com Mon Jul 16 04:28:30 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Mon, 16 Jul 2012 15:28:30 +0400 Subject: Affine transforms - matrix algebra In-Reply-To: <5003F459.7030304@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> Message-ID: <5003FADE.8040408@oracle.com> Hi Pavel, > public Affine(double[] matrix) > // accepts arrays of length 6, 12 and 16. > // In case of 16 members the last four numbers must be 0, 0, 0, 1 > // throws IllegalArgument if the above conditions are not met What is the point of setting 4x4 matrix of the last row must be 0,0,0,1 ? Should we remove 4x4 case at all ? Thanks From pavel.safrata at oracle.com Mon Jul 16 04:35:14 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 16 Jul 2012 13:35:14 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5003F848.7070502@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003F848.7070502@geomatys.fr> Message-ID: <5003FC72.4040203@oracle.com> Hello, On 16.7.2012 13:17, Martin Desruisseaux wrote: > Hello Pavel > > Thanks for the update. All the methods sound fine to me :-). There is > some very minor observations: > > Le 16/07/12 13:00, Pavel Safrata a ?crit : >> public double get(int col, int row) > Should the parameter order follows the convention in matrix indices, > which is (row, column)? Yes, just my "typo". > >> public double[] toArray(MatrixArrayType type) >> // Transform.MatrixArrayType is an enum { MAT_2x3, MAT_3x4, >> MAT_4x4 } >> // Returns array of length 6, 12, 16, respectively > Should we provide also a MAT_3x3 enum (array of length 9) for > consistency with MAT_4x4? Yes, I've come to that conclusion as well (see my other email) :-) > >> public double[] toArray(MatrixArrayType type, double[] array) >> // Similar to the above, just uses the passed array if it is >> big enough > If this method accept null array, maybe we could omit > toArray(MatrixArrayType type) in order to simplify a little bit the API? I would keep both methods. It will make user code cleaner when there is no array to pass in, which I think may happen quite often. Moreover users are used to have both methods from java collections, so they might miss it. Thanks, Pavel > > Martin > From martin.desruisseaux at geomatys.fr Mon Jul 16 04:36:28 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Mon, 16 Jul 2012 13:36:28 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5003FADE.8040408@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> Message-ID: <5003FCBC.60202@geomatys.fr> Le 16/07/12 13:28, Kirill.Prazdnikov a ?crit : > What is the point of setting 4x4 matrix of the last row must be 0,0,0,1 ? > Should we remove 4x4 case at all ? The array could be the result of a computation performed by some other Linear Algebra library, which may not be aware of the affine special case. However I don't know if this use case would be common or not. Martin From pavel.safrata at oracle.com Mon Jul 16 04:37:10 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 16 Jul 2012 13:37:10 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5003FADE.8040408@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> Message-ID: <5003FCE6.2010701@oracle.com> Hi Kirill, it is just for convenience. The point is that if you have algorithms or other libraries that use the fourth row, you can work with the array right away. Regards, Pavel On 16.7.2012 13:28, Kirill.Prazdnikov wrote: > Hi Pavel, > >> public Affine(double[] matrix) >> // accepts arrays of length 6, 12 and 16. >> // In case of 16 members the last four numbers must be 0, 0, >> 0, 1 >> // throws IllegalArgument if the above conditions are not met > > What is the point of setting 4x4 matrix of the last row must be 0,0,0,1 ? > Should we remove 4x4 case at all ? > > Thanks > > From elisa.deaibess at gmail.com Mon Jul 16 05:33:22 2012 From: elisa.deaibess at gmail.com (Elisa Deaibess) Date: Mon, 16 Jul 2012 15:33:22 +0300 Subject: Writing Custom UI Controls Message-ID: Hi, We are writing a new application using JavaFX 2.x. Our application needs some custom controls such as a searchfield, listoptions, ribbon, breadcrumbs, etc... We decided to write common reusable controls; To do that we have 2 ways: 1. Make our controls extends Control and create new skin 2. Extend some layout container or other control Which one do you recommend? Is it safe that our custom controls extends Control and to use the skin/behavior? Or com.sun.javafx.scene.control.skin.SkinBase is a private class and risk to be removed in the next releases In JavaFXPro book I read the following: *Caution *In the discussion that follows, we mention Java classes in packages whose names begin with com.sun. These classes are implementation details of the JavaFX runtime system and are not meant to be used in normal JavaFX applications. And they may change in future releases of JavaFX. Could you please advise? Regards, Elisa From greg.x.brown at oracle.com Mon Jul 16 05:55:31 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Mon, 16 Jul 2012 08:55:31 -0400 Subject: Writing Custom UI Controls In-Reply-To: References: Message-ID: <3B0736B0-2BF5-4776-9CD5-935ACDFE9F49@oracle.com> > We are writing a new application using JavaFX 2.x. Our application needs > some custom controls such as a searchfield, listoptions, ribbon, > breadcrumbs, etc... > > We decided to write common reusable controls; To do that we have 2 ways: > > 1. Make our controls extends Control and create new skin > 2. Extend some layout container or other control JavaFX 2.2 contains some new features that make #2 much easier if you are defining the structure of your custom controls using FXML. See the "Custom Components" section of the "Introduction to FXML" document in the 2.2 Javadoc for more information. Greg From elisa.deaibess at gmail.com Mon Jul 16 06:07:22 2012 From: elisa.deaibess at gmail.com (Elisa Deaibess) Date: Mon, 16 Jul 2012 16:07:22 +0300 Subject: Writing Custom UI Controls In-Reply-To: <3B0736B0-2BF5-4776-9CD5-935ACDFE9F49@oracle.com> References: <3B0736B0-2BF5-4776-9CD5-935ACDFE9F49@oracle.com> Message-ID: Hi, Thanks Greg for your response. Currently we aren't using FXML, we are using JavaFX java api. Regards, Elisa On Mon, Jul 16, 2012 at 3:55 PM, Greg Brown wrote: > > We are writing a new application using JavaFX 2.x. Our application needs > > some custom controls such as a searchfield, listoptions, ribbon, > > breadcrumbs, etc... > > > > We decided to write common reusable controls; To do that we have 2 ways: > > > > 1. Make our controls extends Control and create new skin > > 2. Extend some layout container or other control > > JavaFX 2.2 contains some new features that make #2 much easier if you are > defining the structure of your custom controls using FXML. See the "Custom > Components" section of the "Introduction to FXML" document in the 2.2 > Javadoc for more information. > > Greg > > > From greg.x.brown at oracle.com Mon Jul 16 06:22:17 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Mon, 16 Jul 2012 09:22:17 -0400 Subject: Writing Custom UI Controls In-Reply-To: References: <3B0736B0-2BF5-4776-9CD5-935ACDFE9F49@oracle.com> Message-ID: For small, self-contained controls like a search field or breadcrumb, option #1 is probably best (though I'm not sure if it is considered "public" yet - someone else may want to comment on that). For more complex controls that aggregate other controls (such as a ribbon), I'd suggest #2. I'd also highly recommend looking into FXML if possible. Greg On Jul 16, 2012, at 9:07 AM, Elisa Deaibess wrote: > Hi, > > Thanks Greg for your response. > Currently we aren't using FXML, we are using JavaFX java api. > > Regards, > Elisa > > On Mon, Jul 16, 2012 at 3:55 PM, Greg Brown wrote: > > We are writing a new application using JavaFX 2.x. Our application needs > > some custom controls such as a searchfield, listoptions, ribbon, > > breadcrumbs, etc... > > > > We decided to write common reusable controls; To do that we have 2 ways: > > > > 1. Make our controls extends Control and create new skin > > 2. Extend some layout container or other control > > JavaFX 2.2 contains some new features that make #2 much easier if you are defining the structure of your custom controls using FXML. See the "Custom Components" section of the "Introduction to FXML" document in the 2.2 Javadoc for more information. > > Greg > > > From elisa.deaibess at gmail.com Mon Jul 16 07:20:11 2012 From: elisa.deaibess at gmail.com (Elisa Deaibess) Date: Mon, 16 Jul 2012 17:20:11 +0300 Subject: Writing Custom UI Controls In-Reply-To: References: <3B0736B0-2BF5-4776-9CD5-935ACDFE9F49@oracle.com> Message-ID: Hi, Thanks again Greg. For sure I'll look at the recommended FXML Can anyone please advise if it is safe to use com.sun.javafx.scene.control.skin.SkinBase? is it considered "public"? Or it can be removed in the next releases? Regards, Elisa On Mon, Jul 16, 2012 at 4:22 PM, Greg Brown wrote: > For small, self-contained controls like a search field or breadcrumb, > option #1 is probably best (though I'm not sure if it is considered > "public" yet - someone else may want to comment on that). For more complex > controls that aggregate other controls (such as a ribbon), I'd suggest #2. > I'd also highly recommend looking into FXML if possible. > Greg > > On Jul 16, 2012, at 9:07 AM, Elisa Deaibess wrote: > > Hi, > > Thanks Greg for your response. > Currently we aren't using FXML, we are using JavaFX java api. > > Regards, > Elisa > > On Mon, Jul 16, 2012 at 3:55 PM, Greg Brown wrote: > >> > We are writing a new application using JavaFX 2.x. Our application needs >> > some custom controls such as a searchfield, listoptions, ribbon, >> > breadcrumbs, etc... >> > >> > We decided to write common reusable controls; To do that we have 2 ways: >> > >> > 1. Make our controls extends Control and create new skin >> > 2. Extend some layout container or other control >> >> JavaFX 2.2 contains some new features that make #2 much easier if you are >> defining the structure of your custom controls using FXML. See the "Custom >> Components" section of the "Introduction to FXML" document in the 2.2 >> Javadoc for more information. >> >> Greg >> >> >> > > From richard.bair at oracle.com Mon Jul 16 08:16:25 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 16 Jul 2012 08:16:25 -0700 Subject: Writing Custom UI Controls In-Reply-To: References: <3B0736B0-2BF5-4776-9CD5-935ACDFE9F49@oracle.com> Message-ID: <0F4BF646-2CD8-4A8D-8DE8-0EFA9D3FB557@oracle.com> Hi Elise, Extending Control carries with it certain benefits: - it supports tooltips directly - the skin of the control can be changed (from code or CSS) If the reusable controls you want to build are intended to by style able (especially if intended to be reused outside your current application) then extending Control is the right way to go. There is enough public API that you can create controls and skins yourself that will interoperate, however you have to provide some infrastructure yourself such as how to handle CSS styling (have your skin implementation extend region) and how to handle multi-platform keystrokes (since behavior is not public). The Lombard (nominally, 3.0) product plan includes an item about making more of this infrastructure public so that you can more easily create well behaved controls. One thing we've discussed is to have Control extend Region and create a public SkinBase, replacing our current one, for example. So for sure you cannot rely on our private API since we have ideas that those private classes might be removed. Of course, those classes are open source so you can copy/paste our implementation in your own project as long as you are in compliance with the license. GPL makes this kind of a pain though for commercial apps. Richard On Jul 16, 2012, at 7:20 AM, Elisa Deaibess wrote: > Hi, > > Thanks again Greg. For sure I'll look at the recommended FXML > > Can anyone please advise if it is safe to use > com.sun.javafx.scene.control.skin.SkinBase? > is it considered "public"? Or it can be removed in the next releases? > > Regards, > Elisa > > On Mon, Jul 16, 2012 at 4:22 PM, Greg Brown wrote: > >> For small, self-contained controls like a search field or breadcrumb, >> option #1 is probably best (though I'm not sure if it is considered >> "public" yet - someone else may want to comment on that). For more complex >> controls that aggregate other controls (such as a ribbon), I'd suggest #2. >> I'd also highly recommend looking into FXML if possible. >> Greg >> >> On Jul 16, 2012, at 9:07 AM, Elisa Deaibess wrote: >> >> Hi, >> >> Thanks Greg for your response. >> Currently we aren't using FXML, we are using JavaFX java api. >> >> Regards, >> Elisa >> >> On Mon, Jul 16, 2012 at 3:55 PM, Greg Brown wrote: >> >>>> We are writing a new application using JavaFX 2.x. Our application needs >>>> some custom controls such as a searchfield, listoptions, ribbon, >>>> breadcrumbs, etc... >>>> >>>> We decided to write common reusable controls; To do that we have 2 ways: >>>> >>>> 1. Make our controls extends Control and create new skin >>>> 2. Extend some layout container or other control >>> >>> JavaFX 2.2 contains some new features that make #2 much easier if you are >>> defining the structure of your custom controls using FXML. See the "Custom >>> Components" section of the "Introduction to FXML" document in the 2.2 >>> Javadoc for more information. >>> >>> Greg >>> >>> >>> >> >> From tbee at tbee.org Mon Jul 16 08:33:34 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 16 Jul 2012 17:33:34 +0200 Subject: Writing Custom UI Controls In-Reply-To: <0F4BF646-2CD8-4A8D-8DE8-0EFA9D3FB557@oracle.com> References: <3B0736B0-2BF5-4776-9CD5-935ACDFE9F49@oracle.com> <0F4BF646-2CD8-4A8D-8DE8-0EFA9D3FB557@oracle.com> Message-ID: <5004344D.8080903@tbee.org> And let me add that custom controls are very welcome at the jfxtras.org project. In this way other people can benefit from your work and you can use what we have done so far. Tom On 2012-07-16 17:16, Richard Bair wrote: > Hi Elise, > > Extending Control carries with it certain benefits: > - it supports tooltips directly > - the skin of the control can be changed (from code or CSS) > > If the reusable controls you want to build are intended to by style able (especially if intended to be reused outside your current application) then extending Control is the right way to go. > > There is enough public API that you can create controls and skins yourself that will interoperate, however you have to provide some infrastructure yourself such as how to handle CSS styling (have your skin implementation extend region) and how to handle multi-platform keystrokes (since behavior is not public). The Lombard (nominally, 3.0) product plan includes an item about making more of this infrastructure public so that you can more easily create well behaved controls. > > One thing we've discussed is to have Control extend Region and create a public SkinBase, replacing our current one, for example. So for sure you cannot rely on our private API since we have ideas that those private classes might be removed. > > Of course, those classes are open source so you can copy/paste our implementation in your own project as long as you are in compliance with the license. GPL makes this kind of a pain though for commercial apps. > > Richard > > On Jul 16, 2012, at 7:20 AM, Elisa Deaibess wrote: > >> Hi, >> >> Thanks again Greg. For sure I'll look at the recommended FXML >> >> Can anyone please advise if it is safe to use >> com.sun.javafx.scene.control.skin.SkinBase? >> is it considered "public"? Or it can be removed in the next releases? >> >> Regards, >> Elisa >> >> On Mon, Jul 16, 2012 at 4:22 PM, Greg Brown wrote: >> >>> For small, self-contained controls like a search field or breadcrumb, >>> option #1 is probably best (though I'm not sure if it is considered >>> "public" yet - someone else may want to comment on that). For more complex >>> controls that aggregate other controls (such as a ribbon), I'd suggest #2. >>> I'd also highly recommend looking into FXML if possible. >>> Greg >>> >>> On Jul 16, 2012, at 9:07 AM, Elisa Deaibess wrote: >>> >>> Hi, >>> >>> Thanks Greg for your response. >>> Currently we aren't using FXML, we are using JavaFX java api. >>> >>> Regards, >>> Elisa >>> >>> On Mon, Jul 16, 2012 at 3:55 PM, Greg Brown wrote: >>> >>>>> We are writing a new application using JavaFX 2.x. Our application needs >>>>> some custom controls such as a searchfield, listoptions, ribbon, >>>>> breadcrumbs, etc... >>>>> >>>>> We decided to write common reusable controls; To do that we have 2 ways: >>>>> >>>>> 1. Make our controls extends Control and create new skin >>>>> 2. Extend some layout container or other control >>>> JavaFX 2.2 contains some new features that make #2 much easier if you are >>>> defining the structure of your custom controls using FXML. See the "Custom >>>> Components" section of the "Introduction to FXML" document in the 2.2 >>>> Javadoc for more information. >>>> >>>> Greg >>>> >>>> >>>> >>> From hang.vo at oracle.com Mon Jul 16 10:02:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Jul 2012 17:02:56 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-20845: TextField with bidirectional binding is not editable in applet but editable in standalone execution mode Message-ID: <20120716170259.95CEC4708E@hg.openjdk.java.net> Changeset: 7e06dda995b5 Author: leifs Date: 2012-07-16 18:57 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7e06dda995b5 Fixed RT-20845: TextField with bidirectional binding is not editable in applet but editable in standalone execution mode ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java From christian.schudt at gmx.de Mon Jul 16 09:09:47 2012 From: christian.schudt at gmx.de (Christian Schudt) Date: Mon, 16 Jul 2012 18:09:47 +0200 Subject: Writing Custom UI Controls In-Reply-To: References: Message-ID: <051C90E3-A96A-4D52-849E-F2828C018F7D@gmx.de> Hi, I wondered about that topic, too. I do it that way, that I only use Control and Skin (public API) I put all the behavior in the class which implements Skin. Sometimes, I also derive from layout containers or other controls. I think this depends on what you want to achieve and what base implementation helps you most. If you want to layout stuff, use layout containers. If you want to extend some functionality (e.g. I added maxLength to the TextField), derive from an existing control. Otherwise derive from Control. Just the use of the BehaviorBase is questionable. Regards Christian Am 16.07.2012 um 14:33 schrieb Elisa Deaibess: > Hi, > > We are writing a new application using JavaFX 2.x. Our application needs > some custom controls such as a searchfield, listoptions, ribbon, > breadcrumbs, etc... > > We decided to write common reusable controls; To do that we have 2 ways: > > 1. Make our controls extends Control and create new skin > 2. Extend some layout container or other control > > > Which one do you recommend? > Is it safe that our custom controls extends Control and to use the > skin/behavior? Or com.sun.javafx.scene.control.skin.SkinBase is a private > class and risk to be removed in the next releases > > In JavaFXPro book I read the following: > > *Caution *In the discussion that follows, we mention Java classes in > packages whose names begin with com.sun. > These classes are implementation details of the JavaFX runtime system and > are not meant to be used in normal JavaFX applications. > And they may change in future releases of JavaFX. > > Could you please advise? > > Regards, > Elisa From richard.bair at oracle.com Mon Jul 16 10:15:57 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 16 Jul 2012 10:15:57 -0700 Subject: Writing Custom UI Controls In-Reply-To: <051C90E3-A96A-4D52-849E-F2828C018F7D@gmx.de> References: <051C90E3-A96A-4D52-849E-F2828C018F7D@gmx.de> Message-ID: <1ED57E21-A59B-4561-BB96-D39B1B810C76@oracle.com> Ya. And to provide a little background, originally in 1.0 we talked about making Behavior a public API along with Skin and Control. It was always the idea. However as we got close we realized that Behavior just wasn't (a) strictly necessary and (b) vetted enough to be public. In particular, I always wanted the same kind of functionality in UI controls that we had with Actions and ActionMaps in Swing components. But we didn't have time to do a proper Action / Command pattern investigation and implementation, and so I didn't think Behavior was ready to be public API, since it would necessarily have some overlap there. And strictly speaking until we expose the action map concept, there is no need for Behavior to be public (and maybe, depending on how we do it, you won't need to have Behavior public anyway). So instead it became an aid in our implementation to help separate the UI design from the interaction logic. In some cases this was very clean and helpful (since in theory unit testing a Behavior should be much, much easier than testing a Skin) and also has the benefit that in some cases it makes it easier to write new skins and reuse existing behaviors. In some controls like TextInputControl, this breaks down quickly and requires some extra complication because the UI design and interaction design are so closely linked (as opposed to something like, say, a Button). Long story short, it just isn't ready for prime time, but it is on the plan for 3.0 to get this sort of infrastructure (as far as we are able in the time) public. Richard On Jul 16, 2012, at 9:09 AM, Christian Schudt wrote: > Hi, > > I wondered about that topic, too. > > I do it that way, that I only use Control and Skin (public API) > I put all the behavior in the class which implements Skin. > > Sometimes, I also derive from layout containers or other controls. > I think this depends on what you want to achieve and what base implementation helps you most. > If you want to layout stuff, use layout containers. If you want to extend some functionality (e.g. I added maxLength to the TextField), derive from an existing control. > Otherwise derive from Control. > > Just the use of the BehaviorBase is questionable. > > Regards > Christian > > > > Am 16.07.2012 um 14:33 schrieb Elisa Deaibess: > >> Hi, >> >> We are writing a new application using JavaFX 2.x. Our application needs >> some custom controls such as a searchfield, listoptions, ribbon, >> breadcrumbs, etc... >> >> We decided to write common reusable controls; To do that we have 2 ways: >> >> 1. Make our controls extends Control and create new skin >> 2. Extend some layout container or other control >> >> >> Which one do you recommend? >> Is it safe that our custom controls extends Control and to use the >> skin/behavior? Or com.sun.javafx.scene.control.skin.SkinBase is a private >> class and risk to be removed in the next releases >> >> In JavaFXPro book I read the following: >> >> *Caution *In the discussion that follows, we mention Java classes in >> packages whose names begin with com.sun. >> These classes are implementation details of the JavaFX runtime system and >> are not meant to be used in normal JavaFX applications. >> And they may change in future releases of JavaFX. >> >> Could you please advise? >> >> Regards, >> Elisa > From hang.vo at oracle.com Mon Jul 16 10:32:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Jul 2012 17:32:06 +0000 Subject: hg: openjfx/2.2/controls/rt: fix RT-21141 XYChart changes categories order spontaneously on Remove DataItem Message-ID: <20120716173207.16CF647095@hg.openjdk.java.net> Changeset: a6dd0e5c4451 Author: Paru Somashekar Date: 2012-07-16 10:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a6dd0e5c4451 fix RT-21141 XYChart changes categories order spontaneously on Remove DataItem ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java From richard.bair at oracle.com Mon Jul 16 11:25:18 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 16 Jul 2012 11:25:18 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <5003FCE6.2010701@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> Message-ID: <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> Hi Pavel, Before approving I want Jim Graham to have a look. He's been on vacation, I think he either gets back today or next week. Thanks! Richard On Jul 16, 2012, at 4:37 AM, Pavel Safrata wrote: > Hi Kirill, > it is just for convenience. The point is that if you have algorithms or other libraries that use the fourth row, you can work with the array right away. > Regards, > Pavel > > On 16.7.2012 13:28, Kirill.Prazdnikov wrote: >> Hi Pavel, >> >>> public Affine(double[] matrix) >>> // accepts arrays of length 6, 12 and 16. >>> // In case of 16 members the last four numbers must be 0, 0, 0, 1 >>> // throws IllegalArgument if the above conditions are not met >> >> What is the point of setting 4x4 matrix of the last row must be 0,0,0,1 ? >> Should we remove 4x4 case at all ? >> >> Thanks >> >> > > From hang.vo at oracle.com Mon Jul 16 11:47:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Jul 2012 18:47:39 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-23395 Canvas Exception J2D Message-ID: <20120716184744.453684709B@hg.openjdk.java.net> Changeset: 871aea815e7a Author: "Joseph Andresen" Date: 2012-07-16 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/871aea815e7a RT-23395 Canvas Exception J2D ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java From kevin.rushforth at oracle.com Mon Jul 16 12:00:15 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 Jul 2012 12:00:15 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> Message-ID: <500464BF.7020806@oracle.com> I would also like a chance to look at this, but have been too busy with 2.2 end game (which should ease up this week). -- Kevin Richard Bair wrote: > Hi Pavel, > > Before approving I want Jim Graham to have a look. He's been on vacation, I think he either gets back today or next week. > > Thanks! > Richard > > On Jul 16, 2012, at 4:37 AM, Pavel Safrata wrote: > > >> Hi Kirill, >> it is just for convenience. The point is that if you have algorithms or other libraries that use the fourth row, you can work with the array right away. >> Regards, >> Pavel >> >> On 16.7.2012 13:28, Kirill.Prazdnikov wrote: >> >>> Hi Pavel, >>> >>> >>>> public Affine(double[] matrix) >>>> // accepts arrays of length 6, 12 and 16. >>>> // In case of 16 members the last four numbers must be 0, 0, 0, 1 >>>> // throws IllegalArgument if the above conditions are not met >>>> >>> What is the point of setting 4x4 matrix of the last row must be 0,0,0,1 ? >>> Should we remove 4x4 case at all ? >>> >>> Thanks >>> >>> >>> >> > > From hang.vo at oracle.com Mon Jul 16 12:32:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Jul 2012 19:32:26 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120716193228.E5047470A0@hg.openjdk.java.net> Changeset: 7c7bc01e9da4 Author: jgiles Date: 2012-07-17 07:16 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7c7bc01e9da4 Backed out changeset: e848c165aaa9 (RT-22972: ComboBox with dynamic item list : issue with the "Empty" label) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 264470ba524e Author: jgiles Date: 2012-07-17 07:17 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/264470ba524e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From pavel.safrata at oracle.com Mon Jul 16 12:49:35 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 16 Jul 2012 21:49:35 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> Message-ID: <5004704F.5010607@oracle.com> Hello, Ok, Richard, thanks. I have one more question that I asked earlier but that has not been addressed in this discussion: do we want to use Point3D for rotation axis? It would be consistent with Rotate and it would be convenient to use the Rotate.*_AXIS constants. In the other hand, it would often force users to create unnecessary Point3D instances. Or do we want both? Currently it means public void appendRotation(double theta, double pivotX, double pivotY, double pivotZ, double axisX, double axisY, double axisZ) vs. public void appendRotation(double theta, double pivotX, double pivotY, double pivotZ, Point3D axis) and similarly for prepend. Here is once more the complete proposal with a few minor issues fixed (added 3x3 matrix handling, fixed row/col parameter order, fixed pivot/axis parameter order): On Transform class: public Transform createConcatenation(Transform transform) // Creates new concatenated transform that is equivalent to // this transform applied first and the given transform second // Means multiplication on the left by the given transform public Transform createInverse() throws NoninvertibleTransformException // Creates a negated transform public double get(int row, int col) // Convenience getter for the individual elements // Accepts both params in range 0..3, throws IllegalArgument otherwise public double[] toArray(MatrixArrayType type) // Transform.MatrixArrayType is an enum { MAT_2x3, MAT_3x3, MAT_3x4, MAT_4x4 } // Returns array of length 6, 9, 12, 16, respectively // Throws IllegalArgument if 2x3 or 3x3 is requested for a 3D transform public double[] toArray(MatrixArrayType type, double[] array) // Similar to the above, just uses the passed array if it is big enough public Transform clone() // Of course Transform implementing Cloneable // in subclasses the methods returning Transform will be overridden and will return more specific types where possible. On Affine class: Constructors: public Affine(Transform transform) public Affine(double mxx, double mxy, double tx, double myx, double myy, double ty) public Affine(double mxx, double mxy, double mxz, double tx, double myx, double myy, double myz, double ty, double mzx, double mzy, double mzz, double tz) public Affine(double[] matrix) // accepts arrays of length 6, 9, 12 and 16. // In case of 9 members the last three numbers must be 0, 0, 1 // In case of 16 members the last four numbers must be 0, 0, 0, 1 // throws IllegalArgument if the above conditions are not met Setters of the entire matrix: public void setToTransform(Transform t) public void setToTransform(double mxx, double mxy, double tx, double myx, double myy, double ty) public void setToTransform(double mxx, double mxy, double mxz, double mxt, double myx, double myy, double myz, double myt, double mzx, double mzy, double mzz, double mzt) public void setToTransform(double[] matrix) // the same acceptance criteria as the constructor public void setToIdentity() Operations on the matrix (modifying it in place): public void invert() throws NoninvertibleTransformException public void append(Transform t) public void append(double mxx, double mxy, double tx, double myx, double myy, double ty) public void append(double Txx, double Txy, double Txz, double Txt, double Tyx, double Tyy, double Tyz, double Tyt, double Tzx, double Tzy, double Tzz, double Tzt) public void append(double[] matrix) public void appendTranslation(double tx, double ty) public void appendTranslation(double tx, double ty, double tz) public void appendScale(double sx, double sy) public void appendScale(double sx, double sy, double pivotX, double pivotY) public void appendScale(double sx, double sy, double sz) public void appendScale(double sx, double sy, double sz, double pivotX, double pivotY, double pivotZ) public void appendRotation(double theta) public void appendRotation(double theta, double pivotX, double pivotY) public void appendRotation(double theta, double pivotX, double pivotY, double pivotZ, double axisX, double axisY, double axisZ) public void appendShear(double shx, double shy) public void appendShear(double shx, double shy, double pivotX, double pivotY) // "append" means "add the transformation after the existing one", so // "append" means multiply this matrix on the left by the given matrix public void prepend* // 15 methods // Every append* method has its prepend* companion, // adding the transformation before the existing one, // multiplying on the right Other methods: public void set(int row, int col, double value) // convenience setter for the individual elements // accepts row and col in range 0..3 // allows to set the last row only to 0, 0, 0, 1 // throws IllegalArgument if the above conditions are not met public double getDeterminant() Thanks, Pavel On 16.7.2012 20:25, Richard Bair wrote: > Hi Pavel, > > Before approving I want Jim Graham to have a look. He's been on vacation, I think he either gets back today or next week. > > Thanks! > Richard > > On Jul 16, 2012, at 4:37 AM, Pavel Safrata wrote: > >> Hi Kirill, >> it is just for convenience. The point is that if you have algorithms or other libraries that use the fourth row, you can work with the array right away. >> Regards, >> Pavel >> >> On 16.7.2012 13:28, Kirill.Prazdnikov wrote: >>> Hi Pavel, >>> >>>> public Affine(double[] matrix) >>>> // accepts arrays of length 6, 12 and 16. >>>> // In case of 16 members the last four numbers must be 0, 0, 0, 1 >>>> // throws IllegalArgument if the above conditions are not met >>> What is the point of setting 4x4 matrix of the last row must be 0,0,0,1 ? >>> Should we remove 4x4 case at all ? >>> >>> Thanks >>> >>> >> From richard.bair at oracle.com Mon Jul 16 12:51:14 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 16 Jul 2012 12:51:14 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <5004704F.5010607@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004704F.5010607@oracle.com> Message-ID: > I have one more question that I asked earlier but that has not been addressed in this discussion: do we want to use Point3D for rotation axis? It would be consistent with Rotate and it would be convenient to use the Rotate.*_AXIS constants. In the other hand, it would often force users to create unnecessary Point3D instances. Or do we want both? Currently it means > public void appendRotation(double theta, > double pivotX, double pivotY, double pivotZ, > double axisX, double axisY, double axisZ) > vs. > public void appendRotation(double theta, > double pivotX, double pivotY, double pivotZ, > Point3D axis) > and similarly for prepend. Seems to me it would be worth it to have the Point3D variants, since for normal cases it doesn't require creation of temp objects (I just use the constants), but in the animation case I can avoid it. Thanks Richard From pavel.safrata at oracle.com Mon Jul 16 13:08:34 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 16 Jul 2012 22:08:34 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004704F.5010607@oracle.com> Message-ID: <500474C2.6090405@oracle.com> On 16.7.2012 21:51, Richard Bair wrote: >> I have one more question that I asked earlier but that has not been addressed in this discussion: do we want to use Point3D for rotation axis? It would be consistent with Rotate and it would be convenient to use the Rotate.*_AXIS constants. In the other hand, it would often force users to create unnecessary Point3D instances. Or do we want both? Currently it means >> public void appendRotation(double theta, >> double pivotX, double pivotY, double pivotZ, >> double axisX, double axisY, double axisZ) >> vs. >> public void appendRotation(double theta, >> double pivotX, double pivotY, double pivotZ, >> Point3D axis) >> and similarly for prepend. > Seems to me it would be worth it to have the Point3D variants, since for normal cases it doesn't require creation of temp objects (I just use the constants), but in the animation case I can avoid it. Do I get it correctly that you prefer to have both variants? Thanks, Pavel > > Thanks > Richard From richard.bair at oracle.com Mon Jul 16 14:05:46 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 16 Jul 2012 14:05:46 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <500474C2.6090405@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004704F.5010607@oracle.com> <500474C2.6090405@oracle.com> Message-ID: ya. On Jul 16, 2012, at 1:08 PM, Pavel Safrata wrote: > On 16.7.2012 21:51, Richard Bair wrote: >>> I have one more question that I asked earlier but that has not been addressed in this discussion: do we want to use Point3D for rotation axis? It would be consistent with Rotate and it would be convenient to use the Rotate.*_AXIS constants. In the other hand, it would often force users to create unnecessary Point3D instances. Or do we want both? Currently it means >>> public void appendRotation(double theta, >>> double pivotX, double pivotY, double pivotZ, >>> double axisX, double axisY, double axisZ) >>> vs. >>> public void appendRotation(double theta, >>> double pivotX, double pivotY, double pivotZ, >>> Point3D axis) >>> and similarly for prepend. >> Seems to me it would be worth it to have the Point3D variants, since for normal cases it doesn't require creation of temp objects (I just use the constants), but in the animation case I can avoid it. > > Do I get it correctly that you prefer to have both variants? > Thanks, > Pavel > >> >> Thanks >> Richard > > From tom.schindl at bestsolution.at Mon Jul 16 14:05:52 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 16 Jul 2012 23:05:52 +0200 Subject: TextField#setText(null)? Message-ID: <50048230.4050104@bestsolution.at> Hi, Is it a problem in the JavaDoc but calling TextField#setText(null) results not directly in an error but an NPE once you try to type something into the control: -----------8<----------- TextField f = new TextField(); f.setText(null); primaryStage.setScene(new Scene(b)); primaryStage.setWidth(200); primaryStage.setHeight(200); primaryStage.show(); -----------8<----------- The line with the NPE is in TextInputControlBehavior.defaultKeyTyped line 219 > undoManager.addChange(start, textInput.getText().substring(start, end), character, true); textInput.getText() is null, the problem is when binding e.g. a bean where the value is NULL initially one gets NPEs so this is a major bug. If NULL is not allowed for f.setText() it should throw an IllegalArgumentException immediately I think, not? 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 jmartine_1026 at yahoo.com Mon Jul 16 18:55:21 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Mon, 16 Jul 2012 18:55:21 -0700 (PDT) Subject: problem with builders Message-ID: <1342490121.76193.YahooMailNeo@web160903.mail.bf1.yahoo.com> I am having a problem with some of the builders.... maybe I'm doing something wrong. ?If I instantiate a builder (e.g. LabelBuilder) then if I edit it (e.g. .text("txt") ) then the compiler complaints that the build() method is not present. ?Its as if the .text() method does not returns a LabelBuilder. ?It does not happen with all builders, I have not tested enough to pick up on a pattern. Here are some examples..... //will not compile ? ? ? ? LabelBuilder lb = LabelBuilder.create(); ? ? ? ? Label label = lb.text("txt").build(); ? ? ? ?? //compiles ? ? ? ? StackPaneBuilder spb = StackPaneBuilder.create(); ? ? ? ? StackPane sp = spb.alignment(Pos.CENTER).build(); ? ? ? ?? //will not compile ? ? ? ? RectangleBuilder rb = RectangleBuilder.create(); ? ? ? ? Rectangle r = rb.fill(Color.ALICEBLUE).build(); thanks? jose From hang.vo at oracle.com Mon Jul 16 19:54:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 17 Jul 2012 02:54:34 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix RT-23433: Failures in ByteBgr, ByteBgra, ByteArgb conversion loops found by unit test. Message-ID: <20120717025438.CC638470B3@hg.openjdk.java.net> Changeset: 49d71d1bc5af Author: flar Date: 2012-07-16 19:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/49d71d1bc5af Fix RT-23433: Failures in ByteBgr,ByteBgra,ByteArgb conversion loops found by unit test. Reviewed by Kevin, approved by bug court. ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgra.java ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgb.java ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgba.java + javafx-ui-common/test/unit/com/sun/javafx/image/ConverterTest.java From james.graham at oracle.com Mon Jul 16 21:08:27 2012 From: james.graham at oracle.com (Jim Graham) Date: Mon, 16 Jul 2012 21:08:27 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> Message-ID: <5004E53B.3060108@oracle.com> Oh my! What a discussion! OK, here are my thoughts after having perused most of the discussion: - Canning setToFoo() - I agree, it encouraged too many people to delete an existing transform simply due to thinking that was the method they wanted and I'd rather force them to use "setToIdentity" so it is obvious that they are destroying information. To the person who said "our Affine objects won't contain a transform" - ummm, which Affine objects? Yes, if you construct one it will have identity, but as we add methods to get Affine objects from the environment, those objects will not be identity, so this issue remains real. - append/prepend are problematical. I don't think 2D got it "wrong", I think it did it one way that was actually based on prior work, but there are a number of developers who came from a different background that had the reverse expectation. Simply saying "X confused some people so Y must be the right answer" misses the point that some people were not confused by X and might be confused by Y. Also, if that was a problem, we've already fought that battle getting people used to 2D's system so if we reverse course now then we simply rub everyone's face in it. Sigh. Is there some new terminology that we could use that doesn't trigger expectations? - We already have GraphicsContext in 2.2 that has "translate, scale, etc." I would hope that the "appendFoo()" methods would work like those, but I have the sneaky suspicion that I read in the discussion that actually the prepend methods are closer to those. Consider how a developer that was used to "I scaled then I translated" would view append/prepend? That sounds to me like the scale happened and then the translate was "appended to the list of operations as if one called it after scale in some Canvas code". Also, append should probably reflect what happens when you get the list of Transform objects from a Node and then append some new Transform objects to the end of that list. Prepend should match what happens when you place new Transform objects at the head of that same Node.getTransforms() list. - append might mean a matrix operation with the math going one way, but it might also mean "then after you step into that coordinate system, you do this operation from that perspective", and it might also mean "after you move everything around and you are staring at the transformed objects from outside (i.e. the point of view of the universe), you then move it again like this" and all of those will result in different math. - get(row, col) - I like it - toArray() - what about getMatrix()? - 2x3, 3x4, etc - I would make those explicit in the method name rather than side effected from the array length (which I think someone was suggesting, but maybe I read it wrong) - because someone might have a nice scratch array laying around that is really long and they want to use it to grab the matrix, but they don't really want all of its values to be used. So, if they can call "double scratch[] = new double[1024]; t.getMatrix2x3(scratch);" then that would be nice. - what about getRow(row, array) and getColumn(col, array) which can be combined with vector methods to do fast custom matrix operations? - what about classification methods so they can special case "uniform scaling", "unrotated", "translation-only", etc. matrix cases? There's some food for thought, I'll let that simmer and come back to it tomorrow... ...jim On 7/16/2012 11:25 AM, Richard Bair wrote: > Hi Pavel, > > Before approving I want Jim Graham to have a look. He's been on vacation, I think he either gets back today or next week. > > Thanks! > Richard > > On Jul 16, 2012, at 4:37 AM, Pavel Safrata wrote: > >> Hi Kirill, >> it is just for convenience. The point is that if you have algorithms or other libraries that use the fourth row, you can work with the array right away. >> Regards, >> Pavel >> >> On 16.7.2012 13:28, Kirill.Prazdnikov wrote: >>> Hi Pavel, >>> >>>> public Affine(double[] matrix) >>>> // accepts arrays of length 6, 12 and 16. >>>> // In case of 16 members the last four numbers must be 0, 0, 0, 1 >>>> // throws IllegalArgument if the above conditions are not met >>> >>> What is the point of setting 4x4 matrix of the last row must be 0,0,0,1 ? >>> Should we remove 4x4 case at all ? >>> >>> Thanks >>> >>> >> >> > From james.graham at oracle.com Mon Jul 16 21:11:52 2012 From: james.graham at oracle.com (Jim Graham) Date: Mon, 16 Jul 2012 21:11:52 -0700 Subject: Color.toWeb & Color.toHexString In-Reply-To: <4FFC4124.6040207@oracle.com> References: <4FFC4124.6040207@oracle.com> Message-ID: <5004E608.6020804@oracle.com> I had similar questions to Rich, but I had one additional question: On 7/10/2012 7:50 AM, Pavel Safrata wrote: > public String toHexString() > > This method will return a string rrggbb without the leading hash. It > will ignore opacity and will round the values to the nearest color that > can be represented with such string. An example of use is displaying a > web-based color value in a color picker. Why ignore opacity? ...jim From hjohn at xs4all.nl Mon Jul 16 23:44:37 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 17 Jul 2012 08:44:37 +0200 Subject: problem with builders In-Reply-To: <1342490121.76193.YahooMailNeo@web160903.mail.bf1.yahoo.com> References: <1342490121.76193.YahooMailNeo@web160903.mail.bf1.yahoo.com> Message-ID: <500509D5.9080303@xs4all.nl> This is because the Builder classes are actually generic to make it possible to subclass them, but still make it possible to return the correct type. For example, a RectangleBuilder builds Rectangles, but it extends ShapeBuilder which builds Shapes. In order for the extended ShapeBuilder to know it should return RectangleBuilder for the intermediate steps there is a generic parameter passed by RectangleBuilder: public class RectangleBuilder> extends ShapeBuilder B here is RectangleBuilder. Now, because you are using raw types in your code (you did not specify the generic type for RectangleBuilder for example) and are calling methods that are not part of RectangleBuilder directly (fill is from ShapeBuilder) it cannot determine the correct type anymore when build is called. You can resolve it by writing the code like this: Label label = LabelBuilder.create().text("txt").build(); StackPane sp = StackPaneBuilder.create().alignment(Pos.CENTER).build(); Rectangle r = RectangleBuilder.create().fill(Color.ALICEBLUE).build(); On a side note, I've written such Builder constructs before, and there is another way Oracle could have handled this -- they could have made the final Builder implementations non-generic and then you could write the code as you did -- it would however introduce another class for each builder... public abstract class AbstractRectangleBuilder extends AbstractShapeBuilder public final class RectangleBuilder extends AbstractRectangleBuilder Now the final class, which is used by users, is not generic and can be used like you are doing without any problems at all. --John On 17/07/2012 03:55, Jose Martinez wrote: > > I am having a problem with some of the builders.... maybe I'm doing something wrong. If I instantiate a builder (e.g. LabelBuilder) then if I edit it (e.g. .text("txt") ) then the compiler complaints that the build() method is not present. Its as if the .text() method does not returns a LabelBuilder. It does not happen with all builders, I have not tested enough to pick up on a pattern. > > Here are some examples..... > > //will not compile > LabelBuilder lb = LabelBuilder.create(); > Label label = lb.text("txt").build(); > > //compiles > StackPaneBuilder spb = StackPaneBuilder.create(); > StackPane sp = spb.alignment(Pos.CENTER).build(); > > //will not compile > RectangleBuilder rb = RectangleBuilder.create(); > Rectangle r = rb.fill(Color.ALICEBLUE).build(); > > thanks > jose > From christian.schudt at gmx.de Tue Jul 17 00:30:06 2012 From: christian.schudt at gmx.de (Christian Schudt) Date: Tue, 17 Jul 2012 09:30:06 +0200 Subject: TextField#setText(null)? In-Reply-To: <50048230.4050104@bestsolution.at> References: <50048230.4050104@bestsolution.at> Message-ID: <20120717073006.203910@gmx.net> Hi, this is a known bug, existing several times in Jira already: http://javafx-jira.kenai.com/browse/RT-20845 Originally was planned for Lombard, but fortunately is fixed since yesterday in 2.2. Regards, Christian -------- Original-Nachricht -------- > Datum: Mon, 16 Jul 2012 23:05:52 +0200 > Von: Tom Schindl > An: "openjfx-dev at openjdk.java.net" > Betreff: TextField#setText(null)? > Hi, > > Is it a problem in the JavaDoc but calling TextField#setText(null) > results not directly in an error but an NPE once you try to type > something into the control: > > -----------8<----------- > TextField f = new TextField(); > f.setText(null); > primaryStage.setScene(new Scene(b)); > primaryStage.setWidth(200); > primaryStage.setHeight(200); > primaryStage.show(); > -----------8<----------- > > The line with the NPE is in TextInputControlBehavior.defaultKeyTyped > line 219 > > > undoManager.addChange(start, textInput.getText().substring(start, end), > character, true); > > textInput.getText() is null, the problem is when binding e.g. a bean > where the value is NULL initially one gets NPEs so this is a major bug. > If NULL is not allowed for f.setText() it should throw an > IllegalArgumentException immediately I think, not? > > 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 pavel.safrata at oracle.com Tue Jul 17 01:22:12 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 17 Jul 2012 10:22:12 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5004E53B.3060108@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> Message-ID: <500520B4.1000801@oracle.com> Hi Jim, On 17.7.2012 6:08, Jim Graham wrote: > Oh my! What a discussion! > > OK, here are my thoughts after having perused most of the discussion: > > - Canning setToFoo() - I agree, it encouraged too many people to > delete an existing transform simply due to thinking that was the > method they wanted and I'd rather force them to use "setToIdentity" so > it is obvious that they are destroying information. To the person who > said "our Affine objects won't contain a transform" - ummm, which > Affine objects? Yes, if you construct one it will have identity, but > as we add methods to get Affine objects from the environment, those > objects will not be identity, so this issue remains real. Ok. > > - append/prepend are problematical. I don't think 2D got it "wrong", > I think it did it one way that was actually based on prior work, but > there are a number of developers who came from a different background > that had the reverse expectation. Simply saying "X confused some > people so Y must be the right answer" misses the point that some > people were not confused by X and might be confused by Y. Also, if > that was a problem, we've already fought that battle getting people > used to 2D's system so if we reverse course now then we simply rub > everyone's face in it. Sigh. Is there some new terminology that we > could use that doesn't trigger expectations? Nobody sad "X confused some people so Y must be the right answer". Just the opposite, we agreed that this new approach will cause some confusion as well. The thing is that we cannot reuse J2D API because the method names are not available to us and this is the best thing we could come up with. My impression right now is that any names we choose might be expected to work both ways, because people are used to J2D which really seems to work illogically - you need to add your transformations in the reverse order to get their natural concatenation. Still, I'm open to any better naming if you have one. > > - We already have GraphicsContext in 2.2 that has "translate, scale, > etc." I would hope that the "appendFoo()" methods would work like > those, but I have the sneaky suspicion that I read in the discussion > that actually the prepend methods are closer to those. Consider how a > developer that was used to "I scaled then I translated" would view > append/prepend? That sounds to me like the scale happened and then > the translate was "appended to the list of operations as if one called > it after scale in some Canvas code". Also, append should probably > reflect what happens when you get the list of Transform objects from a > Node and then append some new Transform objects to the end of that > list. Prepend should match what happens when you place new Transform > objects at the head of that same Node.getTransforms() list. So we can switch append/prepend semantics to be illogical consistently with the rest of the java world. Seems that everywhere else if you "scale then translate" the system translates and then scales. It is well possible that consistency wins over being intuitive. > > - append might mean a matrix operation with the math going one way, > but it might also mean "then after you step into that coordinate > system, you do this operation from that perspective", and it might > also mean "after you move everything around and you are staring at the > transformed objects from outside (i.e. the point of view of the > universe), you then move it again like this" and all of those will > result in different math. Do you have names that are not ambiguous and don't have ten words each? ;-) > > - get(row, col) - I like it > - toArray() - what about getMatrix()? I would probably expect getMatrix to return double[[]] or some Matrix. The toArray seems more clear to me. > - 2x3, 3x4, etc - I would make those explicit in the method name > rather than side effected from the array length (which I think someone > was suggesting, but maybe I read it wrong) - because someone might > have a nice scratch array laying around that is really long and they > want to use it to grab the matrix, but they don't really want all of > its values to be used. So, if they can call "double scratch[] = new > double[1024]; t.getMatrix2x3(scratch);" then that would be nice. How about leaving Affine(double[] matrix) as proposed and add Affine(double[] array, MatrixArrayType type, int beginIndex) > - what about getRow(row, array) and getColumn(col, array) which can be > combined with vector methods to do fast custom matrix operations? Sounds good! I would again introduce both variants: double[] getRow(int row), double[] getRow(int row, double[] array) > > - what about classification methods so they can special case "uniform > scaling", "unrotated", "translation-only", etc. matrix cases? I would probably wait for some requests from users to be sure that they really want it and to get some list of transform "classes" they want to recognize. Right now I'm afraid of introducing a complex logic for maintaining this classification that will miss its point. Thanks, Pavel > > There's some food for thought, I'll let that simmer and come back to > it tomorrow... > > ...jim > > On 7/16/2012 11:25 AM, Richard Bair wrote: >> Hi Pavel, >> >> Before approving I want Jim Graham to have a look. He's been on >> vacation, I think he either gets back today or next week. >> >> Thanks! >> Richard >> >> On Jul 16, 2012, at 4:37 AM, Pavel Safrata wrote: >> >>> Hi Kirill, >>> it is just for convenience. The point is that if you have algorithms >>> or other libraries that use the fourth row, you can work with the >>> array right away. >>> Regards, >>> Pavel >>> >>> On 16.7.2012 13:28, Kirill.Prazdnikov wrote: >>>> Hi Pavel, >>>> >>>>> public Affine(double[] matrix) >>>>> // accepts arrays of length 6, 12 and 16. >>>>> // In case of 16 members the last four numbers must be 0, >>>>> 0, 0, 1 >>>>> // throws IllegalArgument if the above conditions are not met >>>> >>>> What is the point of setting 4x4 matrix of the last row must be >>>> 0,0,0,1 ? >>>> Should we remove 4x4 case at all ? >>>> >>>> Thanks >>>> >>>> >>> >>> >> From pavel.safrata at oracle.com Tue Jul 17 01:56:27 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 17 Jul 2012 10:56:27 +0200 Subject: Color.toWeb & Color.toHexString In-Reply-To: <5004E608.6020804@oracle.com> References: <4FFC4124.6040207@oracle.com> <5004E608.6020804@oracle.com> Message-ID: <500528BB.6070502@oracle.com> On 17.7.2012 6:11, Jim Graham wrote: > I had similar questions to Rich, but I had one additional question: > > On 7/10/2012 7:50 AM, Pavel Safrata wrote: >> public String toHexString() >> >> This method will return a string rrggbb without the leading hash. It >> will ignore opacity and will round the values to the nearest color that >> can be represented with such string. An example of use is displaying a >> web-based color value in a color picker. > > Why ignore opacity? This one is disputable. I based it on the mentioned use-case where you edit the color in a color picker and I've never seen an application where opacity would be part of that field. Also AFAIK expressing opacity as 256-based value is not a common thing at all - for instance it wouldn't be parsed by any CSS engine, would it? But I'm not sure this justifies for ignoring the opacity, maybe we should produce the string expressing the color as close as possible. Thanks, Pavel > > ...jim From tom.schindl at bestsolution.at Tue Jul 17 02:09:23 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 17 Jul 2012 11:09:23 +0200 Subject: Color.toWeb & Color.toHexString In-Reply-To: <500528BB.6070502@oracle.com> References: <4FFC4124.6040207@oracle.com> <5004E608.6020804@oracle.com> <500528BB.6070502@oracle.com> Message-ID: <50052BC3.1030704@bestsolution.at> Am 17.07.12 10:56, schrieb Pavel Safrata: > > On 17.7.2012 6:11, Jim Graham wrote: >> I had similar questions to Rich, but I had one additional question: >> >> On 7/10/2012 7:50 AM, Pavel Safrata wrote: >>> public String toHexString() >>> >>> This method will return a string rrggbb without the leading hash. It >>> will ignore opacity and will round the values to the nearest color that >>> can be represented with such string. An example of use is displaying a >>> web-based color value in a color picker. >> >> Why ignore opacity? > > This one is disputable. I based it on the mentioned use-case where you > edit the color in a color picker and I've never seen an application > where opacity would be part of that field. Also AFAIK expressing opacity > as 256-based value is not a common thing at all - for instance it > wouldn't be parsed by any CSS engine, would it? But I'm not sure this > justifies for ignoring the opacity, maybe we should produce the string > expressing the color as close as possible. I would vote for getting the opacity always or if you want a method that allows to suppress it pass a boolean flag to suppress it. 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 pavel.safrata at oracle.com Tue Jul 17 02:24:59 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 17 Jul 2012 11:24:59 +0200 Subject: Color.toWeb & Color.toHexString In-Reply-To: <50052BC3.1030704@bestsolution.at> References: <4FFC4124.6040207@oracle.com> <5004E608.6020804@oracle.com> <500528BB.6070502@oracle.com> <50052BC3.1030704@bestsolution.at> Message-ID: <50052F6B.8090002@oracle.com> On 17.7.2012 11:09, Tom Schindl wrote: > Am 17.07.12 10:56, schrieb Pavel Safrata: >> On 17.7.2012 6:11, Jim Graham wrote: >>> I had similar questions to Rich, but I had one additional question: >>> >>> On 7/10/2012 7:50 AM, Pavel Safrata wrote: >>>> public String toHexString() >>>> >>>> This method will return a string rrggbb without the leading hash. It >>>> will ignore opacity and will round the values to the nearest color that >>>> can be represented with such string. An example of use is displaying a >>>> web-based color value in a color picker. >>> Why ignore opacity? >> This one is disputable. I based it on the mentioned use-case where you >> edit the color in a color picker and I've never seen an application >> where opacity would be part of that field. Also AFAIK expressing opacity >> as 256-based value is not a common thing at all - for instance it >> wouldn't be parsed by any CSS engine, would it? But I'm not sure this >> justifies for ignoring the opacity, maybe we should produce the string >> expressing the color as close as possible. > I would vote for getting the opacity always or if you want a method that > allows to suppress it pass a boolean flag to suppress it. You are probably right, guys. After all one can always call substring when the color picker is shown.. Thanks, Pavel > > Tom > > From eva.krejcirova at oracle.com Tue Jul 17 02:29:33 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Tue, 17 Jul 2012 11:29:33 +0200 Subject: problem with builders In-Reply-To: <500509D5.9080303@xs4all.nl> References: <1342490121.76193.YahooMailNeo@web160903.mail.bf1.yahoo.com> <500509D5.9080303@xs4all.nl> Message-ID: <5005307D.2050800@oracle.com> Hi Jose, There is another solution for your problem - if you write your code like this, it should compile: LabelBuilder lb = LabelBuilder.create(); Label label = lb.text("txt").build(); Regards, Eva On 7/17/2012 8:44 AM, John Hendrikx wrote: > This is because the Builder classes are actually generic to make it > possible to subclass them, but still make it possible to return the > correct type. For example, a RectangleBuilder builds Rectangles, but > it extends ShapeBuilder which builds Shapes. In order for the > extended ShapeBuilder to know it should return RectangleBuilder for > the intermediate steps there is a generic parameter passed by > RectangleBuilder: > > public class RectangleBuilder> extends > ShapeBuilder > > B here is RectangleBuilder. > > Now, because you are using raw types in your code (you did not specify > the generic type for RectangleBuilder for example) and are calling > methods that are not part of RectangleBuilder directly (fill is from > ShapeBuilder) it cannot determine the correct type anymore when build > is called. You can resolve it by writing the code like this: > > Label label = LabelBuilder.create().text("txt").build(); > StackPane sp = > StackPaneBuilder.create().alignment(Pos.CENTER).build(); > Rectangle r = > RectangleBuilder.create().fill(Color.ALICEBLUE).build(); > > On a side note, I've written such Builder constructs before, and there > is another way Oracle could have handled this -- they could have made > the final Builder implementations non-generic and then you could write > the code as you did -- it would however introduce another class for > each builder... > > public abstract class AbstractRectangleBuilder extends > AbstractShapeBuilder > > public final class RectangleBuilder extends > AbstractRectangleBuilder > > Now the final class, which is used by users, is not generic and can be > used like you are doing without any problems at all. > > --John > > On 17/07/2012 03:55, Jose Martinez wrote: >> >> I am having a problem with some of the builders.... maybe I'm doing >> something wrong. If I instantiate a builder (e.g. LabelBuilder) then >> if I edit it (e.g. .text("txt") ) then the compiler complaints that >> the build() method is not present. Its as if the .text() method does >> not returns a LabelBuilder. It does not happen with all builders, I >> have not tested enough to pick up on a pattern. >> >> Here are some examples..... >> >> //will not compile >> LabelBuilder lb = LabelBuilder.create(); >> Label label = lb.text("txt").build(); >> //compiles >> StackPaneBuilder spb = StackPaneBuilder.create(); >> StackPane sp = spb.alignment(Pos.CENTER).build(); >> //will not compile >> RectangleBuilder rb = RectangleBuilder.create(); >> Rectangle r = rb.fill(Color.ALICEBLUE).build(); >> >> thanks jose >> > From martin.desruisseaux at geomatys.fr Tue Jul 17 02:28:57 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 17 Jul 2012 11:28:57 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5004E53B.3060108@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> Message-ID: <50053059.8020702@geomatys.fr> Hello Jim Just a my 2 cents: Le 17/07/12 06:08, Jim Graham a ?crit : > - We already have GraphicsContext in 2.2 that has "translate, scale, > etc." I would hope that the "appendFoo()" methods would work like > those, but I have the sneaky suspicion that I read in the discussion > that actually the prepend methods are closer to those. Consider how a > developer that was used to "I scaled then I translated" would view > append/prepend? That sounds to me like the scale happened and then > the translate was "appended to the list of operations as if one called > it after scale in some Canvas code". Also, append should probably > reflect what happens when you get the list of Transform objects from a > Node and then append some new Transform objects to the end of that > list. Prepend should match what happens when you place new Transform > objects at the head of that same Node.getTransforms() list. I think that this operation order matches the proposal. In the proposal, "append" and "prepend" are from an operation order point of views rather than matrix multiplication order point of view. The Java2D methods have the behaviour of "prepend" in the proposal. In Java2D, AffineTransform.scale(...) followed by AffineTransform.translate(...) mean "first translate, then scale" from an operation order point of view. Nevertheless, I would have been comfortable with keeping the "translate" and "scale" method names with Java2D behaviour, if those names weren't already used by the static methods in the parent class... The "append" and "prepend" prefixes were one workaround we found; an earlier proposal was using longer method names... > - append might mean a matrix operation with the math going one way, > but it might also mean "then after you step into that coordinate > system, you do this operation from that perspective", and it might > also mean "after you move everything around and you are staring at the > transformed objects from outside (i.e. the point of view of the > universe), you then move it again like this" and all of those will > result in different math. I think that the above "coordinate system" perspective matches the current proposal. > - 2x3, 3x4, etc - I would make those explicit in the method name > rather than side effected from the array length The current proposal uses an enum. Would many methods be preferable to an enum in this case? > - what about getRow(row, array) and getColumn(col, array) which can be > combined with vector methods to do fast custom matrix operations? At this point, given the increasing amount of methods and the enum, I wonder if we should replace all those variants by a single method: double[] getSubMatrix(int firstRow, int firstColumn, int numRows, int numColumns, double[] array); This single method would provide the functionalities of getRow, getColumn, getMatrix with enum 2x3, 3x4 and 4x4 (we lost 3x3, but it it probably not a big deal). The enum would not be needed anymore. > - what about classification methods so they can special case "uniform > scaling", "unrotated", "translation-only", etc. matrix cases? Do you mean something similar to AffineTransform.getType() in Java2D? On my side, I didn't found lot of situations were I used this method. However in the JavaFX world, maybe an alternative could be some method returning the most specific subclass of Transform that can represent the Affine. For example if the Affine have only translation terms, then that method would return an instance of Translate. An "instanceof" check would allow the user to get the classification. Martin From elisa.deaibess at gmail.com Tue Jul 17 03:03:03 2012 From: elisa.deaibess at gmail.com (Elisa Deaibess) Date: Tue, 17 Jul 2012 13:03:03 +0300 Subject: Writing Custom UI Controls In-Reply-To: <1ED57E21-A59B-4561-BB96-D39B1B810C76@oracle.com> References: <051C90E3-A96A-4D52-849E-F2828C018F7D@gmx.de> <1ED57E21-A59B-4561-BB96-D39B1B810C76@oracle.com> Message-ID: Thank you all for your valuable and helpful information Regards, Elisa On Mon, Jul 16, 2012 at 8:15 PM, Richard Bair wrote: > Ya. And to provide a little background, originally in 1.0 we talked about > making Behavior a public API along with Skin and Control. It was always the > idea. However as we got close we realized that Behavior just wasn't (a) > strictly necessary and (b) vetted enough to be public. In particular, I > always wanted the same kind of functionality in UI controls that we had > with Actions and ActionMaps in Swing components. But we didn't have time to > do a proper Action / Command pattern investigation and implementation, and > so I didn't think Behavior was ready to be public API, since it would > necessarily have some overlap there. And strictly speaking until we expose > the action map concept, there is no need for Behavior to be public (and > maybe, depending on how we do it, you won't need to have Behavior public > anyway). So instead it became an aid in our implementation to help separate > the UI design from the interaction logic. In some cases this was very clean > and helpful (since in theory unit testing a Behavior should be much, much > easier than testing a Skin) and also has the benefit that in some cases it > makes it easier to write new skins and reuse existing behaviors. In some > controls like TextInputControl, this breaks down quickly and requires some > extra complication because the UI design and interaction design are so > closely linked (as opposed to something like, say, a Button). > > Long story short, it just isn't ready for prime time, but it is on the > plan for 3.0 to get this sort of infrastructure (as far as we are able in > the time) public. > > Richard > > On Jul 16, 2012, at 9:09 AM, Christian Schudt wrote: > > > Hi, > > > > I wondered about that topic, too. > > > > I do it that way, that I only use Control and Skin (public API) > > I put all the behavior in the class which implements Skin. > > > > Sometimes, I also derive from layout containers or other controls. > > I think this depends on what you want to achieve and what base > implementation helps you most. > > If you want to layout stuff, use layout containers. If you want to > extend some functionality (e.g. I added maxLength to the TextField), derive > from an existing control. > > Otherwise derive from Control. > > > > Just the use of the BehaviorBase is questionable. > > > > Regards > > Christian > > > > > > > > Am 16.07.2012 um 14:33 schrieb Elisa Deaibess: > > > >> Hi, > >> > >> We are writing a new application using JavaFX 2.x. Our application needs > >> some custom controls such as a searchfield, listoptions, ribbon, > >> breadcrumbs, etc... > >> > >> We decided to write common reusable controls; To do that we have 2 ways: > >> > >> 1. Make our controls extends Control and create new skin > >> 2. Extend some layout container or other control > >> > >> > >> Which one do you recommend? > >> Is it safe that our custom controls extends Control and to use the > >> skin/behavior? Or com.sun.javafx.scene.control.skin.SkinBase is a > private > >> class and risk to be removed in the next releases > >> > >> In JavaFXPro book I read the following: > >> > >> *Caution *In the discussion that follows, we mention Java classes in > >> packages whose names begin with com.sun. > >> These classes are implementation details of the JavaFX runtime system > and > >> are not meant to be used in normal JavaFX applications. > >> And they may change in future releases of JavaFX. > >> > >> Could you please advise? > >> > >> Regards, > >> Elisa > > > > From pavel.safrata at oracle.com Tue Jul 17 03:22:55 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 17 Jul 2012 12:22:55 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <50053059.8020702@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> Message-ID: <50053CFF.1060006@oracle.com> > >> - what about getRow(row, array) and getColumn(col, array) which can >> be combined with vector methods to do fast custom matrix operations? > At this point, given the increasing amount of methods and the enum, I > wonder if we should replace all those variants by a single method: > > double[] getSubMatrix(int firstRow, int firstColumn, int numRows, int > numColumns, double[] array); > > This single method would provide the functionalities of getRow, > getColumn, getMatrix with enum 2x3, 3x4 and 4x4 (we lost 3x3, but it > it probably not a big deal). The enum would not be needed anymore. > Besides the fact that I don't really like replacing a set of straightforward methods by a single monster, this doesn't really work for all the cases. The 2x3 matrix for instance contains xx xy tx yx yy ty which is, from the full 4x4 matrix, the first, second, and fourth column. Regards, Pavel From martin.desruisseaux at geomatys.fr Tue Jul 17 03:40:35 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 17 Jul 2012 12:40:35 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <50053CFF.1060006@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <50053CFF.1060006@oracle.com> Message-ID: <50054123.6060602@geomatys.fr> Le 17/07/12 12:22, Pavel Safrata a ?crit : >> At this point, given the increasing amount of methods and the enum, I >> wonder if we should replace all those variants by a single method: >> >> double[] getSubMatrix(int firstRow, int firstColumn, int numRows, int >> numColumns, double[] array); >> > Besides the fact that I don't really like replacing a set of > straightforward methods by a single monster, this doesn't really work > for all the cases. The 2x3 matrix for instance contains > > xx xy tx > yx yy ty > > which is, from the full 4x4 matrix, the first, second, and fourth column. Right, I forgot that case. Martin From pedro.duquevieira at gmail.com Tue Jul 17 04:48:58 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 17 Jul 2012 12:48:58 +0100 Subject: Javafx 2.2 documentation Message-ID: Hi, I have seen sometimes reference to documentation on javafx 2.2, like for example, documentation on creating custom controls in fxml. Can someone tell me where is this documentation? Thanks in advance, best regards, -- Pedro Duque Vieira From jmartine_1026 at yahoo.com Tue Jul 17 04:51:31 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Tue, 17 Jul 2012 04:51:31 -0700 (PDT) Subject: problem with builders In-Reply-To: <5005307D.2050800@oracle.com> References: <1342490121.76193.YahooMailNeo@web160903.mail.bf1.yahoo.com> <500509D5.9080303@xs4all.nl> <5005307D.2050800@oracle.com> Message-ID: <1342525891.59250.YahooMailNeo@web160903.mail.bf1.yahoo.com> John, Eva, Thank you for the detailed information. ?Adding the worked. The reason for editting the builder after instantiation is because only common or shared attributes get set initially, further down some edits must be made, specifically text. ? thanks jose ________________________________ From: Eva Krejcirova To: openjfx-dev at openjdk.java.net Cc: jmartine_1026 at yahoo.com Sent: Tuesday, July 17, 2012 5:29 AM Subject: Re: problem with builders Hi Jose, There is another solution for your problem - if you write your code like this, it should compile: LabelBuilder lb = LabelBuilder.create(); Label label = lb.text("txt").build(); Regards, Eva On 7/17/2012 8:44 AM, John Hendrikx wrote: > This is because the Builder classes are actually generic to make it possible to subclass them, but still make it possible to return the correct type.? For example, a RectangleBuilder builds Rectangles, but it extends ShapeBuilder which builds Shapes.? In order for the extended ShapeBuilder to know it should return RectangleBuilder for the intermediate steps there is a generic parameter passed by RectangleBuilder: > > public class RectangleBuilder> extends ShapeBuilder > > B here is RectangleBuilder. > > Now, because you are using raw types in your code (you did not specify the generic type for RectangleBuilder for example) and are calling methods that are not part of RectangleBuilder directly (fill is from ShapeBuilder) it cannot determine the correct type anymore when build is called.? You can resolve it by writing the code like this: > >? ? ? ? ? Label label = LabelBuilder.create().text("txt").build(); >? ? ? ? ? StackPane sp = StackPaneBuilder.create().alignment(Pos.CENTER).build(); >? ? ? ? ? Rectangle r = RectangleBuilder.create().fill(Color.ALICEBLUE).build(); > > On a side note, I've written such Builder constructs before, and there is another way Oracle could have handled this -- they could have made the final Builder implementations non-generic and then you could write the code as you did -- it would however introduce another class for each builder... > > public abstract class AbstractRectangleBuilder extends AbstractShapeBuilder > > public final class RectangleBuilder extends AbstractRectangleBuilder > > Now the final class, which is used by users, is not generic and can be used like you are doing without any problems at all. > > --John > > On 17/07/2012 03:55, Jose Martinez wrote: >> >> I am having a problem with some of the builders.... maybe I'm doing something wrong.? If I instantiate a builder (e.g. LabelBuilder) then if I edit it (e.g. .text("txt") ) then the compiler complaints that the build() method is not present.? Its as if the .text() method does not returns a LabelBuilder.? It does not happen with all builders, I have not tested enough to pick up on a pattern. >> >> Here are some examples..... >> >> //will not compile >>? ? ? ? ? LabelBuilder lb = LabelBuilder.create(); >>? ? ? ? ? Label label = lb.text("txt").build(); >>? ? ? ? ? //compiles >>? ? ? ? ? StackPaneBuilder spb = StackPaneBuilder.create(); >>? ? ? ? ? StackPane sp = spb.alignment(Pos.CENTER).build(); >>? ? ? ? ? //will not compile >>? ? ? ? ? RectangleBuilder rb = RectangleBuilder.create(); >>? ? ? ? ? Rectangle r = rb.fill(Color.ALICEBLUE).build(); >> >> thanks jose >> > From irina.fedortsova at oracle.com Tue Jul 17 05:04:47 2012 From: irina.fedortsova at oracle.com (irina.fedortsova at oracle.com) Date: Tue, 17 Jul 2012 16:04:47 +0400 Subject: Javafx 2.2 documentation In-Reply-To: References: Message-ID: <500554DF.4050302@oracle.com> Hi Pedro, The documentation you are asking is in the works and will go live with JavaFX 2.2 release. Thanks, Irina Fedortsova, JavaFX Technical writer On 7/17/2012 3:48 PM, Pedro Duque Vieira wrote: > Hi, > > I have seen sometimes reference to documentation on javafx 2.2, like for > example, documentation on creating custom controls in fxml. > Can someone tell me where is this documentation? > > Thanks in advance, best regards, From pavel.safrata at oracle.com Tue Jul 17 07:50:19 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 17 Jul 2012 16:50:19 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <50054123.6060602@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <50053CFF.1060006@oracle.com> <50054123.6060602@geomatys.fr> Message-ID: <50057BAB.7070308@oracle.com> I've just realized that the 3x3 matrix is wrong (or at least more confusing than useful). It would be good for representing a 3D transform without translation (which we don't really need to do), but not for the intended representation of 2D transform with translation. So I'm taking back the addition of MAT_3x3. Pavel On 17.7.2012 12:40, Martin Desruisseaux wrote: > Le 17/07/12 12:22, Pavel Safrata a ?crit : >>> At this point, given the increasing amount of methods and the enum, >>> I wonder if we should replace all those variants by a single method: >>> >>> double[] getSubMatrix(int firstRow, int firstColumn, int numRows, >>> int numColumns, double[] array); >>> >> Besides the fact that I don't really like replacing a set of >> straightforward methods by a single monster, this doesn't really work >> for all the cases. The 2x3 matrix for instance contains >> >> xx xy tx >> yx yy ty >> >> which is, from the full 4x4 matrix, the first, second, and fourth >> column. > > Right, I forgot that case. > > Martin > From martin.desruisseaux at geomatys.fr Tue Jul 17 08:03:10 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 17 Jul 2012 17:03:10 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <50057BAB.7070308@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <50053CFF.1060006@oracle.com> <50054123.6060602@geomatys.fr> <50057BAB.7070308@oracle.com> Message-ID: <50057EAE.6020501@geomatys.fr> Le 17/07/12 16:50, Pavel Safrata a ?crit : > I've just realized that the 3x3 matrix is wrong (or at least more > confusing than useful). It would be good for representing a 3D > transform without translation (which we don't really need to do), but > not for the intended representation of 2D transform with translation. > So I'm taking back the addition of MAT_3x3. I though that MAT_3x3 was just a convenience for MAT_2x3 with a [0 0 1] row added, like MAT_4x4 is a convenience for MAT_3x4 with [0 0 0 1] added? Thinking more about it, maybe the original MAT_2D, MAT_3D, etc. names were less confusing after all, since MAT_3x3 may suggests "extract from the 4x4 matrix a sub-matrix of side 3x3", which is not quite my initial understanding. What about: AFFINE_2D (6 values), MATRIX_2D (9 values), AFFINE_3D (12 values), MATRIX_3D (16 values)? Martin From jeff at reportmill.com Tue Jul 17 08:33:02 2012 From: jeff at reportmill.com (Jeff Martin) Date: Tue, 17 Jul 2012 10:33:02 -0500 Subject: Java Inventor: JavaFX for Mortals In-Reply-To: <4FFDAD1C.2010501@oracle.com> References: <4FFDAD1C.2010501@oracle.com> Message-ID: <346B1216-DDF9-40DF-9D42-6DE2AD5F72F0@reportmill.com> It seems this forum has been open to technology previews before, like the very cool JFX Flow and Dex. So in that vein, I hope it's okay to point this group to another. Java Inventor is a free IDE for education to make Java and JavaFX available to a broader audience. I'm thrilled with JavaFX - it's a sophisticated framework for sophisticated developers. Javi (for short) is an app builder and framework that lets anyone build and deploy rich internet database apps in minutes without having to spend years learning dozens of software, server and internet technologies. It's a true all in one: project manager, graphics designer, UI builder, database builder, code editor, media editor, report builder, ORM, app server, DB server, group source code server and more. Please check out the example gallery. The first four items show video creating a JavaFX UI on a data table for contact entry/update/search with report generation and internet deployment to Google App Engine - All in 10 minutes or less! I hope Javi can help JavaFX reach millions of people beyond sophisticated developers: students, hobbyists, business managers, graphics designers and more. Let me know (on or offline) if you have any feedback. Jeff Martin 214.513.1636 From jeff at reportmill.com Tue Jul 17 08:43:54 2012 From: jeff at reportmill.com (Jeff Martin) Date: Tue, 17 Jul 2012 10:43:54 -0500 Subject: Java Inventor: JavaFX for Mortals In-Reply-To: <346B1216-DDF9-40DF-9D42-6DE2AD5F72F0@reportmill.com> References: <4FFDAD1C.2010501@oracle.com> <346B1216-DDF9-40DF-9D42-6DE2AD5F72F0@reportmill.com> Message-ID: <185E8C47-4A3C-40CF-9F3A-4670A86F2E19@reportmill.com> Links were stripped out: Java Inventor Gallery: http://www.reportmill.com/javi/gallery and JFX Flow: http://www.zenjava.com/jfx-flow Dex: http://www.javainc.com/projects/dex/Dex.html On Jul 17, 2012, at 10:33 AM, Jeff Martin wrote: > It seems this forum has been open to technology previews before, like the very cool JFX Flow and Dex. So in that vein, I hope it's okay to point this group to another. > > Java Inventor is a free IDE for education to make Java and JavaFX available to a broader audience. I'm thrilled with JavaFX - it's a sophisticated framework for sophisticated developers. Javi (for short) is an app builder and framework that lets anyone build and deploy rich internet database apps in minutes without having to spend years learning dozens of software, server and internet technologies. It's a true all in one: project manager, graphics designer, UI builder, database builder, code editor, media editor, report builder, ORM, app server, DB server, group source code server and more. > > Please check out the example gallery. The first four items show video creating a JavaFX UI on a data table for contact entry/update/search with report generation and internet deployment to Google App Engine - All in 10 minutes or less! I hope Javi can help JavaFX reach millions of people beyond sophisticated developers: students, hobbyists, business managers, graphics designers and more. Let me know (on or offline) if you have any feedback. > > Jeff Martin > 214.513.1636 From pavel.safrata at oracle.com Tue Jul 17 08:56:58 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 17 Jul 2012 17:56:58 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <50057EAE.6020501@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <50053CFF.1060006@oracle.com> <50054123.6060602@geomatys.fr> <50057BAB.7070308@oracle.com> <50057EAE.6020501@geomatys.fr> Message-ID: <50058B4A.2040403@oracle.com> On 17.7.2012 17:03, Martin Desruisseaux wrote: > Le 17/07/12 16:50, Pavel Safrata a ?crit : >> I've just realized that the 3x3 matrix is wrong (or at least more >> confusing than useful). It would be good for representing a 3D >> transform without translation (which we don't really need to do), but >> not for the intended representation of 2D transform with translation. >> So I'm taking back the addition of MAT_3x3. > > I though that MAT_3x3 was just a convenience for MAT_2x3 with a [0 0 > 1] row added, like MAT_4x4 is a convenience for MAT_3x4 with [0 0 0 1] > added? > > Thinking more about it, maybe the original MAT_2D, MAT_3D, etc. names > were less confusing after all, since MAT_3x3 may suggests "extract > from the 4x4 matrix a sub-matrix of side 3x3", which is not quite my > initial understanding. Exactly, it seems to me that it would be tempting to interpret the 1 in the bottom right corner as a z-axis translation.. > > What about: AFFINE_2D (6 values), MATRIX_2D (9 values), AFFINE_3D (12 > values), MATRIX_3D (16 values)? I think this looks better. The downside that it is probably unusable without reading documentation ("what is the difference between matrix and affine?") What about MAT_2D_3x2, MAT_2D_3x3, MAT_3D_3x4, MAT_3D_4x4? Looks ugly, doesn't it? :-( Pavel > > Martin > From hang.vo at oracle.com Tue Jul 17 09:33:57 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 17 Jul 2012 16:33:57 +0000 Subject: hg: openjfx/2.2/graphics/rt: Follow-on fix for RT-23395 to preserve the original set value (the first version of the fix did this) Message-ID: <20120717163401.D99F2470D6@hg.openjdk.java.net> Changeset: 43999fd698ad Author: kcr Date: 2012-07-17 09:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/43999fd698ad Follow-on fix for RT-23395 to preserve the original set value (the first version of the fix did this) ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java From pedro.duquevieira at gmail.com Tue Jul 17 09:41:02 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 17 Jul 2012 17:41:02 +0100 Subject: Javafx 2.2 documentation Message-ID: Hi Irina, I was asking for documentation available right now. And people in this mailing list have referenced this documentation as if it exists right now. Do you have to be a javafx partner to be able to view this documentation? I am a javafx partner... Cheers, > Hi Pedro, > The documentation you are asking is in the works and will go live with > JavaFX 2.2 release. > Thanks, > Irina Fedortsova, > JavaFX Technical writer > On 7/17/2012 3:48 PM, Pedro Duque Vieira wrote: > > Hi, > > > > I have seen sometimes reference to documentation on javafx 2.2, like for > > example, documentation on creating custom controls in fxml. > > Can someone tell me where is this documentation? > > > > Thanks in advance, best regards, -- Pedro Duque Vieira From david.dehaven at oracle.com Tue Jul 17 10:20:00 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 17 Jul 2012 10:20:00 -0700 Subject: Embed VLC video output into a Scene Graph In-Reply-To: References: Message-ID: > I'm trying to embed a VLC player in a JavaFX 2.2 application. > For that I'm using the libvlc.dll library's API. > > VLC provided two ways to render a video: > 1. Call API function that takes HWND: libvlc_media_player_set_hwnd (libvlc_media_player_t *p_mi, void *drawable) Set a Win32/Win64 API window handle (HWND) where the media player should render its video output. > 2. Register a callback that gets called every time a frame should be rendered: libvlc_video_display_cb (void *opaque, void *picture) Callback prototype to display a picture. > > With the HWND approach, I managed to extract an HWND pointer of the Scene using Glass framework, causing the video to render on the whole scene, no other nodes are visible. > With the Callback approach, and by using JavaFX 2.2 new javafx.scene.canvas.Canvas node, I was able to throw pixels at the canvas, but it turns to be very inefficient in terms of memory and thread usage. > > I would love to have a solution as with AWT + JNA: the HWND can be extracted from java.awt.Canvas component (using JNA), and be given to libvlc API function. This canvas can be placed anywhere in the frame, not occupying all the entire window. > > Hard Guidelines: > 1. Integrating AWT/Swing with FX application is not an option, I want it to be a pure JavaFX application. > 2. Using JavaFX Media API for playback is not an option, since I have a requirement to modify the media player's source code. > 3. The video must not occupy the entire window, allowing other components to be visible. > > Possible solution is to create my own node or control that will wrap Glass component View that has a HWND but I don't know how to bind and make it work with other Glass components. If you start digging into private API's you're dooming your app to crash and burn at the next update, especially true for 3.0 where a lot of under the hood changes are expected to be made. The canvas approach is interesting, but wasteful as it allocates far more resources than necessary. If you get a raster from VLC, then just create an image from the raster. That's what Jasper did for JavaOne last year with the video preview portion of his Microsoft Kinect demo, just create a new image for each frame (sounds wasteful, I know, but not really much different than how MediaView works internally). When you create an image, it gets uploaded to a D3D/GL texture if you're using hardware rendering so the actual rendering doesn't suffer any performance drawbacks. I think you may need to look at WritableImage for this as I'm not sure if the method used for JavaOne is public or even exists any more? WritableImage allows you to change the image contents on the fly, so it should provide what you need without all the overhead of a Canvas node. What I'm more interested in is why you need to use VLC? What's missing in the media stack that you need? File feature requests in JIRA and we can investigate including them in future releases... -DrD- From hang.vo at oracle.com Tue Jul 17 10:19:43 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 17 Jul 2012 17:19:43 +0000 Subject: hg: openjfx/2.2/graphics/rt: 31 new changesets Message-ID: <20120717172009.2F693470D8@hg.openjdk.java.net> Changeset: f28a395961d2 Author: hudson Date: 2012-07-11 12:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f28a395961d2 Added tag 2.2-b17 for changeset 1d8c6251f243 ! .hgtags Changeset: 9b69d1047d82 Author: Kinsley Wong Date: 2012-07-10 13:52 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9b69d1047d82 RT-23281: GridPaneDesignInfo.getCellBounds() breaks after adding a new RowConstraints to a GridPane. ! javafx-designtime/src/javafx/scene/layout/GridPaneDesignInfo.java Changeset: b26dbc994eec Author: Kinsley Wong Date: 2012-07-10 13:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b26dbc994eec RT-23288: [Accordion] SHIFT-TAB should move focus to previous control. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: 153fdd6ebb3d Author: Kinsley Wong Date: 2012-07-10 13:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/153fdd6ebb3d RT-23198: TabPane menu is shown when not necessary. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: a0ca6475993a Author: Kinsley Wong Date: 2012-07-10 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a0ca6475993a RT-23225: Pagination incorrect behavior when page count is less than 0. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 302ba4698b33 Author: David Grieve Date: 2012-07-10 20:19 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/302ba4698b33 RT-23207: if node has inline styles, use slowpath ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: cefe52608b67 Author: David Grieve Date: 2012-07-10 20:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/cefe52608b67 RT-20643: add Scene to CssError and Node to CssError.PropertySetError ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-controls/src/javafx/scene/control/Control.java Changeset: 30b375f0ad85 Author: David Grieve Date: 2012-07-11 08:03 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/30b375f0ad85 RT-20643: add Scene to CssError and Node to CssError.PropertySetError - fix bug found by SceneBuilder testing ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 1953b610d096 Author: mickf Date: 2012-07-11 16:46 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1953b610d096 [TEST-ONLY] RT-23320 - Traversal : write unit test to check for nested focus-traversal cycles inside a TabPane. ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 2e6dd4d24206 Author: David Grieve Date: 2012-07-12 00:28 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2e6dd4d24206 RT-23079: CacheEntry in StyleHelper should weakly reference the shared cache from StylesheetContainer styleCache ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: a844e4fd4abf Author: David Grieve Date: 2012-07-12 16:20 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a844e4fd4abf RT-23256: ScrollPane with large content using mouse wheel is useless ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: eca72eaec20d Author: David Grieve Date: 2012-07-12 16:27 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/eca72eaec20d RT-22941 [ScrollBar, touch] knob is moving in wrong direction, when finger swipe is used. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 32a2ac15cc0e Author: Kinsley Wong Date: 2012-07-12 15:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/32a2ac15cc0e [DOC ONLY] RT-20847: some css properties are not covered in cssref. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: dcc106432347 Author: Paru Somashekar Date: 2012-07-12 15:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/dcc106432347 fix RT-23057 PieChart draws garbage when at min size ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 74b5a4b24935 Author: Paru Somashekar Date: 2012-07-12 15:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/74b5a4b24935 fix RT-21295 Setting chart data to null disables chart animation ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 6c543a637228 Author: Paru Somashekar Date: 2012-07-12 15:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6c543a637228 fix RT-21164 BarChart: Adding several bars in a row produces upside down bars. ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java Changeset: 231378f0f928 Author: Paru Somashekar Date: 2012-07-12 15:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/231378f0f928 fix RT-19903 Call ObservableList#clear() for LineChart result on IndexOutOfBoundsException. ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java Changeset: 374f5352788f Author: Paru Somashekar Date: 2012-07-12 16:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/374f5352788f fix RT-18985 Slider labels disappear too eagerly ! javafx-ui-controls/src/javafx/scene/chart/Axis.java Changeset: aa283b2f20ad Author: Kinsley Wong Date: 2012-07-12 16:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/aa283b2f20ad Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: d12adf6ea5d5 Author: David Grieve Date: 2012-07-13 13:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d12adf6ea5d5 RT-21894: unit test ! javafx-ui-controls/test/javafx/scene/control/MenuButtonTest.java Changeset: 8b3da2148b1b Author: David Grieve Date: 2012-07-13 13:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8b3da2148b1b RT-21894: LabeledImpl needs to track the origin of the Labeled properites it does not mirror. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: d3c8bd0df966 Author: Kinsley Wong Date: 2012-07-13 14:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d3c8bd0df966 [DOC ONLY] added some comments to EmbeddedTextContextMenuContent. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/EmbeddedTextContextMenuContent.java Changeset: b9a7024c3450 Author: jgiles Date: 2012-07-10 08:32 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b9a7024c3450 RT-23275: Editable combobox throws StackOverflowError when press ESC key ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 58bea6c6decc Author: jgiles Date: 2012-07-13 12:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/58bea6c6decc [DOC ONLY] RT-23308: All impl_* methods must be hidden from javadoc and marked as deprecated ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: e848c165aaa9 Author: jgiles Date: 2012-07-16 11:18 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e848c165aaa9 RT-22972: ComboBox with dynamic item list : issue with the "Empty" label ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 5ba93f3d48b7 Author: jgiles Date: 2012-07-16 11:57 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/5ba93f3d48b7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 7e06dda995b5 Author: leifs Date: 2012-07-16 18:57 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7e06dda995b5 Fixed RT-20845: TextField with bidirectional binding is not editable in applet but editable in standalone execution mode ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java Changeset: a6dd0e5c4451 Author: Paru Somashekar Date: 2012-07-16 10:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a6dd0e5c4451 fix RT-21141 XYChart changes categories order spontaneously on Remove DataItem ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 7c7bc01e9da4 Author: jgiles Date: 2012-07-17 07:16 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7c7bc01e9da4 Backed out changeset: e848c165aaa9 (RT-22972: ComboBox with dynamic item list : issue with the "Empty" label) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 264470ba524e Author: jgiles Date: 2012-07-17 07:17 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/264470ba524e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 7839d55ac4c0 Author: Yao Wang Date: 2012-07-17 10:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7839d55ac4c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java From ozemale at ozemail.com.au Tue Jul 17 10:48:57 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Wed, 18 Jul 2012 03:48:57 +1000 Subject: JavaFX on iOS, Android and Metro Message-ID: <00ac01cd6444$70d874c0$52895e40$@com.au> Hopefully this is not OT, I recall Richard Bair's post from a few weeks ago where he outlined his grand vision for JavaFX to be truly running everywhere in an ideal world and this of course must include iOS and Metro. Whilst I realise this was just "dreaming" and in no way represented Oracle's official plans, I also note that there is a JavaOne session on this topic later this year. However, I read recently that Metro apps are not permitted to use "executable memory" such as is utilised in a JIT compiler and I believe iOS may have a similar restriction. This has been complained about by the likes of LuaJIT's Mike Pall and others. Can anyone confirm this? Surely if this is true then Java itself would be significantly handicapped in these environments and would need to be fully interpreted only. Again, I am not requesting any statements about Oracle's plans in this area, just confirmation that such a restriction does exist and its effect on Java's JIT compiler. Thanks, -jct From joshua at marinacci.org Tue Jul 17 10:51:09 2012 From: joshua at marinacci.org (Josh Marinacci) Date: Tue, 17 Jul 2012 10:51:09 -0700 Subject: JavaFX on iOS, Android and Metro In-Reply-To: <00ac01cd6444$70d874c0$52895e40$@com.au> References: <00ac01cd6444$70d874c0$52895e40$@com.au> Message-ID: <21C04C762B4B4B74B0069DED87D58BF5@marinacci.org> I don't know the Java plans, but I do know that the C#/Mono community solved this problem by using ahead of time compilation. Something might be possible for Java as well. - J -- Josh Marinacci joshondesign.com On Tuesday, July 17, 2012 at 10:48 AM, John C. Turnbull wrote: > Hopefully this is not OT, I recall Richard Bair's post from a few weeks ago > where he outlined his grand vision for JavaFX to be truly running everywhere > in an ideal world and this of course must include iOS and Metro. Whilst I > realise this was just "dreaming" and in no way represented Oracle's official > plans, I also note that there is a JavaOne session on this topic later this > year. However, I read recently that Metro apps are not permitted to use > "executable memory" such as is utilised in a JIT compiler and I believe iOS > may have a similar restriction. This has been complained about by the likes > of LuaJIT's Mike Pall and others. > > > Can anyone confirm this? Surely if this is true then Java itself would be > significantly handicapped in these environments and would need to be fully > interpreted only. > > > Again, I am not requesting any statements about Oracle's plans in this area, > just confirmation that such a restriction does exist and its effect on > Java's JIT compiler. > > > Thanks, > > > -jct From richard.bair at oracle.com Tue Jul 17 10:58:37 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 17 Jul 2012 10:58:37 -0700 Subject: JavaFX on iOS, Android and Metro In-Reply-To: <00ac01cd6444$70d874c0$52895e40$@com.au> References: <00ac01cd6444$70d874c0$52895e40$@com.au> Message-ID: > Can anyone confirm this? Surely if this is true then Java itself would be > significantly handicapped in these environments and would need to be fully > interpreted only. Yes, iOS (and to my understanding Metro) do not allow executable memory segments to be created by the application. Hence, no JIT. The standard solution to this (Adobe AIR does this, for example) is to have ahead of time compilation. Richard From james.graham at oracle.com Tue Jul 17 11:20:04 2012 From: james.graham at oracle.com (Jim Graham) Date: Tue, 17 Jul 2012 11:20:04 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <50053059.8020702@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> Message-ID: <5005ACD4.7040500@oracle.com> I think we disagree as to what "translate then scale" means. To me, it is ambiguously referring to two totally different outcomes which depend on your perspective as "translate me and then scale me" or "translate that thing and then scale it". There is no "right and wrong" and any discussion that uses those words is simply burying their head in their own default interpretation and ignoring that people see things differently. Similarly with append and prepend - they do not remove the ambiguity, they simply provide a name for it. If you think the "translate" and "scale" names from 2D worked opposite from your default view (which you may not realize was just one of 2 possible views, there is no right or wrong), then append does not explicitly resolve the issue - it is just as ambiguous as your existing "my view was right and someone else got it wrong" mistaken impression. The only way that "append" can be interpreted unambiguously from the current FX context is if it works as if one appended some Transform nodes to the list in Node's "getTransforms()" List, but even that may not match another engineer's default interpretation. That is the only definition we currently have of append in the current set of APIs. If your append* methods will work differently than that interpretation then you are creating an inconsistency. (Note that ObservableList.add is consistent with List.add which defines the operation as "append" so the order implied by that term has already been spoken for.) Note that Java2D didn't invent its interpretation of what it means to "translate(), then scale()" - we are doing the same thing that PostScript did which predates any of this by a few years. We also happen to be doing the same thing that the latest transform standard for the web is doing - HTML5 Canvas/GraphicsContext... ...jim On 7/17/2012 2:28 AM, Martin Desruisseaux wrote: > Hello Jim > > Just a my 2 cents: > > Le 17/07/12 06:08, Jim Graham a ?crit : >> - We already have GraphicsContext in 2.2 that has "translate, scale, >> etc." I would hope that the "appendFoo()" methods would work like >> those, but I have the sneaky suspicion that I read in the discussion >> that actually the prepend methods are closer to those. Consider how a >> developer that was used to "I scaled then I translated" would view >> append/prepend? That sounds to me like the scale happened and then the >> translate was "appended to the list of operations as if one called it >> after scale in some Canvas code". Also, append should probably reflect >> what happens when you get the list of Transform objects from a Node >> and then append some new Transform objects to the end of that list. >> Prepend should match what happens when you place new Transform objects >> at the head of that same Node.getTransforms() list. > I think that this operation order matches the proposal. In the proposal, > "append" and "prepend" are from an operation order point of views rather > than matrix multiplication order point of view. > > The Java2D methods have the behaviour of "prepend" in the proposal. In > Java2D, AffineTransform.scale(...) followed by > AffineTransform.translate(...) mean "first translate, then scale" from > an operation order point of view. > > Nevertheless, I would have been comfortable with keeping the "translate" > and "scale" method names with Java2D behaviour, if those names weren't > already used by the static methods in the parent class... The "append" > and "prepend" prefixes were one workaround we found; an earlier proposal > was using longer method names... > > >> - append might mean a matrix operation with the math going one way, >> but it might also mean "then after you step into that coordinate >> system, you do this operation from that perspective", and it might >> also mean "after you move everything around and you are staring at the >> transformed objects from outside (i.e. the point of view of the >> universe), you then move it again like this" and all of those will >> result in different math. > I think that the above "coordinate system" perspective matches the > current proposal. > > >> - 2x3, 3x4, etc - I would make those explicit in the method name >> rather than side effected from the array length > The current proposal uses an enum. Would many methods be preferable to > an enum in this case? > > >> - what about getRow(row, array) and getColumn(col, array) which can be >> combined with vector methods to do fast custom matrix operations? > At this point, given the increasing amount of methods and the enum, I > wonder if we should replace all those variants by a single method: > > double[] getSubMatrix(int firstRow, int firstColumn, int numRows, int > numColumns, double[] array); > > This single method would provide the functionalities of getRow, > getColumn, getMatrix with enum 2x3, 3x4 and 4x4 (we lost 3x3, but it it > probably not a big deal). The enum would not be needed anymore. > > >> - what about classification methods so they can special case "uniform >> scaling", "unrotated", "translation-only", etc. matrix cases? > Do you mean something similar to AffineTransform.getType() in Java2D? On > my side, I didn't found lot of situations were I used this method. > However in the JavaFX world, maybe an alternative could be some method > returning the most specific subclass of Transform that can represent the > Affine. For example if the Affine have only translation terms, then that > method would return an instance of Translate. An "instanceof" check > would allow the user to get the classification. > > > Martin > From martin.desruisseaux at geomatys.fr Tue Jul 17 11:44:34 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 17 Jul 2012 20:44:34 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5005ACD4.7040500@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> Message-ID: <5005B292.7040603@geomatys.fr> Hello Graham My interpretation was that Java2D/Postscript/HTML5 "translate" and "scale" were designed the way they are not because there is a "right" and "wrong" views, but simply because they were the most frequently used ways. At least in the code a saw and wrote, Java2D concatenate-like operations were quite more frequent than preConcatenate-like operations. I think we would still have used the "translate" and "scale" names if they were available. But since we have to find other names, what else can we use? Martin Le 17/07/12 20:20, Jim Graham a ?crit : > I think we disagree as to what "translate then scale" means. To me, > it is ambiguously referring to two totally different outcomes which > depend on your perspective as "translate me and then scale me" or > "translate that thing and then scale it". There is no "right and > wrong" and any discussion that uses those words is simply burying > their head in their own default interpretation and ignoring that > people see things differently. > > Similarly with append and prepend - they do not remove the ambiguity, > they simply provide a name for it. If you think the "translate" and > "scale" names from 2D worked opposite from your default view (which > you may not realize was just one of 2 possible views, there is no > right or wrong), then append does not explicitly resolve the issue - > it is just as ambiguous as your existing "my view was right and > someone else got it wrong" mistaken impression. > > The only way that "append" can be interpreted unambiguously from the > current FX context is if it works as if one appended some Transform > nodes to the list in Node's "getTransforms()" List, but > even that may not match another engineer's default interpretation. > That is the only definition we currently have of append in the current > set of APIs. If your append* methods will work differently than that > interpretation then you are creating an inconsistency. (Note that > ObservableList.add is consistent with List.add which defines the > operation as "append" so the order implied by that term has already > been spoken for.) > > Note that Java2D didn't invent its interpretation of what it means to > "translate(), then scale()" - we are doing the same thing that > PostScript did which predates any of this by a few years. We also > happen to be doing the same thing that the latest transform standard > for the web is doing - HTML5 Canvas/GraphicsContext... > > ...jim From info at fxmlguide.com Tue Jul 17 11:44:32 2012 From: info at fxmlguide.com (FXML Guide) Date: Tue, 17 Jul 2012 11:44:32 -0700 Subject: Javafx 2.2 documentation In-Reply-To: References: Message-ID: <5005B290.9060404@fxmlguide.com> Hello Pedro; Greg Brown referenced Custom Components in the updated 'Introduction to FXML.' This document can be found within your JavaFX 2.2 SDK directory here: /JavaFX 2.2 SDK/docs/api/javafx/fxml/doc-files/introduction_to_fxml.html#custom_components TA Hubbard fxmlguide.com On 7/17/2012 9:41 AM, Pedro Duque Vieira wrote: > Hi Irina, > > I was asking for documentation available right now. > And people in this mailing list have referenced this documentation as if it > exists right now. > > Do you have to be a javafx partner to be able to view this documentation? I > am a javafx partner... > > Cheers, > > >> Hi Pedro, >> The documentation you are asking is in the works and will go live with >> JavaFX 2.2 release. >> Thanks, >> Irina Fedortsova, >> JavaFX Technical writer >> On 7/17/2012 3:48 PM, Pedro Duque Vieira wrote: >>> Hi, >>> >>> I have seen sometimes reference to documentation on javafx 2.2, like for >>> example, documentation on creating custom controls in fxml. >>> Can someone tell me where is this documentation? >>> >>> Thanks in advance, best regards, > From kirill.prazdnikov at oracle.com Tue Jul 17 11:49:41 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Tue, 17 Jul 2012 22:49:41 +0400 Subject: Affine transforms - matrix algebra In-Reply-To: <5005ACD4.7040500@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> Message-ID: <5005B3C5.3030307@oracle.com> On 17.07.2012 22:20, Jim Graham wrote: > Similarly with append and prepend - they do not remove the ambiguity These two are the most confusing. If we look at a matrix (A) as a function which translate a point (x) form R3 into a point (y) from R3 : A(x) = y What does append ? A.append(B): is it a A(B(x)) or B(A(x)) ? Thanks -Kirill From martin.desruisseaux at geomatys.fr Tue Jul 17 11:58:51 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 17 Jul 2012 20:58:51 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5005B3C5.3030307@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> Message-ID: <5005B5EB.7060508@geomatys.fr> What about the following proposal? If we consider the Affine as a function that transform coordinates from a source coordinate system to a target coordinate system, then: sourceTranslate(...) (equivalent to Java2D translate) targetTranslate(...) (equivalent to Java2D preConcatenate) Martin From pavel.safrata at oracle.com Tue Jul 17 12:14:14 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 17 Jul 2012 21:14:14 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5005B3C5.3030307@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> Message-ID: <5005B986.9010008@oracle.com> If we keep the append/prepend terminology and switch the semantics (for reasons explained by Jim), is that a good API? The semantic would then be defined as "append" means the same thing as adding the transform to the end of Node's transform list. Or, Jim, do you have a better naming suggestion? Thanks, Pavel On 17.7.2012 20:49, Kirill.Prazdnikov wrote: > On 17.07.2012 22:20, Jim Graham wrote: >> Similarly with append and prepend - they do not remove the ambiguity > > These two are the most confusing. > > If we look at a matrix (A) as a function which translate a point (x) > form R3 into a point (y) from R3 : > A(x) = y > > What does append ? > > A.append(B): is it a A(B(x)) or B(A(x)) ? > > Thanks > -Kirill > From martin.desruisseaux at geomatys.fr Tue Jul 17 13:03:18 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 17 Jul 2012 22:03:18 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5005B986.9010008@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> Message-ID: <5005C506.7030102@geomatys.fr> Le 17/07/12 21:14, Pavel Safrata a ?crit : > If we keep the append/prepend terminology and switch the semantics > (for reasons explained by Jim), is that a good API? The semantic would > then be defined as "append" means the same thing as adding the > transform to the end of Node's transform list. Well, just for the record, the original append/prepend terminology was an attempt to be in the spirit of Java2D javadoc, which said for Cx.concatenate(Tx): "Transforming a point p by the updated transform Cx' is equivalent to first transforming p by Tx and then transforming the result by the original transform Cx like this: Cx'(p) = Cx(Tx(p)) - note the usage of "first" and "then". The original terminology was also consistent with the definition of ConcatenatedOperation in the ISO-19111 international standard, which is defined as a sequence of coordinate operation steps. "prepend" was adding a step in the beginning of that sequence, and "append" adding a step at the end of that sequence. ISO-19111 is mostly about dealing with non-linear transform (map projections) in addition to affine transform. Since matrix notation can not be used in such case (while I admit that the Cx(Tx(p)) notation still apply), maybe it could be an explanation for the difference in interpretations. Martin From pedro.duquevieira at gmail.com Tue Jul 17 13:46:47 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 17 Jul 2012 21:46:47 +0100 Subject: Javafx 2.2 documentation Message-ID: Hi TA Hubbard, Thanks, that was exactly what I was looking for!! Best regards, > Hello Pedro; > Greg Brown referenced Custom Components in the updated 'Introduction to > FXML.' This document can be found within your JavaFX 2.2 SDK directory > here: > /JavaFX 2.2 > SDK/docs/api/javafx/fxml/doc-files/introduction_to_fxml. > html#custom_components > TA Hubbard > fxmlguide.com -- Pedro Duque Vieira From hjohn at xs4all.nl Tue Jul 17 14:49:25 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 17 Jul 2012 23:49:25 +0200 Subject: Embed VLC video output into a Scene Graph In-Reply-To: References: Message-ID: <5005DDE5.6000304@xs4all.nl> On 17/07/2012 19:20, David DeHaven wrote: > >> I'm trying to embed a VLC player in a JavaFX 2.2 application. >> For that I'm using the libvlc.dll library's API. >> >> VLC provided two ways to render a video: >> 1. Call API function that takes HWND: libvlc_media_player_set_hwnd (libvlc_media_player_t *p_mi, void *drawable) Set a Win32/Win64 API window handle (HWND) where the media player should render its video output. >> 2. Register a callback that gets called every time a frame should be rendered: libvlc_video_display_cb (void *opaque, void *picture) Callback prototype to display a picture. >> >> With the HWND approach, I managed to extract an HWND pointer of the Scene using Glass framework, causing the video to render on the whole scene, no other nodes are visible. >> With the Callback approach, and by using JavaFX 2.2 new javafx.scene.canvas.Canvas node, I was able to throw pixels at the canvas, but it turns to be very inefficient in terms of memory and thread usage. >> >> I would love to have a solution as with AWT + JNA: the HWND can be extracted from java.awt.Canvas component (using JNA), and be given to libvlc API function. This canvas can be placed anywhere in the frame, not occupying all the entire window. >> >> Hard Guidelines: >> 1. Integrating AWT/Swing with FX application is not an option, I want it to be a pure JavaFX application. >> 2. Using JavaFX Media API for playback is not an option, since I have a requirement to modify the media player's source code. >> 3. The video must not occupy the entire window, allowing other components to be visible. >> >> Possible solution is to create my own node or control that will wrap Glass component View that has a HWND but I don't know how to bind and make it work with other Glass components. > If you start digging into private API's you're dooming your app to crash and burn at the next update, especially true for 3.0 where a lot of under the hood changes are expected to be made. If there was a solution that would allow full 1080p playback of popular containers like avi and mkv that would require a little bit of hacking but break guaranteed when 3.0 is released, I'd take it. As it is, 99% of videos need to be transcoded before the standard media framework will play it. Hence the need for alternatives, VLC / Gstreamer / Xuggler / etc... > The canvas approach is interesting, but wasteful as it allocates far more resources than necessary. Yup. All we need though is direct access to a texture or heavy weight component, preferably with a HWND so embedabble players can tell their output to render directly to it. > If you get a raster from VLC, then just create an image from the raster. That's what Jasper did for JavaOne last year with the video preview portion of his Microsoft Kinect demo, just create a new image for each frame (sounds wasteful, I know, but not really much different than how MediaView works internally). When you create an image, it gets uploaded to a D3D/GL texture if you're using hardware rendering so the actual rendering doesn't suffer any performance drawbacks. This is also wasteful, so much so that you can forget smooth playback of the format that matters at this moment, full hd. Throwing around multi-megabyte textures at a rate of 25 frames per second is in my experience not really feasible without a considerable performance penalty -- that's why they stopped doing that 10 years ago and created overlays. > I think you may need to look at WritableImage for this as I'm not sure if the method used for JavaOne is public or even exists any more? WritableImage allows you to change the image contents on the fly, so it should provide what you need without all the overhead of a Canvas node. > > What I'm more interested in is why you need to use VLC? What's missing in the media stack that you need? File feature requests in JIRA and we can investigate including them in future releases... Well, for me, VLC is needed because it actually plays the videos I throw at it (avi, mkv, mpg being the three most common containers). It also plays streams, like you can get from YouTube (through a simple Google API). Conversion is not an option -- it needs to play the files users have available to them. What if Java could only decoded PNG image files? I cannot expect users to transcode all of their images so my app can read them. As far as I'm concerned the current MediaView is a neat trick to be able to say that JavaFX supports Video playback, but in reality it is only useful in a small niche where you are providing or encoding your own videos in the correct format (or if you enjoy watching Big Buck Bunny). So we're left with hacks, trying to use Canvas, or WriteableImage, embedding Swing, overlaying other Windows on top of ours, obtaining HWND's in the hope that a player can render its data in the background of a Stage with JavaFX nodes on top... or as I have done, open two Windows (awt Frame + Stage on top of it), make the Stage transparent and have full hardware accelerated video render to the Frame. I certainly wouldn't mind a better solution, there is lots of nice things I could do in my app if the Video was a Node like the rest of the visible controls... so I'm hoping that eventually the gstreamer lite stack can simply be replaced to play back all the common formats, but I'm afraid it's not going to be happening in a reasonable time frame. --John From pavel.safrata at oracle.com Tue Jul 17 23:02:22 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 18 Jul 2012 08:02:22 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5005C506.7030102@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> Message-ID: <5006516E.4030108@oracle.com> Hi guys, I have one more idea. What about going the other way around and naming the methods according to the matrix operations? That could be pretty unambiguous I think: leftProduct (equivalent to J2D preConcatenate) rightProduct (equivalent to concatenate) leftTranslate (equivalent to preTranslate) rightTranslate (equivalent to translate) etc. Pavel From hang.vo at oracle.com Wed Jul 18 15:03:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 18 Jul 2012 22:03:39 +0000 Subject: hg: openjfx/2.2/master/rt: 38 new changesets Message-ID: <20120718220413.B706947124@hg.openjdk.java.net> Changeset: 9b69d1047d82 Author: Kinsley Wong Date: 2012-07-10 13:52 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9b69d1047d82 RT-23281: GridPaneDesignInfo.getCellBounds() breaks after adding a new RowConstraints to a GridPane. ! javafx-designtime/src/javafx/scene/layout/GridPaneDesignInfo.java Changeset: b26dbc994eec Author: Kinsley Wong Date: 2012-07-10 13:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b26dbc994eec RT-23288: [Accordion] SHIFT-TAB should move focus to previous control. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: 153fdd6ebb3d Author: Kinsley Wong Date: 2012-07-10 13:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/153fdd6ebb3d RT-23198: TabPane menu is shown when not necessary. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: a0ca6475993a Author: Kinsley Wong Date: 2012-07-10 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a0ca6475993a RT-23225: Pagination incorrect behavior when page count is less than 0. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 302ba4698b33 Author: David Grieve Date: 2012-07-10 20:19 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/302ba4698b33 RT-23207: if node has inline styles, use slowpath ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: cefe52608b67 Author: David Grieve Date: 2012-07-10 20:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cefe52608b67 RT-20643: add Scene to CssError and Node to CssError.PropertySetError ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-controls/src/javafx/scene/control/Control.java Changeset: 30b375f0ad85 Author: David Grieve Date: 2012-07-11 08:03 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/30b375f0ad85 RT-20643: add Scene to CssError and Node to CssError.PropertySetError - fix bug found by SceneBuilder testing ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 1953b610d096 Author: mickf Date: 2012-07-11 16:46 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1953b610d096 [TEST-ONLY] RT-23320 - Traversal : write unit test to check for nested focus-traversal cycles inside a TabPane. ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 2e6dd4d24206 Author: David Grieve Date: 2012-07-12 00:28 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2e6dd4d24206 RT-23079: CacheEntry in StyleHelper should weakly reference the shared cache from StylesheetContainer styleCache ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: a844e4fd4abf Author: David Grieve Date: 2012-07-12 16:20 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a844e4fd4abf RT-23256: ScrollPane with large content using mouse wheel is useless ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: eca72eaec20d Author: David Grieve Date: 2012-07-12 16:27 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/eca72eaec20d RT-22941 [ScrollBar, touch] knob is moving in wrong direction, when finger swipe is used. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 32a2ac15cc0e Author: Kinsley Wong Date: 2012-07-12 15:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/32a2ac15cc0e [DOC ONLY] RT-20847: some css properties are not covered in cssref. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: dcc106432347 Author: Paru Somashekar Date: 2012-07-12 15:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/dcc106432347 fix RT-23057 PieChart draws garbage when at min size ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 74b5a4b24935 Author: Paru Somashekar Date: 2012-07-12 15:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/74b5a4b24935 fix RT-21295 Setting chart data to null disables chart animation ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 6c543a637228 Author: Paru Somashekar Date: 2012-07-12 15:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6c543a637228 fix RT-21164 BarChart: Adding several bars in a row produces upside down bars. ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java Changeset: 231378f0f928 Author: Paru Somashekar Date: 2012-07-12 15:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/231378f0f928 fix RT-19903 Call ObservableList#clear() for LineChart result on IndexOutOfBoundsException. ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java Changeset: 374f5352788f Author: Paru Somashekar Date: 2012-07-12 16:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/374f5352788f fix RT-18985 Slider labels disappear too eagerly ! javafx-ui-controls/src/javafx/scene/chart/Axis.java Changeset: aa283b2f20ad Author: Kinsley Wong Date: 2012-07-12 16:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/aa283b2f20ad Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: d12adf6ea5d5 Author: David Grieve Date: 2012-07-13 13:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d12adf6ea5d5 RT-21894: unit test ! javafx-ui-controls/test/javafx/scene/control/MenuButtonTest.java Changeset: 8b3da2148b1b Author: David Grieve Date: 2012-07-13 13:15 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8b3da2148b1b RT-21894: LabeledImpl needs to track the origin of the Labeled properites it does not mirror. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: d3c8bd0df966 Author: Kinsley Wong Date: 2012-07-13 14:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d3c8bd0df966 [DOC ONLY] added some comments to EmbeddedTextContextMenuContent. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/EmbeddedTextContextMenuContent.java Changeset: b9a7024c3450 Author: jgiles Date: 2012-07-10 08:32 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b9a7024c3450 RT-23275: Editable combobox throws StackOverflowError when press ESC key ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 58bea6c6decc Author: jgiles Date: 2012-07-13 12:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/58bea6c6decc [DOC ONLY] RT-23308: All impl_* methods must be hidden from javadoc and marked as deprecated ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: e848c165aaa9 Author: jgiles Date: 2012-07-16 11:18 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e848c165aaa9 RT-22972: ComboBox with dynamic item list : issue with the "Empty" label ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 5ba93f3d48b7 Author: jgiles Date: 2012-07-16 11:57 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/5ba93f3d48b7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 7e06dda995b5 Author: leifs Date: 2012-07-16 18:57 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7e06dda995b5 Fixed RT-20845: TextField with bidirectional binding is not editable in applet but editable in standalone execution mode ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java Changeset: a6dd0e5c4451 Author: Paru Somashekar Date: 2012-07-16 10:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a6dd0e5c4451 fix RT-21141 XYChart changes categories order spontaneously on Remove DataItem ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java Changeset: 7c7bc01e9da4 Author: jgiles Date: 2012-07-17 07:16 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7c7bc01e9da4 Backed out changeset: e848c165aaa9 (RT-22972: ComboBox with dynamic item list : issue with the "Empty" label) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 264470ba524e Author: jgiles Date: 2012-07-17 07:17 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/264470ba524e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 9f73665d3945 Author: rbair Date: 2012-07-10 13:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9f73665d3945 Fix for RT-21784: use tag @since in the javadoc ! javafx-concurrent/src/javafx/concurrent/Task.java ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java ! javafx-ui-common/src/javafx/application/Platform.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SnapshotParameters.java ! javafx-ui-common/src/javafx/scene/SnapshotResult.java ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.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/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/transform/Transform.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.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/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/Menu.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/MapValueFactory.java ! javafx-ui-controls/src/javafx/scene/control/cell/ProgressBarTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java ! javafx-util-converter/src/javafx/util/converter/FormatStringConverter.java Changeset: b7f67bf6f737 Author: "Joseph Andresen" Date: 2012-07-10 14:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b7f67bf6f737 RT-22953 effects docs ! javafx-ui-common/src/javafx/scene/effect/Blend.java ! javafx-ui-common/src/javafx/scene/effect/Bloom.java ! javafx-ui-common/src/javafx/scene/effect/BoxBlur.java ! javafx-ui-common/src/javafx/scene/effect/ColorAdjust.java ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/DropShadow.java ! javafx-ui-common/src/javafx/scene/effect/FloatMap.java ! javafx-ui-common/src/javafx/scene/effect/GaussianBlur.java ! javafx-ui-common/src/javafx/scene/effect/Glow.java ! javafx-ui-common/src/javafx/scene/effect/ImageInput.java ! javafx-ui-common/src/javafx/scene/effect/InnerShadow.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java ! javafx-ui-common/src/javafx/scene/effect/MotionBlur.java ! javafx-ui-common/src/javafx/scene/effect/PerspectiveTransform.java ! javafx-ui-common/src/javafx/scene/effect/Reflection.java ! javafx-ui-common/src/javafx/scene/effect/SepiaTone.java ! javafx-ui-common/src/javafx/scene/effect/Shadow.java Changeset: 802e47751653 Author: "Joseph Andresen" Date: 2012-07-12 14:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/802e47751653 RT-21826 ImagePattern exception/background image load ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java Changeset: 2ca0c5dc56ee Author: Lubomir Nerad Date: 2012-07-13 10:25 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2ca0c5dc56ee Approved fix for RT-23062: Scene not getting garbage collected ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 871aea815e7a Author: "Joseph Andresen" Date: 2012-07-16 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/871aea815e7a RT-23395 Canvas Exception J2D ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 49d71d1bc5af Author: flar Date: 2012-07-16 19:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/49d71d1bc5af Fix RT-23433: Failures in ByteBgr,ByteBgra,ByteArgb conversion loops found by unit test. Reviewed by Kevin, approved by bug court. ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgra.java ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgb.java ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgba.java + javafx-ui-common/test/unit/com/sun/javafx/image/ConverterTest.java Changeset: 43999fd698ad Author: kcr Date: 2012-07-17 09:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/43999fd698ad Follow-on fix for RT-23395 to preserve the original set value (the first version of the fix did this) ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 7839d55ac4c0 Author: Yao Wang Date: 2012-07-17 10:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7839d55ac4c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: 4e47913d1062 Author: hudson Date: 2012-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4e47913d1062 Added tag 2.2-b18 for changeset 7839d55ac4c0 ! .hgtags From gouessej at orange.fr Thu Jul 19 03:22:21 2012 From: gouessej at orange.fr (gouessej at orange.fr) Date: Thu, 19 Jul 2012 12:22:21 +0200 (CEST) Subject: JavaFX and interoperability with Java bindings for the OpenGL API Message-ID: <1597749073.37031.1342693341208.JavaMail.www@wwinf1j20> Hi I have just read this article about JavaFX architecture : http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm Is it possible to use the OpenGL backend under Windows? We need to do that in order to benefit of the best performance and allow the use of any Java binding for the OpenGL API, especially JOGL 2.0. Direct3D seems to be used by default under Windows; if we can't change that (for example by setting a property like what we do for Java2D), there is a risk of conflict at driver level. How can another windowing toolkit monitor the way JavaFX draws its components? Best regards. From alexandre.iline at oracle.com Thu Jul 19 09:37:17 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Thu, 19 Jul 2012 16:37:17 +0000 Subject: hg: openjfx/2.2/master/tests: 6 new changesets Message-ID: <20120719163718.F0D6F47148@hg.openjdk.java.net> Changeset: cffb592b0930 Author: Alexandre (Shura) Iline Date: 2012-07-10 14:39 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/cffb592b0930 Menu sample from KAM + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/menu/MenuApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/menu/MenuSample.java Changeset: 7844f43c4834 Author: Alexandre (Shura) Iline Date: 2012-07-16 20:11 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/7844f43c4834 Menu work. Check the sample. ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/menu/MenuApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/menu/MenuSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/AbstractNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeParentImpl.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneNodeHierarchy.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/WindowList.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/WindowWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/WindowWrapper.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/Windows.java - tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AbstractMenuItemsParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/CheckBoxWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/CheckMenuItemWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ContextMenuWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuBarWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuButtonWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuItemParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuTreeSelectorImpl.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/RadioMenuItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/StringMenuOwnerImpl.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TabNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TableCellItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeItemWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeItemTest.java Changeset: c86f0c7ecdc4 Author: Oleg Barbashov Date: 2012-07-18 17:42 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/c86f0c7ecdc4 JemmyFX: ComboBoxWrap minor fixes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ComboBoxWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/ComboBoxApp.java Changeset: 41815a2a941f Author: Andrey Nazarov Date: 2012-07-18 16:10 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/41815a2a941f make node hierarchy public ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeHierarchy.java Changeset: ae097e5bfc13 Author: Alexandre (Shura) Iline Date: 2012-07-19 20:32 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/ae097e5bfc13 removed debug output ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/menu/MenuSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ComboBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeItemParent.java Changeset: 2d2e434c8d9f Author: Alexandre (Shura) Iline Date: 2012-07-19 20:33 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/2d2e434c8d9f merge ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ComboBoxWrap.java From pavel.safrata at oracle.com Thu Jul 19 13:39:57 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 19 Jul 2012 22:39:57 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5006516E.4030108@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> Message-ID: <5008709D.8030602@oracle.com> Or we could simply keep the J2D terminology prefixed with something, perhaps "apply". Pavel On 18.7.2012 8:02, Pavel Safrata wrote: > Hi guys, > I have one more idea. What about going the other way around and naming > the methods according to the matrix operations? That could be pretty > unambiguous I think: > > leftProduct (equivalent to J2D preConcatenate) > rightProduct (equivalent to concatenate) > leftTranslate (equivalent to preTranslate) > rightTranslate (equivalent to translate) > etc. > > Pavel From martin.desruisseaux at geomatys.fr Thu Jul 19 14:16:05 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 19 Jul 2012 23:16:05 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5008709D.8030602@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> Message-ID: <50087915.5060201@geomatys.fr> Le 19/07/12 22:39, Pavel Safrata a ?crit : > Or we could simply keep the J2D terminology prefixed with something, > perhaps "apply". On my side, I liked the method names that specify in which space the translation or scale apply, no matter if the methods use "source"/"target" or "prepend"/"append" or something else. I admit that there is different opinions of what "append" means. My view is strongly influenced by ISO-19111 and by the wording of Java2D AffineTransform.concatenate(...) javadoc, but I understand that other peoples will view the mathematical notation instead. It seems to me that the choices depend on the "pedagogic" approach chosen for telling to the users what the methods do. I see the following choices (not trying to be exhaustive; I just list what - in my current understanding - seem the most frequent/debated points of views): 1) The "operation chain" point of view (ISO-19111 and AffineTransform.concatenate(...) javadoc wording). 2) The mathematical (especially matrix) notation point of view. I have a preference for 1 given that, in my past experience with an open source project, I realized that many Java developers seem to be a bit scared by mathematics. However I think I will be fine with whatever you select. Regards, Martin From hang.vo at oracle.com Thu Jul 19 15:33:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 19 Jul 2012 22:33:26 +0000 Subject: hg: openjfx/2.2/controls/rt: 9 new changesets Message-ID: <20120719223337.DF69147152@hg.openjdk.java.net> Changeset: 9f73665d3945 Author: rbair Date: 2012-07-10 13:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9f73665d3945 Fix for RT-21784: use tag @since in the javadoc ! javafx-concurrent/src/javafx/concurrent/Task.java ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java ! javafx-ui-common/src/javafx/application/Platform.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SnapshotParameters.java ! javafx-ui-common/src/javafx/scene/SnapshotResult.java ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyCode.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/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/transform/Transform.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.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/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/Menu.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/MapValueFactory.java ! javafx-ui-controls/src/javafx/scene/control/cell/ProgressBarTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java ! javafx-util-converter/src/javafx/util/converter/FormatStringConverter.java Changeset: b7f67bf6f737 Author: "Joseph Andresen" Date: 2012-07-10 14:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b7f67bf6f737 RT-22953 effects docs ! javafx-ui-common/src/javafx/scene/effect/Blend.java ! javafx-ui-common/src/javafx/scene/effect/Bloom.java ! javafx-ui-common/src/javafx/scene/effect/BoxBlur.java ! javafx-ui-common/src/javafx/scene/effect/ColorAdjust.java ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/effect/DisplacementMap.java ! javafx-ui-common/src/javafx/scene/effect/DropShadow.java ! javafx-ui-common/src/javafx/scene/effect/FloatMap.java ! javafx-ui-common/src/javafx/scene/effect/GaussianBlur.java ! javafx-ui-common/src/javafx/scene/effect/Glow.java ! javafx-ui-common/src/javafx/scene/effect/ImageInput.java ! javafx-ui-common/src/javafx/scene/effect/InnerShadow.java ! javafx-ui-common/src/javafx/scene/effect/Lighting.java ! javafx-ui-common/src/javafx/scene/effect/MotionBlur.java ! javafx-ui-common/src/javafx/scene/effect/PerspectiveTransform.java ! javafx-ui-common/src/javafx/scene/effect/Reflection.java ! javafx-ui-common/src/javafx/scene/effect/SepiaTone.java ! javafx-ui-common/src/javafx/scene/effect/Shadow.java Changeset: 802e47751653 Author: "Joseph Andresen" Date: 2012-07-12 14:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/802e47751653 RT-21826 ImagePattern exception/background image load ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java Changeset: 2ca0c5dc56ee Author: Lubomir Nerad Date: 2012-07-13 10:25 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2ca0c5dc56ee Approved fix for RT-23062: Scene not getting garbage collected ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 871aea815e7a Author: "Joseph Andresen" Date: 2012-07-16 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/871aea815e7a RT-23395 Canvas Exception J2D ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 49d71d1bc5af Author: flar Date: 2012-07-16 19:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/49d71d1bc5af Fix RT-23433: Failures in ByteBgr,ByteBgra,ByteArgb conversion loops found by unit test. Reviewed by Kevin, approved by bug court. ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgra.java ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgb.java ! javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgba.java + javafx-ui-common/test/unit/com/sun/javafx/image/ConverterTest.java Changeset: 43999fd698ad Author: kcr Date: 2012-07-17 09:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/43999fd698ad Follow-on fix for RT-23395 to preserve the original set value (the first version of the fix did this) ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 7839d55ac4c0 Author: Yao Wang Date: 2012-07-17 10:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7839d55ac4c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: 4e47913d1062 Author: hudson Date: 2012-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4e47913d1062 Added tag 2.2-b18 for changeset 7839d55ac4c0 ! .hgtags From leonid.popov at oracle.com Fri Jul 20 08:23:52 2012 From: leonid.popov at oracle.com (Leonid Popov) Date: Fri, 20 Jul 2012 19:23:52 +0400 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <4FAE5143.4080409@oracle.com> References: <4FAE5143.4080409@oracle.com> Message-ID: <50097808.4030205@oracle.com> (Sorry, re-sending the same request with the correct subject, as specified by Richard) Hi, Some time ago Peter proposed an API change introducing a new property for WebView. Unfortunately, it hasn't gone to 2.2, so I (as the actual owner of this issue) am re-requesting the API change described below in the original Peter's email, now for JavaFX 3.0. Thanks, Leonid -------- Original Message -------- Subject: API Request: WebView.scale property Date: Sat, 12 May 2012 16:02:11 +0400 From: Peter Zhelezniakov To: openjfx-dev at openjdk.java.net , jfx-webnode_us_grp at oracle.com I suggest adding 'scale' property to WebView: class javafx.scene.web.WebView { /** * Scale factor applied to the Web page. The scale affects logical bounds * of the Web page, but not bounds of the {@code WebView} node. * * @defaultValue 1.0 */ public final void setScale(double value); public final double getScale(); public DoubleProperty scaleProperty(); } This property is different from scaleX/Y in several ways: - scale is applied internally, i.e. logical bounds of the web page change but WebView bounds don't; rather, scrollbars are updated. Likewise in a frameset document frame bounds don't change. - Scrollbars are not scaled and keep their regular size. Similar functionality can be found in browsers, e.g. try Ctrl+/Ctrl- in Firefox. WebView currently has a similar property called fontScale, but that applies to text elements only. http://javafx-jira.kenai.com/browse/RT-21499 Thanks! -- Peter | x33066 | St Petersburg, Russia | timezone: GMT+04 From Sergey.Malenkov at oracle.com Fri Jul 20 08:34:37 2012 From: Sergey.Malenkov at oracle.com (Sergey Malenkov) Date: Fri, 20 Jul 2012 19:34:37 +0400 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <50097808.4030205@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> Message-ID: <50097A8D.3030200@oracle.com> Hi Leonid, What do you think about renaming this property to "zoom"? I think that "scale" will confuse users because of Node.scaleX/scaleY. Also it is a common expression for webpage scaling, for example: http://windows.microsoft.com/en-us/windows-vista/Zoom-in-on-a-webpage Thanks, SAM On 20.07.2012 19:23, Leonid Popov wrote: > (Sorry, re-sending the same request with the correct subject, as > specified by Richard) > > Hi, > > Some time ago Peter proposed an API change introducing a new property > for WebView. Unfortunately, it hasn't gone to 2.2, so I (as the actual > owner of this issue) am re-requesting the API change described below in > the original Peter's email, now for JavaFX 3.0. > > Thanks, > Leonid > > -------- Original Message -------- > Subject: API Request: WebView.scale property > Date: Sat, 12 May 2012 16:02:11 +0400 > From: Peter Zhelezniakov > To: openjfx-dev at openjdk.java.net , > jfx-webnode_us_grp at oracle.com > > > > I suggest adding 'scale' property to WebView: > > class javafx.scene.web.WebView { > /** > * Scale factor applied to the Web page. The scale affects logical > bounds > * of the Web page, but not bounds of the {@code WebView} node. > * > * @defaultValue 1.0 > */ > public final void setScale(double value); > public final double getScale(); > public DoubleProperty scaleProperty(); > } > > This property is different from scaleX/Y in several ways: > - scale is applied internally, i.e. logical bounds of the web page > change but WebView bounds don't; rather, scrollbars are updated. > Likewise in a frameset document frame bounds don't change. > - Scrollbars are not scaled and keep their regular size. > > Similar functionality can be found in browsers, e.g. try Ctrl+/Ctrl- in > Firefox. WebView currently has a similar property called fontScale, but > that applies to text elements only. > > http://javafx-jira.kenai.com/browse/RT-21499 > > Thanks! From leonid.popov at oracle.com Fri Jul 20 09:14:21 2012 From: leonid.popov at oracle.com (Leonid Popov) Date: Fri, 20 Jul 2012 20:14:21 +0400 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <50097A8D.3030200@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> Message-ID: <500983DD.2040407@oracle.com> Hi Sergey, It sounds reasonable, assuming that scaleX/scaleY have slightly different semantics (they apply to the whole view, including scrollbars, while the proposed property should affect WebView contents only). Any other opinions on scale vs. zoom? Thanks, Leonid On 7/20/2012 7:34 PM, Sergey Malenkov wrote: > Hi Leonid, > > What do you think about renaming this property to "zoom"? > I think that "scale" will confuse users because of Node.scaleX/scaleY. > Also it is a common expression for webpage scaling, for example: > http://windows.microsoft.com/en-us/windows-vista/Zoom-in-on-a-webpage > > Thanks, > SAM > > On 20.07.2012 19:23, Leonid Popov wrote: >> (Sorry, re-sending the same request with the correct subject, as >> specified by Richard) >> >> Hi, >> >> Some time ago Peter proposed an API change introducing a new property >> for WebView. Unfortunately, it hasn't gone to 2.2, so I (as the actual >> owner of this issue) am re-requesting the API change described below in >> the original Peter's email, now for JavaFX 3.0. >> >> Thanks, >> Leonid >> >> -------- Original Message -------- >> Subject: API Request: WebView.scale property >> Date: Sat, 12 May 2012 16:02:11 +0400 >> From: Peter Zhelezniakov >> To: openjfx-dev at openjdk.java.net , >> jfx-webnode_us_grp at oracle.com >> >> >> >> I suggest adding 'scale' property to WebView: >> >> class javafx.scene.web.WebView { >> /** >> * Scale factor applied to the Web page. The scale affects logical >> bounds >> * of the Web page, but not bounds of the {@code WebView} node. >> * >> * @defaultValue 1.0 >> */ >> public final void setScale(double value); >> public final double getScale(); >> public DoubleProperty scaleProperty(); >> } >> >> This property is different from scaleX/Y in several ways: >> - scale is applied internally, i.e. logical bounds of the web page >> change but WebView bounds don't; rather, scrollbars are updated. >> Likewise in a frameset document frame bounds don't change. >> - Scrollbars are not scaled and keep their regular size. >> >> Similar functionality can be found in browsers, e.g. try Ctrl+/Ctrl- in >> Firefox. WebView currently has a similar property called fontScale, but >> that applies to text elements only. >> >> http://javafx-jira.kenai.com/browse/RT-21499 >> >> Thanks! From richard.bair at oracle.com Fri Jul 20 09:32:55 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 20 Jul 2012 09:32:55 -0700 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <500983DD.2040407@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> Message-ID: Personally I liked zoom better. On Jul 20, 2012, at 9:14 AM, Leonid Popov wrote: > Hi Sergey, > > It sounds reasonable, assuming that scaleX/scaleY have slightly different semantics (they apply to the whole view, including scrollbars, while the proposed property should affect WebView contents only). Any other opinions on scale vs. zoom? > > Thanks, > Leonid > > On 7/20/2012 7:34 PM, Sergey Malenkov wrote: >> Hi Leonid, >> >> What do you think about renaming this property to "zoom"? >> I think that "scale" will confuse users because of Node.scaleX/scaleY. >> Also it is a common expression for webpage scaling, for example: >> http://windows.microsoft.com/en-us/windows-vista/Zoom-in-on-a-webpage >> >> Thanks, >> SAM >> >> On 20.07.2012 19:23, Leonid Popov wrote: >>> (Sorry, re-sending the same request with the correct subject, as >>> specified by Richard) >>> >>> Hi, >>> >>> Some time ago Peter proposed an API change introducing a new property >>> for WebView. Unfortunately, it hasn't gone to 2.2, so I (as the actual >>> owner of this issue) am re-requesting the API change described below in >>> the original Peter's email, now for JavaFX 3.0. >>> >>> Thanks, >>> Leonid >>> >>> -------- Original Message -------- >>> Subject: API Request: WebView.scale property >>> Date: Sat, 12 May 2012 16:02:11 +0400 >>> From: Peter Zhelezniakov >>> To: openjfx-dev at openjdk.java.net , >>> jfx-webnode_us_grp at oracle.com >>> >>> >>> >>> I suggest adding 'scale' property to WebView: >>> >>> class javafx.scene.web.WebView { >>> /** >>> * Scale factor applied to the Web page. The scale affects logical >>> bounds >>> * of the Web page, but not bounds of the {@code WebView} node. >>> * >>> * @defaultValue 1.0 >>> */ >>> public final void setScale(double value); >>> public final double getScale(); >>> public DoubleProperty scaleProperty(); >>> } >>> >>> This property is different from scaleX/Y in several ways: >>> - scale is applied internally, i.e. logical bounds of the web page >>> change but WebView bounds don't; rather, scrollbars are updated. >>> Likewise in a frameset document frame bounds don't change. >>> - Scrollbars are not scaled and keep their regular size. >>> >>> Similar functionality can be found in browsers, e.g. try Ctrl+/Ctrl- in >>> Firefox. WebView currently has a similar property called fontScale, but >>> that applies to text elements only. >>> >>> http://javafx-jira.kenai.com/browse/RT-21499 >>> >>> Thanks! > From greg.x.brown at oracle.com Fri Jul 20 10:01:34 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 20 Jul 2012 13:01:34 -0400 Subject: API change request (RT-23413) Message-ID: This change would add a clearImports() method to FXMLLoader. See http://javafx-jira.kenai.com/browse/RT-23413. Justification (from JIRA): "If the FXMLLoader is used to load the same fxml-file mutliple times, it should be able to cache the collected information about classes and properties between the load() calls. This would massively improve the performance when using one fxml-file to describe an arbitrary number of objects." Implementation: FXMLLoader no longer clears the imports when load() is called; instead, any previous imports are preserved. Callers can explicitly clear the imports via a new method named clearImports(); however, in practice, this won't generally be necessary, since FXMLLoader instances are typically only used once and then disposed. From richard.bair at oracle.com Fri Jul 20 10:04:42 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 20 Jul 2012 10:04:42 -0700 Subject: API change request (RT-23413) In-Reply-To: References: Message-ID: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> Right, so the place where somebody would get tripped up by this change is if they use the same FXMLLoader instance for loading multiple different FXML files, is that right? One other thing I just thought of right this moment -- what if we auto-cleared the imports when calling load on a different URL than was used the last time? Richard On Jul 20, 2012, at 10:01 AM, Greg Brown wrote: > This change would add a clearImports() method to FXMLLoader. See http://javafx-jira.kenai.com/browse/RT-23413. > > Justification (from JIRA): > > "If the FXMLLoader is used to load the same fxml-file mutliple times, it should be able to cache the collected information about classes and properties between the load() calls. This would massively improve the performance when using one fxml-file to describe an arbitrary number of objects." > > Implementation: > > FXMLLoader no longer clears the imports when load() is called; instead, any previous imports are preserved. Callers can explicitly clear the imports via a new method named clearImports(); however, in practice, this won't generally be necessary, since FXMLLoader instances are typically only used once and then disposed. > From greg.x.brown at oracle.com Fri Jul 20 10:10:23 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 20 Jul 2012 13:10:23 -0400 Subject: API change request (RT-23413) In-Reply-To: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> References: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> Message-ID: > Right, so the place where somebody would get tripped up by this change is if they use the same FXMLLoader instance for loading multiple different FXML files, is that right? Right. But that would only happen if a) a loader instance was re-used, which is uncommon and b) the second document referred to a class with the same name but different package than a class referenced by the first document (also uncommon). > One other thing I just thought of right this moment -- what if we auto-cleared the imports when calling load on a different URL than was used the last time? That would work, but I don't think there's much harm in simply preserving the imports. If you really want to make sure they are cleared, you can either use a new loader instance or call clearImports(). From richard.bair at oracle.com Fri Jul 20 10:13:37 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 20 Jul 2012 10:13:37 -0700 Subject: API change request (RT-23413) In-Reply-To: References: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> Message-ID: <8C2B3A5E-E154-47A6-9A0E-EA86544C4AD4@oracle.com> On Jul 20, 2012, at 10:10 AM, Greg Brown wrote: >> Right, so the place where somebody would get tripped up by this change is if they use the same FXMLLoader instance for loading multiple different FXML files, is that right? > > Right. But that would only happen if a) a loader instance was re-used, which is uncommon and b) the second document referred to a class with the same name but different package than a class referenced by the first document (also uncommon). Correct, the fact that we don't have APIs with the same name but in different packages makes this less common (although I expect quite difficult to debug if it happens!) >> One other thing I just thought of right this moment -- what if we auto-cleared the imports when calling load on a different URL than was used the last time? > > That would work, but I don't think there's much harm in simply preserving the imports. If you really want to make sure they are cleared, you can either use a new loader instance or call clearImports(). I'm just wondering if we can get the best behavior by default without the developer having to do anything special. That is, the behavior would still be correct (even those edge cases mentioned above wouldn't occur) but when a single FXMLLoader is used to load multiple instances of the same document all the imports are already cached. From steve.x.northover at oracle.com Fri Jul 20 10:54:22 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 20 Jul 2012 13:54:22 -0400 Subject: API change request (RT-23413) In-Reply-To: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> References: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> Message-ID: <50099B4E.602@oracle.com> Is there a case where someone could get burned by the caching? If so, we could leave the default behavior and have a setImportsCached/getImportsCached flag. Steve On 20/07/2012 1:04 PM, Richard Bair wrote: > Right, so the place where somebody would get tripped up by this change is if they use the same FXMLLoader instance for loading multiple different FXML files, is that right? > > One other thing I just thought of right this moment -- what if we auto-cleared the imports when calling load on a different URL than was used the last time? > > Richard > > On Jul 20, 2012, at 10:01 AM, Greg Brown wrote: > >> This change would add a clearImports() method to FXMLLoader. See http://javafx-jira.kenai.com/browse/RT-23413. >> >> Justification (from JIRA): >> >> "If the FXMLLoader is used to load the same fxml-file mutliple times, it should be able to cache the collected information about classes and properties between the load() calls. This would massively improve the performance when using one fxml-file to describe an arbitrary number of objects." >> >> Implementation: >> >> FXMLLoader no longer clears the imports when load() is called; instead, any previous imports are preserved. Callers can explicitly clear the imports via a new method named clearImports(); however, in practice, this won't generally be necessary, since FXMLLoader instances are typically only used once and then disposed. >> From greg.x.brown at oracle.com Fri Jul 20 11:08:09 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 20 Jul 2012 14:08:09 -0400 Subject: API change request (RT-23413) In-Reply-To: <8C2B3A5E-E154-47A6-9A0E-EA86544C4AD4@oracle.com> References: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> <8C2B3A5E-E154-47A6-9A0E-EA86544C4AD4@oracle.com> Message-ID: <86C3F528-EFA6-431A-9087-F8F3B33384AA@oracle.com> >>> One other thing I just thought of right this moment -- what if we auto-cleared the imports when calling load on a different URL than was used the last time? >> >> That would work, but I don't think there's much harm in simply preserving the imports. If you really want to make sure they are cleared, you can either use a new loader instance or call clearImports(). > > I'm just wondering if we can get the best behavior by default without the developer having to do anything special. That is, the behavior would still be correct (even those edge cases mentioned above wouldn't occur) but when a single FXMLLoader is used to load multiple instances of the same document all the imports are already cached. I agree that it would be ideal if we could optimize the load behavior transparently. However, it occurred to me that clearing the cache based on URL might not always work either. If the caller is using the same FXMLLoader instance to load content from a URL that refers to a web site, the document's content could easily be different for each invocation of load(). If we don't want to introduce any potentially confusing behavior, then Steve's suggestion is probably the way to go (allow the user to configure the behavior using a flag). From Richard.Bair at oracle.com Fri Jul 20 11:28:20 2012 From: Richard.Bair at oracle.com (Richard Bair) Date: Fri, 20 Jul 2012 11:28:20 -0700 Subject: API change request (RT-23413) In-Reply-To: <86C3F528-EFA6-431A-9087-F8F3B33384AA@oracle.com> References: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> <8C2B3A5E-E154-47A6-9A0E-EA86544C4AD4@oracle.com> <86C3F528-EFA6-431A-9087-F8F3B33384AA@oracle.com> Message-ID: <18251FA2-9152-4878-A60D-BFABCC80E6BF@oracle.com> >>>> One other thing I just thought of right this moment -- what if we auto-cleared the imports when calling load on a different URL than was used the last time? >>> >>> That would work, but I don't think there's much harm in simply preserving the imports. If you really want to make sure they are cleared, you can either use a new loader instance or call clearImports(). >> >> I'm just wondering if we can get the best behavior by default without the developer having to do anything special. That is, the behavior would still be correct (even those edge cases mentioned above wouldn't occur) but when a single FXMLLoader is used to load multiple instances of the same document all the imports are already cached. > > I agree that it would be ideal if we could optimize the load behavior transparently. However, it occurred to me that clearing the cache based on URL might not always work either. If the caller is using the same FXMLLoader instance to load content from a URL that refers to a web site, the document's content could easily be different for each invocation of load(). > > If we don't want to introduce any potentially confusing behavior, then Steve's suggestion is probably the way to go (allow the user to configure the behavior using a flag). Would you need this method in that case, or is the flag sufficient? I kind of like the flag idea in that nobody gets burned, they opt into this behavior when they know they have a situation that it works for. The downside is that since it isn't enabled by default (?) people first run into a performance problem and then investigate it and then flip the flag. Of course libraries / frameworks like ZenJava could handle this by default. Richard From greg.x.brown at oracle.com Fri Jul 20 11:31:52 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 20 Jul 2012 14:31:52 -0400 Subject: API change request (RT-23413) In-Reply-To: <18251FA2-9152-4878-A60D-BFABCC80E6BF@oracle.com> References: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> <8C2B3A5E-E154-47A6-9A0E-EA86544C4AD4@oracle.com> <86C3F528-EFA6-431A-9087-F8F3B33384AA@oracle.com> <18251FA2-9152-4878-A60D-BFABCC80E6BF@oracle.com> Message-ID: <52896308-AE65-479E-A0F7-CA10980BA9E8@oracle.com> > Would you need this method in that case, or is the flag sufficient? Just the flag. > I kind of like the flag idea in that nobody gets burned, they opt into this behavior when they know they have a situation that it works for. Agreed. > The downside is that since it isn't enabled by default (?) people first run into a performance problem and then investigate it and then flip the flag. Right. That's why my first inclination was to make this the default behavior, since most callers won't re-use FXMLLoader instances and thus won't get burned by it. But to be on the safe side, requiring callers to proactively enable it is probably best. G From Richard.Bair at oracle.com Fri Jul 20 11:36:23 2012 From: Richard.Bair at oracle.com (Richard Bair) Date: Fri, 20 Jul 2012 11:36:23 -0700 Subject: API change request (RT-23413) In-Reply-To: <52896308-AE65-479E-A0F7-CA10980BA9E8@oracle.com> References: <6C62F1DC-05B6-40B3-8121-A42D8AFBE799@oracle.com> <8C2B3A5E-E154-47A6-9A0E-EA86544C4AD4@oracle.com> <86C3F528-EFA6-431A-9087-F8F3B33384AA@oracle.com> <18251FA2-9152-4878-A60D-BFABCC80E6BF@oracle.com> <52896308-AE65-479E-A0F7-CA10980BA9E8@oracle.com> Message-ID: Sounds good to me. On Jul 20, 2012, at 11:31 AM, Greg Brown wrote: >> Would you need this method in that case, or is the flag sufficient? > > Just the flag. > >> I kind of like the flag idea in that nobody gets burned, they opt into this behavior when they know they have a situation that it works for. > > Agreed. > >> The downside is that since it isn't enabled by default (?) people first run into a performance problem and then investigate it and then flip the flag. > > Right. That's why my first inclination was to make this the default behavior, since most callers won't re-use FXMLLoader instances and thus won't get burned by it. But to be on the safe side, requiring callers to proactively enable it is probably best. > > G > From daniel.fuchs at oracle.com Fri Jul 20 11:59:29 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 20 Jul 2012 20:59:29 +0200 Subject: API change request (RT-23413) In-Reply-To: References: Message-ID: <5009AA91.6070709@oracle.com> Hi, Whatever option you choose, I think you need to clear the imports if the ClassLoader changes. Otherwise you might use the class that was returned by the previous ClassLoader, which would be bad. Also you probably need to specify what happens if the default class loader is changed. Does that affect existing FXMLLoader instances? I guess not... "Sets the default ClassLoader" is maybe a bit too concise ;-) best regards, -- daniel From greg.x.brown at oracle.com Fri Jul 20 12:03:21 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 20 Jul 2012 15:03:21 -0400 Subject: API change request (RT-23413) In-Reply-To: <5009AA91.6070709@oracle.com> References: <5009AA91.6070709@oracle.com> Message-ID: Good point. Thanks! On Jul 20, 2012, at 2:59 PM, Daniel Fuchs wrote: > Hi, > > Whatever option you choose, I think you need to clear the imports if the ClassLoader changes. > Otherwise you might use the class that was returned by the previous ClassLoader, which would be > bad. > Also you probably need to specify what happens if the default class loader is changed. Does that > affect existing FXMLLoader instances? I guess not... > "Sets the default ClassLoader" is maybe a bit too concise ;-) > > best regards, > > -- daniel From pedro.duquevieira at gmail.com Fri Jul 20 15:02:19 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 20 Jul 2012 23:02:19 +0100 Subject: Transform point using localToSceneTransform Message-ID: Hi, I need to transform a point using the localToSceneTransform of a node, however I don't see any method on Transform class to accomplish this. Is there an easy way or do I have to do the math myself? Thanks, best regards, -- Pedro Duque Vieira From james.graham at oracle.com Fri Jul 20 17:02:15 2012 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 Jul 2012 17:02:15 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <50087915.5060201@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> Message-ID: <5009F187.4030002@oracle.com> When I wrote my first reply in this thread I tried to warn people that I was coming back from vacation to a long thread and I hadn't double checked all of the math that was being proposed, so I was commenting from a general perspective that wasn't necessarily in agreement or conflict with the current proposal at the time. I hope that I didn't send people off on a wild goose chase based on my list of points that may have come from a negative "we shouldn't do this or that" kind of perspective. To switch things around, let me make some positive statements of something that I would find acceptable and which I think may have actually been formally proposed here (but I didn't "do the math" to verify that). I believe that the following produce equivalent transforms: -------------- Node.getTransforms().add(new Scale(sx,sy)); Node.getTransforms().add(new Translate(tx,ty)); --- t = new java.awt.geom.AffineTransform(); t.scale(sx, sy); t.translate(tx, ty); --- t = new java.awt.geom.AffineTransform(); tmp = new java.awt.geom.AffineTransform(); tmp.setToScale(sx, sy); t.concatenate(tmp); tmp.setToTranslate(tx, ty); t.concatenate(tmp); --- Node n...; Group g = new Group(n); g.setScale(sx, sy); n.setTranslate(tx, ty); -------------- We also have the fact that "preConcatenate()" is mathematically reversed, and also inside-out from the perspective of what is being manipluated, as compared to concatenate(). So, if "appendFoo(...)" was essentially equivalent to: - Node.getTransforms().add(new Foo(...)); - t.foo(...); - t.concatenate(tmp.setToFoo(...)); and "prependFoo(...)" was essentially equivalent to: - Node.getTransforms().add(0, new Foo(...)); - we don't have a Java2D reverse for t.foo(); - t.preConcatenate(tmp.setToFoo(...)); then I could be happy. It may not have complete unambiguity in an absolute sense, but it would at least establish an internal consistency and harmony of naming conventions with respect to the JavaFX Node transform attributes and with the prior art in the Java geometry family (AffineTransform)... I feel that append, while we can argue the semantics of what it might mean mathematically, sounds like the more natural verb of the two forms of methods (comparing appendFoo to prependFoo), and in general it is the set of methods that they probably want to be using if they come from Java2D, or if they are writing code that takes a transform from somewhere else that defines their "transformation context" and they want to work within that (if you prepend, then you override the context someone set up for you, if you append, then you take their context and work relative to it). Is that what was being proposed before I came in and stomped on the discussion? ...jim From ozemale at ozemail.com.au Fri Jul 20 17:04:20 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sat, 21 Jul 2012 10:04:20 +1000 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> Message-ID: <004401cd66d4$613b7980$23b26c80$@com.au> Why not zoomX() and zoomY() for flexibility? -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair Sent: Saturday, 21 July 2012 02:33 To: Leonid Popov Cc: openjfx-dev at openjdk.java.net; jfx-webnode_us_grp at oracle.com; Sergey Malenkov Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) Personally I liked zoom better. On Jul 20, 2012, at 9:14 AM, Leonid Popov wrote: > Hi Sergey, > > It sounds reasonable, assuming that scaleX/scaleY have slightly different semantics (they apply to the whole view, including scrollbars, while the proposed property should affect WebView contents only). Any other opinions on scale vs. zoom? > > Thanks, > Leonid > > On 7/20/2012 7:34 PM, Sergey Malenkov wrote: >> Hi Leonid, >> >> What do you think about renaming this property to "zoom"? >> I think that "scale" will confuse users because of Node.scaleX/scaleY. >> Also it is a common expression for webpage scaling, for example: >> http://windows.microsoft.com/en-us/windows-vista/Zoom-in-on-a-webpage >> >> Thanks, >> SAM >> >> On 20.07.2012 19:23, Leonid Popov wrote: >>> (Sorry, re-sending the same request with the correct subject, as >>> specified by Richard) >>> >>> Hi, >>> >>> Some time ago Peter proposed an API change introducing a new >>> property for WebView. Unfortunately, it hasn't gone to 2.2, so I (as >>> the actual owner of this issue) am re-requesting the API change >>> described below in the original Peter's email, now for JavaFX 3.0. >>> >>> Thanks, >>> Leonid >>> >>> -------- Original Message -------- >>> Subject: API Request: WebView.scale property >>> Date: Sat, 12 May 2012 16:02:11 +0400 >>> From: Peter Zhelezniakov >>> To: openjfx-dev at openjdk.java.net , >>> jfx-webnode_us_grp at oracle.com >>> >>> >>> >>> I suggest adding 'scale' property to WebView: >>> >>> class javafx.scene.web.WebView { >>> /** >>> * Scale factor applied to the Web page. The scale affects logical >>> bounds >>> * of the Web page, but not bounds of the {@code WebView} node. >>> * >>> * @defaultValue 1.0 >>> */ >>> public final void setScale(double value); public final double >>> getScale(); public DoubleProperty scaleProperty(); } >>> >>> This property is different from scaleX/Y in several ways: >>> - scale is applied internally, i.e. logical bounds of the web page >>> change but WebView bounds don't; rather, scrollbars are updated. >>> Likewise in a frameset document frame bounds don't change. >>> - Scrollbars are not scaled and keep their regular size. >>> >>> Similar functionality can be found in browsers, e.g. try Ctrl+/Ctrl- >>> in Firefox. WebView currently has a similar property called >>> fontScale, but that applies to text elements only. >>> >>> http://javafx-jira.kenai.com/browse/RT-21499 >>> >>> Thanks! > From james.graham at oracle.com Fri Jul 20 17:09:03 2012 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 Jul 2012 17:09:03 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <5009F187.4030002@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> Message-ID: <5009F31F.2060303@oracle.com> I should have added that the reasons I think it creates a harmony of naming conventions is that we would have the association: appendFoo() is like adding Foo to the end of a Node.getTransforms() list and prependFoo() is like doing foo with a *pre*Concatenate (or similarly, like prepending Foo to the start of a Node tx list) The append and prepend names follow reasonably straightforwardly from either of those two semantic models... ...jim On 7/20/2012 5:02 PM, Jim Graham wrote: > When I wrote my first reply in this thread I tried to warn people that I > was coming back from vacation to a long thread and I hadn't double > checked all of the math that was being proposed, so I was commenting > from a general perspective that wasn't necessarily in agreement or > conflict with the current proposal at the time. I hope that I didn't > send people off on a wild goose chase based on my list of points that > may have come from a negative "we shouldn't do this or that" kind of > perspective. > > To switch things around, let me make some positive statements of > something that I would find acceptable and which I think may have > actually been formally proposed here (but I didn't "do the math" to > verify that). > > I believe that the following produce equivalent transforms: > > -------------- > Node.getTransforms().add(new Scale(sx,sy)); > Node.getTransforms().add(new Translate(tx,ty)); > --- > t = new java.awt.geom.AffineTransform(); > t.scale(sx, sy); > t.translate(tx, ty); > --- > t = new java.awt.geom.AffineTransform(); > tmp = new java.awt.geom.AffineTransform(); > tmp.setToScale(sx, sy); > t.concatenate(tmp); > tmp.setToTranslate(tx, ty); > t.concatenate(tmp); > --- > Node n...; > Group g = new Group(n); > g.setScale(sx, sy); > n.setTranslate(tx, ty); > -------------- > > We also have the fact that "preConcatenate()" is mathematically > reversed, and also inside-out from the perspective of what is being > manipluated, as compared to concatenate(). > > So, if "appendFoo(...)" was essentially equivalent to: > > - Node.getTransforms().add(new Foo(...)); > - t.foo(...); > - t.concatenate(tmp.setToFoo(...)); > > and "prependFoo(...)" was essentially equivalent to: > > - Node.getTransforms().add(0, new Foo(...)); > - we don't have a Java2D reverse for t.foo(); > - t.preConcatenate(tmp.setToFoo(...)); > > then I could be happy. It may not have complete unambiguity in an > absolute sense, but it would at least establish an internal consistency > and harmony of naming conventions with respect to the JavaFX Node > transform attributes and with the prior art in the Java geometry family > (AffineTransform)... > > I feel that append, while we can argue the semantics of what it might > mean mathematically, sounds like the more natural verb of the two forms > of methods (comparing appendFoo to prependFoo), and in general it is the > set of methods that they probably want to be using if they come from > Java2D, or if they are writing code that takes a transform from > somewhere else that defines their "transformation context" and they want > to work within that (if you prepend, then you override the context > someone set up for you, if you append, then you take their context and > work relative to it). > > Is that what was being proposed before I came in and stomped on the > discussion? > > ...jim > From ozemale at ozemail.com.au Fri Jul 20 17:15:58 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sat, 21 Jul 2012 10:15:58 +1000 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <004401cd66d4$613b7980$23b26c80$@com.au> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <004401cd66d4$613b7980$23b26c80$@com.au> Message-ID: <004a01cd66d6$0134bb80$039e3280$@com.au> Actually, zoomX() and zoomY() probably aren't necessary but why are we focusing on WebView here? Surely this should be at the Node level? I want to be able to zoom in on images, graphics etc. where only the contents zoom, not the scroll bars. I very much have a use case for this. -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of John C. Turnbull Sent: Saturday, 21 July 2012 10:04 To: 'Richard Bair'; 'Leonid Popov' Cc: openjfx-dev at openjdk.java.net; jfx-webnode_us_grp at oracle.com; 'Sergey Malenkov' Subject: RE: API REVIEW: WebView.scale property (for JavaFX 3.0 now) Why not zoomX() and zoomY() for flexibility? -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair Sent: Saturday, 21 July 2012 02:33 To: Leonid Popov Cc: openjfx-dev at openjdk.java.net; jfx-webnode_us_grp at oracle.com; Sergey Malenkov Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) Personally I liked zoom better. On Jul 20, 2012, at 9:14 AM, Leonid Popov wrote: > Hi Sergey, > > It sounds reasonable, assuming that scaleX/scaleY have slightly > different semantics (they apply to the whole view, including scrollbars, while the proposed property should affect WebView contents only). Any other opinions on scale vs. zoom? > > Thanks, > Leonid > > On 7/20/2012 7:34 PM, Sergey Malenkov wrote: >> Hi Leonid, >> >> What do you think about renaming this property to "zoom"? >> I think that "scale" will confuse users because of Node.scaleX/scaleY. >> Also it is a common expression for webpage scaling, for example: >> http://windows.microsoft.com/en-us/windows-vista/Zoom-in-on-a-webpage >> >> Thanks, >> SAM >> >> On 20.07.2012 19:23, Leonid Popov wrote: >>> (Sorry, re-sending the same request with the correct subject, as >>> specified by Richard) >>> >>> Hi, >>> >>> Some time ago Peter proposed an API change introducing a new >>> property for WebView. Unfortunately, it hasn't gone to 2.2, so I (as >>> the actual owner of this issue) am re-requesting the API change >>> described below in the original Peter's email, now for JavaFX 3.0. >>> >>> Thanks, >>> Leonid >>> >>> -------- Original Message -------- >>> Subject: API Request: WebView.scale property >>> Date: Sat, 12 May 2012 16:02:11 +0400 >>> From: Peter Zhelezniakov >>> To: openjfx-dev at openjdk.java.net , >>> jfx-webnode_us_grp at oracle.com >>> >>> >>> >>> I suggest adding 'scale' property to WebView: >>> >>> class javafx.scene.web.WebView { >>> /** >>> * Scale factor applied to the Web page. The scale affects logical >>> bounds >>> * of the Web page, but not bounds of the {@code WebView} node. >>> * >>> * @defaultValue 1.0 >>> */ >>> public final void setScale(double value); public final double >>> getScale(); public DoubleProperty scaleProperty(); } >>> >>> This property is different from scaleX/Y in several ways: >>> - scale is applied internally, i.e. logical bounds of the web page >>> change but WebView bounds don't; rather, scrollbars are updated. >>> Likewise in a frameset document frame bounds don't change. >>> - Scrollbars are not scaled and keep their regular size. >>> >>> Similar functionality can be found in browsers, e.g. try Ctrl+/Ctrl- >>> in Firefox. WebView currently has a similar property called >>> fontScale, but that applies to text elements only. >>> >>> http://javafx-jira.kenai.com/browse/RT-21499 >>> >>> Thanks! > From martin.desruisseaux at geomatys.fr Fri Jul 20 17:52:18 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Sat, 21 Jul 2012 02:52:18 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5009F187.4030002@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> Message-ID: <5009FD42.6080200@geomatys.fr> Hello Jim No worry, I don't think that anyone felt sent off. I think that peoples know that emails can give all kind of impression not always accurate. I wasn't aware that a concept of transformation chains could be associated to nodes. Given that this chain is in reverse order compared to the one I was familiar with, I understand the difference in interpretation of "append". I agree that consistency is important. I have no problem with any choice, but I would just like the explanation about transformation chains (in the JavaFX sense) to appear somewhere in the javadoc, for helping some developers (including myself) to do the right association in their mind. Thanks and regards, Martin Le 21/07/12 02:02, Jim Graham a ?crit : > When I wrote my first reply in this thread I tried to warn people that > I was coming back from vacation to a long thread and I hadn't double > checked all of the math that was being proposed, so I was commenting > from a general perspective that wasn't necessarily in agreement or > conflict with the current proposal at the time. I hope that I didn't > send people off on a wild goose chase based on my list of points that > may have come from a negative "we shouldn't do this or that" kind of > perspective. > > To switch things around, let me make some positive statements of > something that I would find acceptable and which I think may have > actually been formally proposed here (but I didn't "do the math" to > verify that). > > I believe that the following produce equivalent transforms: > > -------------- > Node.getTransforms().add(new Scale(sx,sy)); > Node.getTransforms().add(new Translate(tx,ty)); > --- > t = new java.awt.geom.AffineTransform(); > t.scale(sx, sy); > t.translate(tx, ty); > --- > t = new java.awt.geom.AffineTransform(); > tmp = new java.awt.geom.AffineTransform(); > tmp.setToScale(sx, sy); > t.concatenate(tmp); > tmp.setToTranslate(tx, ty); > t.concatenate(tmp); > --- > Node n...; > Group g = new Group(n); > g.setScale(sx, sy); > n.setTranslate(tx, ty); > -------------- > > We also have the fact that "preConcatenate()" is mathematically > reversed, and also inside-out from the perspective of what is being > manipluated, as compared to concatenate(). > > So, if "appendFoo(...)" was essentially equivalent to: > > - Node.getTransforms().add(new Foo(...)); > - t.foo(...); > - t.concatenate(tmp.setToFoo(...)); > > and "prependFoo(...)" was essentially equivalent to: > > - Node.getTransforms().add(0, new Foo(...)); > - we don't have a Java2D reverse for t.foo(); > - t.preConcatenate(tmp.setToFoo(...)); > > then I could be happy. It may not have complete unambiguity in an > absolute sense, but it would at least establish an internal > consistency and harmony of naming conventions with respect to the > JavaFX Node transform attributes and with the prior art in the Java > geometry family (AffineTransform)... > > I feel that append, while we can argue the semantics of what it might > mean mathematically, sounds like the more natural verb of the two > forms of methods (comparing appendFoo to prependFoo), and in general > it is the set of methods that they probably want to be using if they > come from Java2D, or if they are writing code that takes a transform > from somewhere else that defines their "transformation context" and > they want to work within that (if you prepend, then you override the > context someone set up for you, if you append, then you take their > context and work relative to it). > > Is that what was being proposed before I came in and stomped on the > discussion? > > ...jim > From kirill.prazdnikov at oracle.com Sat Jul 21 02:48:24 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Sat, 21 Jul 2012 13:48:24 +0400 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <004401cd66d4$613b7980$23b26c80$@com.au> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <004401cd66d4$613b7980$23b26c80$@com.au> Message-ID: <500A7AE8.9000607@oracle.com> Hi John, Originally, This feature is a typical browser zoom feature, like if you open a web page in InternetExplorer and use View\Zoom +\- to decrease\increase virtual screen ( and relay-out everything ) and to increase\decrease visual appearance accordingly. You may try Ctrl+"+" and Ctrl+"-" in IE. In order to achieve per coordinate zoom (X,Y) you may use Node.scaleXY properties. Thanks, -Kirill On 7/21/2012 4:04 AM, John C. Turnbull wrote: > Why not zoomX() and zoomY() for flexibility? > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair > Sent: Saturday, 21 July 2012 02:33 > To: Leonid Popov > Cc: openjfx-dev at openjdk.java.net; jfx-webnode_us_grp at oracle.com; Sergey > Malenkov > Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) > > Personally I liked zoom better. > > On Jul 20, 2012, at 9:14 AM, Leonid Popov wrote: > >> Hi Sergey, >> >> It sounds reasonable, assuming that scaleX/scaleY have slightly different > semantics (they apply to the whole view, including scrollbars, while the > proposed property should affect WebView contents only). Any other opinions > on scale vs. zoom? >> Thanks, >> Leonid >> >> On 7/20/2012 7:34 PM, Sergey Malenkov wrote: >>> Hi Leonid, >>> >>> What do you think about renaming this property to "zoom"? >>> I think that "scale" will confuse users because of Node.scaleX/scaleY. >>> Also it is a common expression for webpage scaling, for example: >>> http://windows.microsoft.com/en-us/windows-vista/Zoom-in-on-a-webpage >>> >>> Thanks, >>> SAM >>> >>> On 20.07.2012 19:23, Leonid Popov wrote: >>>> (Sorry, re-sending the same request with the correct subject, as >>>> specified by Richard) >>>> >>>> Hi, >>>> >>>> Some time ago Peter proposed an API change introducing a new >>>> property for WebView. Unfortunately, it hasn't gone to 2.2, so I (as >>>> the actual owner of this issue) am re-requesting the API change >>>> described below in the original Peter's email, now for JavaFX 3.0. >>>> >>>> Thanks, >>>> Leonid >>>> >>>> -------- Original Message -------- >>>> Subject: API Request: WebView.scale property >>>> Date: Sat, 12 May 2012 16:02:11 +0400 >>>> From: Peter Zhelezniakov >>>> To: openjfx-dev at openjdk.java.net, >>>> jfx-webnode_us_grp at oracle.com >>>> >>>> >>>> >>>> I suggest adding 'scale' property to WebView: >>>> >>>> class javafx.scene.web.WebView { >>>> /** >>>> * Scale factor applied to the Web page. The scale affects logical >>>> bounds >>>> * of the Web page, but not bounds of the {@code WebView} node. >>>> * >>>> * @defaultValue 1.0 >>>> */ >>>> public final void setScale(double value); public final double >>>> getScale(); public DoubleProperty scaleProperty(); } >>>> >>>> This property is different from scaleX/Y in several ways: >>>> - scale is applied internally, i.e. logical bounds of the web page >>>> change but WebView bounds don't; rather, scrollbars are updated. >>>> Likewise in a frameset document frame bounds don't change. >>>> - Scrollbars are not scaled and keep their regular size. >>>> >>>> Similar functionality can be found in browsers, e.g. try Ctrl+/Ctrl- >>>> in Firefox. WebView currently has a similar property called >>>> fontScale, but that applies to text elements only. >>>> >>>> http://javafx-jira.kenai.com/browse/RT-21499 >>>> >>>> Thanks! From zonski at gmail.com Sat Jul 21 15:55:54 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 22 Jul 2012 08:55:54 +1000 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> Message-ID: For those that are interested, I have put together an alternate version of the Auto Updating proposal. The installer can be found at: - http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate.msi To make things nicer, this time I have used the "JavaFX Ensemble" app as the base application. I've added a 'version bar' to the bottom of this and you can click the check for updates link on this. The newer version that gets downloaded has a red bar, just to highlight the difference in version. This implementation differs from the last in two main ways: 1. It works with the existing native installers that Igor has created 2. It assumes compile-time deltas will be used instead of runtime deltas *User Experience* As before, the user experience shown is not the one we want as the final version. I have improved on the last experience, but I would really like to do now is get a conversation going on what people see as the ideal experience. I believe the framework should provide a 'default' experience that developers can very easily hook into their application (e.g. there should be something like a CheckForUpdatesAction you can hook into your menus or button). This should be the 80% What information would you like to see about a current release and available upgrade? Visually Deltas Currently only a 'full' upgrade is used, there are no 'deltas' - with one variation on this theme: if the JRE version has not changed then the JRE does not need to be included in the upgrade. So your first install (the 'exe') will include all the JARs and the JRE (36MB) but the subsequent upgrade is a zip containing just the new JARs (8MB for Ensemble). Igor's thinking (please correct me if I misquote you Igor!) is that this approach will be the recommended norm and that deltas will be much less frequently used. Other Implementation notes Technical notes: Since Igor's native installer does not yet On Wed, Jun 20, 2012 at 11:59 AM, Daniel Zwolenski wrote: > I've uploaded a new MSI to: http://zenjava.com/demo/update/testapp.msi > > This is version 3 and it is blue. If you install and check for updates, > you will see that version 4 is available for download. If you upgrade you > will see that it's red. Note the upgrade is now quite quick as they both > use the same Java version. > > This is now all in JavaFX instead of Swing. It is a nicer UI and user > experience but it is still very raw and would need a lot of work. It should > give you more of an idea though, and, of course, if anyone wants to look at > making it nicer please let me know. > > *Note: If you have the older version you can auto update to this newer > version but because the whole point is to demonstrate the new auto-update > code, you would be better served by uninstalling, downloading the new one, > installing and then upgrading. * > > I'm hoping (perhaps optimistically) for feedback on the two proposed > approaches from the community regarding "deltas assembled at compile time" > vs "deltas determined at runtime" (where a 'delta' is the same thing as a > 'patch'). The floor is open, but if there isn't any feedback in the next > few days I will focus on just one approach - in the absence of any other > input it will likely be Igor's "deltas assembled at compile time" approach. > Speak now or forever hold your peace (or at least apologise later when you > make me change to another way). > > Just to re-cap, here are the main pros/cons of each solution: > > - with *compile-time deltas* we can assemble all the changes into one, > easy to deploy file (per delta/OS). > - with *runtime deltas* the app has to be uploaded to the server > unzipped (i.e. as it would appear on your local system) so the apps can > work out diffs on the fly > > - with *compile-time deltas* you have to create and maintain all > deltas you want to be available (e.g. v1-to-v2, v2-to-v3 and v1-to-v3). If > you don't provide a delta, the system reverts to 'full' update (i.e. > downloads everything). Currently this could mean a 50MB download (instead > of say a 4MB delta), but Igor has indicated this might be reduced > considerably. Deltas also require some extra steps at compile time to > define/detect what has changed. > - with *runtime deltas* you only maintain/upload the latest code - the > apps all work out the delta's on the fly and only download what they need > (e.g. the 4MB of jars that have changed). You do not need to create or > maintain any deltas. You do need to maintain an 'app-profile' but this > could be mostly generated (easily from Maven, I imagine ant could automate > it if you used versioned jars). > > - the single file of the *compile-time deltas* make life > easier/quicker for signing. > - with *runtime deltas* the tool has to sign every jar individually > (although tooling would hide this - and signing requirements are not yet > fully explored) > > There are likely other smaller benefits as well (Igor, did I miss any big > ones?) but these major ones are what I would be weighing up. > > There is another possible usage of *runtime deltas* that I've not brought > up before because I still can't decide if it is a positive or a negative. > With this approach the JARs don't have to come from the same URL source, so > for example you could download the third party JARs (like hibernate, > spring, etc) directly from centralised servers - and the Maven repos > provide exactly this already. This would be useful for corporate, intranet > style apps where they could maintain their own Maven repo, but for public > apps it might be a little risky? It also opens up lots of questions > regarding JAR signing, but I personally feel signing is not as necessary in > all cases as might be the current thinking (but that's probably another > debate). > > Any and all feedback on all the above will be useful for determining a > solution. > From zonski at gmail.com Sat Jul 21 17:10:44 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 22 Jul 2012 10:10:44 +1000 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> Message-ID: *Apologies for the previous, half-written email - I have a new keyboard and bumped some magic button. Here is the full version:* For those that are interested, I have put together an alternate version of the Auto Updating proposal. The installer can be found at: - http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe To make things nicer, this time I have used the "JavaFX Ensemble" app as the base application. I've added a 'version bar' to the bottom of this and you can click the check for updates link on this. The newer version that gets downloaded has a red (ugly) bar, just to highlight the difference in version. This implementation differs from the last in two main ways: 1. It works with the existing native installers that Igor has created 2. It assumes compile-time deltas will be used instead of runtime deltas Source code for everything can be found at: - http://code.google.com/p/zen-update/source/browse/trunk/ *User Experience* As before, the user experience shown is not the one we want as the final version. I have improved on the last experience, but I would really like to get a conversation going on what people see as the ideal experience. I believe the framework should provide a 'default' experience that developers can very easily plug in to their application (e.g. there should be something like a CheckForUpdatesAction you can hook into your menus or button). This should cover the 80% use case. The framework should then allow the developer to hook into it and fully customise the experience however they like. So my two main questions are: 1. what would you consider the perfect auto-updating user experience? 2. what ways would you likely want to customise this experience for more specialised scenarios? Things to consider: - How should the user be notified of new updates and then start the check for updates process (e.g. on start up, from a menu, from a status bar, from a status bar tooltip bubble)? - Would you like to see the auto-update be done in a dialog or some other mechanism (such as a panel you then embed somewhere)? - What information would you like to see about a current release and available upgrade? Visually do you have any thoughts on how this should be displayed? - What pages/steps should the auto-update wizard take the user through, what should be on each step, and how should this look visually (screen mockups would be awesome, but general comments are good too)? And of course anything else you want to comment on would be welcome. *Deltas* Currently only a 'full' upgrade is used, there are no 'deltas' - with one variation on this theme: if the JRE version has not changed then the JRE does not need to be included in the upgrade. So your first download (the 'exe') will include all the JARs and the JRE (36MB) but the subsequent upgrade is a zip containing just the new JARs (8MB for Ensemble - your app may be more or less). Igor's thinking (please correct me if I misquote you Igor!) is that this approach will be the recommended norm and that deltas will be much less frequently used. If your app is small or released infrequently then this is probably acceptable. I'd be very interested to hear people's opinion on this one - once we head down one road (and we are already heading down it) then it will get very hard to change direction. *Implementation notes * * * To add AU to the Ensemble app, I cheated and just used Ensemble as a third party jar, instantiated the UI and added it to my own Scene, with the Auto Updating status bar added to the bottom. Ideally this should be better integrated in the long run. You can see the code for this here: - http://code.google.com/p/zen-update/source/browse/trunk/ensemble-with-zen-update/ - http://code.google.com/p/zen-update/source/browse/trunk/ensemble-with-zen-update/src/com/zenjava/update/EnsembleWithZenUpdate.java The actual AU framework code can be found here: - http://code.google.com/p/zen-update/source/browse/trunk/zen-update/ - http://code.google.com/p/zen-update/source/browse/trunk/zen-update-patcher/ This time I have used ANT as the build tool instead of Maven, since most people seem to be using this, although I have used normal/plain ANT scripts, not the weird Netbeans specific ones that Netbeans seems to create. Additional comments: - This is still a windows only implementation (but technically should be easy to port to the others since Igor's done the hard work with his packagers - if any Mac or Linux developers want to volunteer I would be more than happy to talk you through what's needed - probably not a lot of work involved just some simple Objective C or C++ coding). - In general, the implementation could be used in your own app if you really wanted to (though I would highly recommend fixing up the User Experience) - with one major limitation: I currently hard-code the name of the 'exe' for the Ensemble launcher in the C++ code. This needs to be dynamic and I have been talking to Igor about ways that I could work out what this 'exe' is called from within my C++ code. - Since Igor's native installer does not yet install to 'program files', I've not bothered dealing nicely with Windows' UAC in this one. There is no code for it in this repository but it could be easily added. - As before the code is intended as a rapid, throw-away POC only, the final version will likely look considerably different at a code level (e.g. better structured, more robust, more complete). Don't get too hung up on the structure of the code at this stage, just focus on the general high-level approach of the solution. Cheers, Dan > > On Wed, Jun 20, 2012 at 11:59 AM, Daniel Zwolenski wrote: > >> I've uploaded a new MSI to: http://zenjava.com/demo/update/testapp.msi >> >> This is version 3 and it is blue. If you install and check for updates, >> you will see that version 4 is available for download. If you upgrade you >> will see that it's red. Note the upgrade is now quite quick as they both >> use the same Java version. >> >> This is now all in JavaFX instead of Swing. It is a nicer UI and user >> experience but it is still very raw and would need a lot of work. It should >> give you more of an idea though, and, of course, if anyone wants to look at >> making it nicer please let me know. >> >> *Note: If you have the older version you can auto update to this newer >> version but because the whole point is to demonstrate the new auto-update >> code, you would be better served by uninstalling, downloading the new one, >> installing and then upgrading. * >> >> I'm hoping (perhaps optimistically) for feedback on the two proposed >> approaches from the community regarding "deltas assembled at compile time" >> vs "deltas determined at runtime" (where a 'delta' is the same thing as a >> 'patch'). The floor is open, but if there isn't any feedback in the next >> few days I will focus on just one approach - in the absence of any other >> input it will likely be Igor's "deltas assembled at compile time" approach. >> Speak now or forever hold your peace (or at least apologise later when you >> make me change to another way). >> >> Just to re-cap, here are the main pros/cons of each solution: >> >> - with *compile-time deltas* we can assemble all the changes into >> one, easy to deploy file (per delta/OS). >> - with *runtime deltas* the app has to be uploaded to the server >> unzipped (i.e. as it would appear on your local system) so the apps can >> work out diffs on the fly >> >> - with *compile-time deltas* you have to create and maintain all >> deltas you want to be available (e.g. v1-to-v2, v2-to-v3 and v1-to-v3). If >> you don't provide a delta, the system reverts to 'full' update (i.e. >> downloads everything). Currently this could mean a 50MB download (instead >> of say a 4MB delta), but Igor has indicated this might be reduced >> considerably. Deltas also require some extra steps at compile time to >> define/detect what has changed. >> - with *runtime deltas* you only maintain/upload the latest code - >> the apps all work out the delta's on the fly and only download what they >> need (e.g. the 4MB of jars that have changed). You do not need to create or >> maintain any deltas. You do need to maintain an 'app-profile' but this >> could be mostly generated (easily from Maven, I imagine ant could automate >> it if you used versioned jars). >> >> - the single file of the *compile-time deltas* make life >> easier/quicker for signing. >> - with *runtime deltas* the tool has to sign every jar individually >> (although tooling would hide this - and signing requirements are not yet >> fully explored) >> >> There are likely other smaller benefits as well (Igor, did I miss any big >> ones?) but these major ones are what I would be weighing up. >> >> There is another possible usage of *runtime deltas* that I've not >> brought up before because I still can't decide if it is a positive or a >> negative. With this approach the JARs don't have to come from the same URL >> source, so for example you could download the third party JARs (like >> hibernate, spring, etc) directly from centralised servers - and the Maven >> repos provide exactly this already. This would be useful for corporate, >> intranet style apps where they could maintain their own Maven repo, but for >> public apps it might be a little risky? It also opens up lots of questions >> regarding JAR signing, but I personally feel signing is not as necessary in >> all cases as might be the current thinking (but that's probably another >> debate). >> >> Any and all feedback on all the above will be useful for determining a >> solution. >> > > From jmartine_1026 at yahoo.com Sat Jul 21 21:00:38 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Sat, 21 Jul 2012 21:00:38 -0700 (PDT) Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> Message-ID: <1342929638.55082.YahooMailNeo@web160904.mail.bf1.yahoo.com> Dan, The?Ensemble?example looks pretty good. ?Nice work. > ?- How should the user be notified of new updates and then start the ? check for updates process (e.g. on start up, from a menu, from a status ? bar, from a status bar tooltip bubble)? Right from the main title screen they would see that an upgrade is available and given the option to upgrade now. ?This mimics some of my favorite apps. > ?- Would you like to see the auto-update be done in a dialog or some ? other mechanism (such as a panel you then embed somewhere)? I like how your example did it.... the current app shuts down and the installation for the upgrade starts. ?This seems like a reasonable default. > ?- What information would you like to see about a current release and ? available upgrade? Visually do you have any thoughts on how this should be ? displayed? Release notes. ?I am used to how IOS does it, a user can see the list of changes before they upgrade an app. ?So when a user is told that an upgrade is available they would see 1) the version number of the new release, 2) a link to see the changes (via pop-up), this should cover all releases between current and latest 3) upgrade now link. ?Extra credit: option to upgrade to an?intermediary?version.... i do not know how popular this would be, I know for some apps in the past I had to hunt down version?in between?currently-installed and latest. > ?- What pages/steps should the auto-update wizard take the user through, ? what should be on each step, and how should this look visually (screen ? mockups would be awesome, but general comments are good too)?? The Ensemble example's pages/steps looked good to me... a simple progress indicator. ?Simple and clean with no questions or input needed from the user. >?? 2. what ways would you likely want to customise this experience for more? specialised scenarios? When a user purchases a license for my app they will be allowed to download future updates up to a certain point ?So if they have a very old license then they can't upgrade to latest. ?Do not know if this is something you want to build into the framework, but it at least must be implementable. ?If the user chooses to buy a new license to upgrade, would be cool if they just enter the new license and then they get to upgrade. ?So I guess I'm saying license based upgrade would be cool or at least not blocked by the framework. On a?separate?topic...?how did you implement your details popup? ?I notice how it displayed outside of your main window and how it would remain within my desktop's borders. ? jose ________________________________ From: Daniel Zwolenski To: openjfx-dev at openjdk.java.net Sent: Saturday, July 21, 2012 8:10 PM Subject: Re: Auto-update of native application bundles *Apologies for the previous, half-written email - I have a new keyboard and bumped some magic button. Here is the full version:* For those that are interested, I have put together an alternate version of the Auto Updating proposal. The installer can be found at: ? - http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe To make things nicer, this time I have used the "JavaFX Ensemble" app as the base application. I've added a 'version bar' to the bottom of this and you can click the check for updates link on this. The newer version that gets downloaded has a red (ugly) bar, just to highlight the difference in version. This implementation differs from the last in two main ways: ? 1. It works with the existing native installers that Igor has created ? 2. It assumes compile-time deltas will be used instead of runtime deltas Source code for everything can be found at: ? - http://code.google.com/p/zen-update/source/browse/trunk/ *User Experience* As before, the user experience shown is not the one we want as the final version. I have improved on the last experience, but I would really like to get a conversation going on what people see as the ideal experience. I believe the framework should provide a 'default' experience that developers can very easily plug in to their application (e.g. there should be something like a CheckForUpdatesAction you can hook into your menus or button). This should cover the 80% use case. The framework should then allow the developer to hook into it and fully customise the experience however they like. So my two main questions are: ? 1. what would you consider the perfect auto-updating user experience? ? 2. what ways would you likely want to customise this experience for more ? specialised scenarios? Things to consider: ? - How should the user be notified of new updates and then start the ? check for updates process (e.g. on start up, from a menu, from a status ? bar, from a status bar tooltip bubble)? ? - Would you like to see the auto-update be done in a dialog or some ? other mechanism (such as a panel you then embed somewhere)? ? - What information would you like to see about a current release and ? available upgrade? Visually do you have any thoughts on how this should be ? displayed? ? - What pages/steps should the auto-update wizard take the user through, ? what should be on each step, and how should this look visually (screen ? mockups would be awesome, but general comments are good too)? And of course anything else you want to comment on would be welcome. *Deltas* Currently only a 'full' upgrade is used, there are no 'deltas' - with one variation on this theme: if the JRE version has not changed then the JRE does not need to be included in the upgrade. So your first download (the 'exe') will include all the JARs and the JRE (36MB) but the subsequent upgrade is a zip containing just the new JARs (8MB for Ensemble - your app may be more or less). Igor's thinking (please correct me if I misquote you Igor!) is that this approach will be the recommended norm and that deltas will be much less frequently used. If your app is small or released infrequently then this is probably acceptable. I'd be very interested to hear people's opinion on this one - once we head down one road (and we are already heading down it) then it will get very hard to change direction. *Implementation notes * * * To add AU to the Ensemble app, I cheated and just used Ensemble as a third party jar, instantiated the UI and added it to my own Scene, with the Auto Updating status bar added to the bottom. Ideally this should be better integrated in the long run. You can see the code for this here: ? - ? http://code.google.com/p/zen-update/source/browse/trunk/ensemble-with-zen-update/ ? - ? http://code.google.com/p/zen-update/source/browse/trunk/ensemble-with-zen-update/src/com/zenjava/update/EnsembleWithZenUpdate.java The actual AU framework code can be found here: ? - http://code.google.com/p/zen-update/source/browse/trunk/zen-update/ ? - ? http://code.google.com/p/zen-update/source/browse/trunk/zen-update-patcher/ This time I have used ANT as the build tool instead of Maven, since most people seem to be using this, although I have used normal/plain ANT scripts, not the weird Netbeans specific ones that Netbeans seems to create. Additional comments: ? - This is still a windows only implementation (but technically should be ? easy to port to the others since Igor's done the hard work with his ? packagers - if any Mac or Linux developers want to volunteer I would be ? more than happy to talk you through what's needed - probably not a lot of ? work involved just some simple Objective C or C++ coding). ? - In general, the implementation could be used in your own app if you ? really wanted to (though I would highly recommend fixing up the User ? Experience) - with one major limitation: I currently hard-code the name of ? the 'exe' for the Ensemble launcher in the C++ code. This needs to be ? dynamic and I have been talking to Igor about ways that I could work out ? what this 'exe' is called from within my C++ code. ? - Since Igor's native installer does not yet install to 'program files', ? I've not bothered dealing? nicely with Windows' UAC in this one. There is ? no code for it in this repository but it could be easily added. ? - As before the code is intended as a rapid, throw-away POC only, the ? final version will likely look considerably different at a code level ? (e.g. better structured, more robust, more complete). Don't get too hung up ? on the structure of the code at this stage, just focus on the general ? high-level approach of the solution. Cheers, Dan > > On Wed, Jun 20, 2012 at 11:59 AM, Daniel Zwolenski wrote: > >> I've uploaded a new MSI to: http://zenjava.com/demo/update/testapp.msi >> >> This is version 3 and it is blue. If you install and check for updates, >> you will see that version 4 is available for download. If you upgrade you >> will see that it's red. Note the upgrade is now quite quick as they both >> use the same Java version. >> >> This is now all in JavaFX instead of Swing. It is a nicer UI and user >> experience but it is still very raw and would need a lot of work. It should >> give you more of an idea though, and, of course, if anyone wants to look at >> making it nicer please let me know. >> >> *Note: If you have the older version you can auto update to this newer >> version but because the whole point is to demonstrate the new auto-update >> code, you would be better served by uninstalling, downloading the new one, >> installing and then upgrading. * >> >> I'm hoping (perhaps optimistically) for feedback on the two proposed >> approaches from the community regarding "deltas assembled at compile time" >> vs "deltas determined at runtime" (where a 'delta' is the same thing as a >> 'patch'). The floor is open, but if there isn't any feedback in the next >> few days I will focus on just one approach - in the absence of any other >> input it will likely be Igor's "deltas assembled at compile time" approach. >> Speak now or forever hold your peace (or at least apologise later when you >> make me change to another way). >> >> Just to re-cap, here are the main pros/cons of each solution: >> >>? ? - with *compile-time deltas* we can assemble all the changes into >>? ? one, easy to deploy file (per delta/OS). >>? ? - with *runtime deltas* the app has to be uploaded to the server >>? ? unzipped (i.e. as it would appear on your local system) so the apps can >>? ? work out diffs on the fly >> >>? ? - with *compile-time deltas* you have to create and maintain all >>? ? deltas you want to be available (e.g. v1-to-v2, v2-to-v3 and v1-to-v3). If >>? ? you don't provide a delta, the system reverts to 'full' update (i.e. >>? ? downloads everything). Currently this could mean a 50MB download (instead >>? ? of say a 4MB delta), but Igor has indicated this might be reduced >>? ? considerably. Deltas also require some extra steps at compile time to >>? ? define/detect what has changed. >>? ? - with *runtime deltas* you only maintain/upload the latest code - >>? ? the apps all work out the delta's on the fly and only download what they >>? ? need (e.g. the 4MB of jars that have changed). You do not need to create or >>? ? maintain any deltas. You do need to maintain an 'app-profile' but this >>? ? could be mostly generated (easily from Maven, I imagine ant could automate >>? ? it if you used versioned jars). >> >>? ? - the single file of the *compile-time deltas* make life >>? ? easier/quicker for signing. >>? ? - with *runtime deltas* the tool has to sign every jar individually >>? ? (although tooling would hide this - and signing requirements are not yet >>? ? fully explored) >> >> There are likely other smaller benefits as well (Igor, did I miss any big >> ones?) but these major ones are what I would be weighing up. >> >> There is another possible usage of *runtime deltas* that I've not >> brought up before because I still can't decide if it is a positive or a >> negative. With this approach the JARs don't have to come from the same URL >> source, so for example you could download the third party JARs (like >> hibernate, spring, etc) directly from centralised servers - and the Maven >> repos provide exactly this already. This would be useful for corporate, >> intranet style apps where they could maintain their own Maven repo, but for >> public apps it might be a little risky? It also opens up lots of questions >> regarding JAR signing, but I personally feel signing is not as necessary in >> all cases as might be the current thinking (but that's probably another >> debate). >> >> Any and all feedback on all the above will be useful for determining a >> solution. >> > > From igor.nekrestyanov at oracle.com Sat Jul 21 21:36:46 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Sat, 21 Jul 2012 21:36:46 -0700 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> Message-ID: <500B835E.3060708@oracle.com> Hi Dan, thanks for pushing this effort! On 7/21/12 5:10 PM, Daniel Zwolenski wrote: > *Deltas* > > Currently only a 'full' upgrade is used, there are no 'deltas' - with one > variation on this theme: if the JRE version has not changed then the JRE > does not need to be included in the upgrade. So your first download (the > 'exe') will include all the JARs and the JRE (36MB) but the subsequent > upgrade is a zip containing just the new JARs (8MB for Ensemble - your app > may be more or less). > > Igor's thinking (please correct me if I misquote you Igor!) is that this > approach will be the recommended norm and that deltas will be much less > frequently used. > If your app is small or released infrequently then this is > probably acceptable. I'd be very interested to hear people's opinion on > this one - once we head down one road (and we are already heading down it) > then it will get very hard to change direction. We could support delta's. I do not see big technical problems with "applying delta patch". The complicated part is how developer will prepare static delta. One option is to keep image of previous version and provide it as base for delta generation. Another simple alternative (variation of app only) is to provide list of files to be included into update. Then these files will be included (as full file) into update and older versions of these files will be replaced. Other files will not be included into update and will be left intact. > > - Since Igor's native installer does not yet install to 'program files', Actually, recent versions of javafx ant tasks support system wide installation. System wide installs are default for .msi/.dmg/.rpm/.deb. User level installation is default for .exe. For .exe/.msi/.dmg you can chose whether you want system level or user level install using "install" attribute of fx:preferences. For example following will request bundle with system level installation and this will request user level: Hopefully soon we will have better docs available for what is possible with current implementation, -igor From zonski at gmail.com Sun Jul 22 02:09:35 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 22 Jul 2012 19:09:35 +1000 Subject: Auto-update of native application bundles In-Reply-To: <1342929638.55082.YahooMailNeo@web160904.mail.bf1.yahoo.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> <1342929638.55082.YahooMailNeo@web160904.mail.bf1.yahoo.com> Message-ID: Thanks Jose for you feedback - much appreciated. One topic I forgot to mention in the previous email - currently there is no signing and validation of the download. It assumes the URL you reference for AU is trustworthy and if you download something from that you are getting what you asked for and therefore it's ok to run that code. I tend to feel this is ok but I am generally on the relaxed end in this area. My logic is there's no guarantee the original install was not a hack/nasty, so why complicate the later downloads by trying to guarantee they are from the same source. What do people think about this, what do we need to make things "safe" and if we do add security and jar signing should this be mandatory or optional? I, for one, would prefer not to complicate my build for an app that is only going to be installed/used on an intranet and VPN and therefore is probably safe enough without signing. Right from the main title screen they would see that an upgrade is > available and given the option to upgrade now. This mimics some of my > favorite apps. > Can you elaborate on what you mean by the 'main title screen'? I'm guessing you are saying that a popup should be shown on startup if an upgrade is available but please let me know if I misunderstood. > Release notes. I am used to how IOS does it, a user can see the list of > changes before they upgrade an app. > Good to know. I left out release notes as I was not sure exactly how people would want to use them. Adding it to the pre-install step makes sense. > this should cover all releases between current and latest > A simple solution would be just to link to a webpage and the developer is responsible for maintaining this page. This would allow you to completely style and manage this page as you want (e.g. something like http://www.jetbrains.com/idea/whatsnew/index.html). Trying to record and derive individual release details and merge them would complicate the build process quite a lot I imagine and in some cases may not make sense. I'd be interested to hear more on how people would use this feature and what would work best for them. I'd also be interested to know about Terms & Conditions pages - do people need this, should it be shown before the upgrade (seems logical), and does there need to be some record of the T&C acceptance legally, or is it generally enough that they can;t get past that page without clicking 'accept'? Extra credit: option to upgrade to an intermediary version.... i do not > know how popular this would be, I know for some apps in the past I had to > hunt down version in between currently-installed and latest. > Good use case to know about but I'm thinking this would not be part of the default work-flow. It adds complexity to a lot of levels that I'm not sure would be totally worth it. We definitely should make the underlying framework customisable enough however that this could be implemented by the developer. Happy to hear more thoughts on this one, and if the base framework allows for it (which it will) then it could always be added in a later version. > 2. what ways would you likely want to customise this experience for more > specialised scenarios? > > When a user purchases a license for my app they will be allowed to > download future updates up to a certain point So if they have a very old > license then they can't upgrade to latest. Do not know if this is > something you want to build into the framework, but it at least must be > implementable. If the user chooses to buy a new license to upgrade, > would be cool if they just enter the new license and then they get to > upgrade. So I guess I'm saying license based upgrade would be cool or at > least not blocked by the framework. > This is a good point. I definitely think the base framework should/will allow for this to be implemented on top of what comes by default. Thinking about it there is really an enhanced process that is common for most paid-for applications as opposed to your standard freebie or back-office application. Not sure this should be part of the core library, but perhaps - Igor and Richard might have some ideas on this as we get further along. A way for developers to easily licence/charge for their apps may well encourage more developers (as seen by the iOS app store). Perhaps though, this payment based AU system would be a nice open source project that extends the base functionality. It could then make use of third party licence, ssl, hashing and payment-gateway libraries to implement some powerful stuff on this. For example, I don't see any technical reason why someone keen couldn't build their own 'pay now' screen as part of the upgrade wizard and hook this into a payment provider (such as PayPal). That would be pretty sweet. > On a separate topic... how did you implement your details popup? I > notice how it displayed outside of your main window and how it would remain > within my desktop's borders. > I just borrowed the old lightbox concept from web land (see http://gettopup.com/) Basically, instead of adding the root of the scene directly to the Scene, I create a StackPane to wrapper it. When the "popup" is shown it is added to the top layer of this stackpane and so covers everything underneath. I use a semi-transparent pane to contain the popup and it is this semi-transparent pane that greys out the underlying scene and blocks mouse input, etc. All pretty basic stuff. I've used these a lot instead of dialogs, they have the advantage that they can be animated in/out and can be any shape, etc. They have the disadvantage that they can't really be application modal if you have multiple top-level windows (i.e. scenes) and I don't know how well they would block keyboard input such as shortcut keys. I've thought about open sourcing the code for this (it's very simple) but never gotten round to it. If you are interested let me know. > *From:* Daniel Zwolenski > *To:* openjfx-dev at openjdk.java.net > *Sent:* Saturday, July 21, 2012 8:10 PM > > *Subject:* Re: Auto-update of native application bundles > > *Apologies for the previous, half-written email - I have a new keyboard and > bumped some magic button. Here is the full version:* > > > For those that are interested, I have put together an alternate version of > the Auto Updating proposal. > > The installer can be found at: > > - http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe > > > To make things nicer, this time I have used the "JavaFX Ensemble" app as > the base application. I've added a 'version bar' to the bottom of this and > you can click the check for updates link on this. The newer version that > gets downloaded has a red (ugly) bar, just to highlight the difference in > version. > > This implementation differs from the last in two main ways: > > 1. It works with the existing native installers that Igor has created > 2. It assumes compile-time deltas will be used instead of runtime deltas > > > > Source code for everything can be found at: > > - http://code.google.com/p/zen-update/source/browse/trunk/ > > > *User Experience* > > > As before, the user experience shown is not the one we want as the final > version. I have improved on the last experience, but I would really like to > get a conversation going on what people see as the ideal experience. > > I believe the framework should provide a 'default' experience that > developers can very easily plug in to their application (e.g. there should > be something like a CheckForUpdatesAction you can hook into your menus or > button). This should cover the 80% use case. The framework should then > allow the developer to hook into it and fully customise the experience > however they like. > > So my two main questions are: > > 1. what would you consider the perfect auto-updating user experience? > 2. what ways would you likely want to customise this experience for more > > specialised scenarios? > > Things to consider: > > - How should the user be notified of new updates and then start the > > check for updates process (e.g. on start up, from a menu, from a status > bar, from a status bar tooltip bubble)? > - Would you like to see the auto-update be done in a dialog or some > > other mechanism (such as a panel you then embed somewhere)? > - What information would you like to see about a current release and > > available upgrade? Visually do you have any thoughts on how this should > be > displayed? > - What pages/steps should the auto-update wizard take the user through, > > what should be on each step, and how should this look visually (screen > mockups would be awesome, but general comments are good too)? > > And of course anything else you want to comment on would be welcome. > > *Deltas* > > > Currently only a 'full' upgrade is used, there are no 'deltas' - with one > variation on this theme: if the JRE version has not changed then the JRE > does not need to be included in the upgrade. So your first download (the > 'exe') will include all the JARs and the JRE (36MB) but the subsequent > upgrade is a zip containing just the new JARs (8MB for Ensemble - your app > may be more or less). > > Igor's thinking (please correct me if I misquote you Igor!) is that this > approach will be the recommended norm and that deltas will be much less > frequently used. If your app is small or released infrequently then this is > probably acceptable. I'd be very interested to hear people's opinion on > this one - once we head down one road (and we are already heading down it) > then it will get very hard to change direction. > > *Implementation notes * > * > * > > To add AU to the Ensemble app, I cheated and just used Ensemble as a third > party jar, instantiated the UI and added it to my own Scene, with the Auto > Updating status bar added to the bottom. Ideally this should be better > integrated in the long run. > > You can see the code for this here: > > - > > http://code.google.com/p/zen-update/source/browse/trunk/ensemble-with-zen-update/ > > - > > http://code.google.com/p/zen-update/source/browse/trunk/ensemble-with-zen-update/src/com/zenjava/update/EnsembleWithZenUpdate.java > > The actual AU framework code can be found here: > > - http://code.google.com/p/zen-update/source/browse/trunk/zen-update/ > > - > > http://code.google.com/p/zen-update/source/browse/trunk/zen-update-patcher/ > > This time I have used ANT as the build tool instead of Maven, since most > people seem to be using this, although I have used normal/plain ANT > scripts, not the weird Netbeans specific ones that Netbeans seems to > create. > > Additional comments: > > - This is still a windows only implementation (but technically should be > > easy to port to the others since Igor's done the hard work with his > packagers - if any Mac or Linux developers want to volunteer I would be > more than happy to talk you through what's needed - probably not a lot of > work involved just some simple Objective C or C++ coding). > > - In general, the implementation could be used in your own app if you > > really wanted to (though I would highly recommend fixing up the User > Experience) - with one major limitation: I currently hard-code the name > of > the 'exe' for the Ensemble launcher in the C++ code. This needs to be > dynamic and I have been talking to Igor about ways that I could work out > what this 'exe' is called from within my C++ code. > > - Since Igor's native installer does not yet install to 'program files', > > I've not bothered dealing nicely with Windows' UAC in this one. There is > no code for it in this repository but it could be easily added. > > - As before the code is intended as a rapid, throw-away POC only, the > > final version will likely look considerably different at a code level > (e.g. better structured, more robust, more complete). Don't get too hung > up > on the structure of the code at this stage, just focus on the general > high-level approach of the solution. > > Cheers, > Dan > > > > > > > On Wed, Jun 20, 2012 at 11:59 AM, Daniel Zwolenski < > zonski at googlemail.com>wrote: > > > >> I've uploaded a new MSI to: http://zenjava.com/demo/update/testapp.msi > >> > >> This is version 3 and it is blue. If you install and check for updates, > >> you will see that version 4 is available for download. If you upgrade > you > >> will see that it's red. Note the upgrade is now quite quick as they both > >> use the same Java version. > >> > >> This is now all in JavaFX instead of Swing. It is a nicer UI and user > >> experience but it is still very raw and would need a lot of work. It > should > >> give you more of an idea though, and, of course, if anyone wants to > look at > >> making it nicer please let me know. > >> > >> *Note: If you have the older version you can auto update to this newer > > >> version but because the whole point is to demonstrate the new > auto-update > >> code, you would be better served by uninstalling, downloading the new > one, > >> installing and then upgrading. * > > >> > >> I'm hoping (perhaps optimistically) for feedback on the two proposed > >> approaches from the community regarding "deltas assembled at compile > time" > >> vs "deltas determined at runtime" (where a 'delta' is the same thing as > a > >> 'patch'). The floor is open, but if there isn't any feedback in the next > >> few days I will focus on just one approach - in the absence of any other > >> input it will likely be Igor's "deltas assembled at compile time" > approach. > >> Speak now or forever hold your peace (or at least apologise later when > you > >> make me change to another way). > >> > >> Just to re-cap, here are the main pros/cons of each solution: > >> > >> - with *compile-time deltas* we can assemble all the changes into > > >> one, easy to deploy file (per delta/OS). > >> - with *runtime deltas* the app has to be uploaded to the server > > >> unzipped (i.e. as it would appear on your local system) so the apps > can > >> work out diffs on the fly > >> > >> - with *compile-time deltas* you have to create and maintain all > > >> deltas you want to be available (e.g. v1-to-v2, v2-to-v3 and > v1-to-v3). If > >> you don't provide a delta, the system reverts to 'full' update (i.e. > >> downloads everything). Currently this could mean a 50MB download > (instead > >> of say a 4MB delta), but Igor has indicated this might be reduced > >> considerably. Deltas also require some extra steps at compile time to > >> define/detect what has changed. > >> - with *runtime deltas* you only maintain/upload the latest code - > > >> the apps all work out the delta's on the fly and only download what > they > >> need (e.g. the 4MB of jars that have changed). You do not need to > create or > >> maintain any deltas. You do need to maintain an 'app-profile' but > this > >> could be mostly generated (easily from Maven, I imagine ant could > automate > >> it if you used versioned jars). > >> > >> - the single file of the *compile-time deltas* make life > >> easier/quicker for signing. > >> - with *runtime deltas* the tool has to sign every jar individually > > >> (although tooling would hide this - and signing requirements are not > yet > >> fully explored) > >> > >> There are likely other smaller benefits as well (Igor, did I miss any > big > >> ones?) but these major ones are what I would be weighing up. > >> > >> There is another possible usage of *runtime deltas* that I've not > > >> brought up before because I still can't decide if it is a positive or a > >> negative. With this approach the JARs don't have to come from the same > URL > >> source, so for example you could download the third party JARs (like > >> hibernate, spring, etc) directly from centralised servers - and the > Maven > >> repos provide exactly this already. This would be useful for corporate, > >> intranet style apps where they could maintain their own Maven repo, but > for > >> public apps it might be a little risky? It also opens up lots of > questions > >> regarding JAR signing, but I personally feel signing is not as > necessary in > >> all cases as might be the current thinking (but that's probably another > >> debate). > >> > >> Any and all feedback on all the above will be useful for determining a > >> solution. > >> > > > > > > > From zonski at gmail.com Sun Jul 22 03:59:02 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 22 Jul 2012 20:59:02 +1000 Subject: Java Inventor: JavaFX for Mortals In-Reply-To: <185E8C47-4A3C-40CF-9F3A-4670A86F2E19@reportmill.com> References: <4FFDAD1C.2010501@oracle.com> <346B1216-DDF9-40DF-9D42-6DE2AD5F72F0@reportmill.com> <185E8C47-4A3C-40CF-9F3A-4670A86F2E19@reportmill.com> Message-ID: Hey Jeff, I don't think anyone else has replied on this so I thought I would just jump in and say: very impressive! You've sure covered a lot of ground there. I especially like the publish to Google App Engine feature - nice touch. I'll be interested to see what kind of uptake you get on this. Dan On Wed, Jul 18, 2012 at 1:43 AM, Jeff Martin wrote: > Links were stripped out: > > Java Inventor Gallery: http://www.reportmill.com/javi/gallery > > and > > JFX Flow: http://www.zenjava.com/jfx-flow > Dex: http://www.javainc.com/projects/dex/Dex.html > > > On Jul 17, 2012, at 10:33 AM, Jeff Martin wrote: > > > It seems this forum has been open to technology previews before, like > the very cool JFX Flow and Dex. So in that vein, I hope it's okay to point > this group to another. > > > > Java Inventor is a free IDE for education to make Java and JavaFX > available to a broader audience. I'm thrilled with JavaFX - it's a > sophisticated framework for sophisticated developers. Javi (for short) is > an app builder and framework that lets anyone build and deploy rich > internet database apps in minutes without having to spend years learning > dozens of software, server and internet technologies. It's a true all in > one: project manager, graphics designer, UI builder, database builder, code > editor, media editor, report builder, ORM, app server, DB server, group > source code server and more. > > > > Please check out the example gallery. The first four items show video > creating a JavaFX UI on a data table for contact entry/update/search with > report generation and internet deployment to Google App Engine - All in 10 > minutes or less! I hope Javi can help JavaFX reach millions of people > beyond sophisticated developers: students, hobbyists, business managers, > graphics designers and more. Let me know (on or offline) if you have any > feedback. > > > > Jeff Martin > > 214.513.1636 > > From jeff at reportmill.com Sun Jul 22 09:18:11 2012 From: jeff at reportmill.com (Jeff Martin) Date: Sun, 22 Jul 2012 11:18:11 -0500 Subject: Java Inventor: JavaFX for Mortals In-Reply-To: References: <4FFDAD1C.2010501@oracle.com> <346B1216-DDF9-40DF-9D42-6DE2AD5F72F0@reportmill.com> <185E8C47-4A3C-40CF-9F3A-4670A86F2E19@reportmill.com> Message-ID: <27BCF952-7911-4A1E-8547-42854550C718@reportmill.com> Thanks, Dan! I keep thinking this is the best way to get a huge audience to take JavaFX for a spin. Since I'm laboring away in obscurity, the kind words help immensely (and I know we share similar visions :-). If the average developer requires months of learning to appreciate JavaFX the way we do, we may not have enough runway to get off the ground. At NeXT (anyone remember it?), the ability to create an instant runnable prototype with Interface Builder was one of our most redeeming accomplishments (the other, of course, being Mac OS X :-). Javi with JavaFX takes it to a whole new level. jeff On Jul 22, 2012, at 5:59 AM, Daniel Zwolenski wrote: > Hey Jeff, > > I don't think anyone else has replied on this so I thought I would just jump in and say: very impressive! > > You've sure covered a lot of ground there. I especially like the publish to Google App Engine feature - nice touch. > > I'll be interested to see what kind of uptake you get on this. > > Dan > > > On Wed, Jul 18, 2012 at 1:43 AM, Jeff Martin wrote: > Links were stripped out: > > Java Inventor Gallery: http://www.reportmill.com/javi/gallery > > and > > JFX Flow: http://www.zenjava.com/jfx-flow > Dex: http://www.javainc.com/projects/dex/Dex.html > > > On Jul 17, 2012, at 10:33 AM, Jeff Martin wrote: > > > It seems this forum has been open to technology previews before, like the very cool JFX Flow and Dex. So in that vein, I hope it's okay to point this group to another. > > > > Java Inventor is a free IDE for education to make Java and JavaFX available to a broader audience. I'm thrilled with JavaFX - it's a sophisticated framework for sophisticated developers. Javi (for short) is an app builder and framework that lets anyone build and deploy rich internet database apps in minutes without having to spend years learning dozens of software, server and internet technologies. It's a true all in one: project manager, graphics designer, UI builder, database builder, code editor, media editor, report builder, ORM, app server, DB server, group source code server and more. > > > > Please check out the example gallery. The first four items show video creating a JavaFX UI on a data table for contact entry/update/search with report generation and internet deployment to Google App Engine - All in 10 minutes or less! I hope Javi can help JavaFX reach millions of people beyond sophisticated developers: students, hobbyists, business managers, graphics designers and more. Let me know (on or offline) if you have any feedback. > > > > Jeff Martin > > 214.513.1636 From pavel.safrata at oracle.com Mon Jul 23 02:11:56 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 23 Jul 2012 11:11:56 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <5009FD42.6080200@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> Message-ID: <500D155C.3000906@oracle.com> Hello, looks like we reached the agreement on a (well documented) append/prepend terminology with the original proposal semantics reversed. Before I post the final proposal, following changes need to be discussed: We need to add manual transformation methods to Transfrom class. This is very important, I can't believe I've forgotten them.. public Point3D transform(Point3D point) public Bounds transform(Bounds bounds) Any other? Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, MAT_3D_3x4, MAT_3D_4x4, do you agree? Keep the methods accepting arrays recognizing their types according to their length and add public Affine(double[] array, MatrixArrayType type, int beginIndex) public void setToTransform(double[] array, MatrixArrayType type, int beginIndex) public void append(double[] array, MatrixArrayType type, int beginIndex) public void prepend(double[] array, MatrixArrayType type, int beginIndex) Do you agree? Or would you prefer different set of array-accepting methods? Regarding the getRow/getColumn: we again face the problem whether to return 3 or 4 elements. Consistently with the toArray, I propose VectorArrayType = { VAT_2D, VAT_3D } public double[] getRow(int row, VectorArrayType type), public double[] getRow(int row, VectorArrayType type, double[] array) public double[] getColumn(int col, VectorArrayType type), public double[] getColumn(int col, VectorArrayType type, double[] array) Do you agree? Thanks, Pavel On 21.7.2012 2:52, Martin Desruisseaux wrote: > Hello Jim > > No worry, I don't think that anyone felt sent off. I think that > peoples know that emails can give all kind of impression not always > accurate. > > I wasn't aware that a concept of transformation chains could be > associated to nodes. Given that this chain is in reverse order > compared to the one I was familiar with, I understand the difference > in interpretation of "append". I agree that consistency is important. > I have no problem with any choice, but I would just like the > explanation about transformation chains (in the JavaFX sense) to > appear somewhere in the javadoc, for helping some developers > (including myself) to do the right association in their mind. > > Thanks and regards, > > Martin > > > > Le 21/07/12 02:02, Jim Graham a ?crit : >> When I wrote my first reply in this thread I tried to warn people >> that I was coming back from vacation to a long thread and I hadn't >> double checked all of the math that was being proposed, so I was >> commenting from a general perspective that wasn't necessarily in >> agreement or conflict with the current proposal at the time. I hope >> that I didn't send people off on a wild goose chase based on my list >> of points that may have come from a negative "we shouldn't do this or >> that" kind of perspective. >> >> To switch things around, let me make some positive statements of >> something that I would find acceptable and which I think may have >> actually been formally proposed here (but I didn't "do the math" to >> verify that). >> >> I believe that the following produce equivalent transforms: >> >> -------------- >> Node.getTransforms().add(new Scale(sx,sy)); >> Node.getTransforms().add(new Translate(tx,ty)); >> --- >> t = new java.awt.geom.AffineTransform(); >> t.scale(sx, sy); >> t.translate(tx, ty); >> --- >> t = new java.awt.geom.AffineTransform(); >> tmp = new java.awt.geom.AffineTransform(); >> tmp.setToScale(sx, sy); >> t.concatenate(tmp); >> tmp.setToTranslate(tx, ty); >> t.concatenate(tmp); >> --- >> Node n...; >> Group g = new Group(n); >> g.setScale(sx, sy); >> n.setTranslate(tx, ty); >> -------------- >> >> We also have the fact that "preConcatenate()" is mathematically >> reversed, and also inside-out from the perspective of what is being >> manipluated, as compared to concatenate(). >> >> So, if "appendFoo(...)" was essentially equivalent to: >> >> - Node.getTransforms().add(new Foo(...)); >> - t.foo(...); >> - t.concatenate(tmp.setToFoo(...)); >> >> and "prependFoo(...)" was essentially equivalent to: >> >> - Node.getTransforms().add(0, new Foo(...)); >> - we don't have a Java2D reverse for t.foo(); >> - t.preConcatenate(tmp.setToFoo(...)); >> >> then I could be happy. It may not have complete unambiguity in an >> absolute sense, but it would at least establish an internal >> consistency and harmony of naming conventions with respect to the >> JavaFX Node transform attributes and with the prior art in the Java >> geometry family (AffineTransform)... >> >> I feel that append, while we can argue the semantics of what it might >> mean mathematically, sounds like the more natural verb of the two >> forms of methods (comparing appendFoo to prependFoo), and in general >> it is the set of methods that they probably want to be using if they >> come from Java2D, or if they are writing code that takes a transform >> from somewhere else that defines their "transformation context" and >> they want to work within that (if you prepend, then you override the >> context someone set up for you, if you append, then you take their >> context and work relative to it). >> >> Is that what was being proposed before I came in and stomped on the >> discussion? >> >> ...jim >> > From pavel.safrata at oracle.com Mon Jul 23 02:18:37 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 23 Jul 2012 11:18:37 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: References: Message-ID: <500D16ED.9050409@oracle.com> Hello, currently there is no API for this. It is planned for the 3.0 release (together with other matrix algebra operations - thanks for reminding me by the way). So right now you unfortunately need to do the math yourself. Regards, Pavel P.S. I didn't tell you this but as a temporary workaround you can use an undocumented internal (but publicly accessible) method impl_transform(Point3D). Please note that this method will be removed in the next version (with the addition of the proper public methods). On 21.7.2012 0:02, Pedro Duque Vieira wrote: > Hi, > > I need to transform a point using the localToSceneTransform of a node, > however I don't see any method on Transform class to accomplish this. > Is there an easy way or do I have to do the math myself? > > Thanks, best regards, > From Peter.Zhelezniakov at oracle.com Mon Jul 23 02:21:08 2012 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Mon, 23 Jul 2012 13:21:08 +0400 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <500983DD.2040407@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> Message-ID: <500D1784.2060105@oracle.com> On 07/20/12 20:14, Leonid Popov wrote: > It sounds reasonable, assuming that scaleX/scaleY have slightly > different semantics (they apply to the whole view, including scrollbars, > while the proposed property should affect WebView contents only). Any > other opinions on scale vs. zoom? I named it scaleProperty for consistency as we already had fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive than 'scale'. I don't have strong preference now. Should we name it just zoomProperty, or maybe zoomFactorProperty? Native speakers please advise! Thanks! -- Peter From Peter.Zhelezniakov at oracle.com Mon Jul 23 02:43:03 2012 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Mon, 23 Jul 2012 13:43:03 +0400 Subject: openjfx-dev Digest, Vol 8, Issue 45 In-Reply-To: References: Message-ID: <500D1CA7.2090106@oracle.com> Hi John, On 07/21/12 04:52, John C. Turnbull wrote: > Actually, zoomX() and zoomY() probably aren't necessary but why are we > focusing on WebView here? Surely this should be at the Node level? I want > to be able to zoom in on images, graphics etc. where only the contents zoom, > not the scroll bars. I very much have a use case for this. Most nodes can do this already -- when you put them into a scroll pane and scale, the scroll pane handles the size change by adjusting scroll bars. WebView is different as it handles scrolling internally, without any enclosing scroll pane. This is so because of frames that may contain their own scrollbars and be scrolled independent of the rest of the page. So WebView can not be treated as a browser component inside a scroll pane. As for zoomX/Y I don't think Webkit supports it. It's designed as a browser core, and browsers hardly ever need such functionality. Thanks! -- Peter From martin.desruisseaux at geomatys.fr Mon Jul 23 03:09:47 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Mon, 23 Jul 2012 12:09:47 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500D155C.3000906@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> Message-ID: <500D22EB.3040109@geomatys.fr> Le 23/07/12 11:11, Pavel Safrata a ?crit : > We need to add manual transformation methods to Transfrom class. This > is very important, I can't believe I've forgotten them.. I noticed that those methods were missing, but I though that it was on intend :) > public Point3D transform(Point3D point) > public Bounds transform(Bounds bounds) > Any other? I think that the following one is very important for performance reasons: void transform(double[] srcPts, int srcOffset, double[] dstPts, int dstOffset, int numPts); with semantic identical to the one currently in the Java2D AffineTransform. The other variants working on float arrays and the ones mixing float/double arrays would also be useful. Alternatively, methods working on java.nio.Float/DoubleBuffer instead than arrays would also be okay if performances are the same (this would avoid the need for src/dstOffset and numPts arguments). Maybe it would be worth to phrase the javadoc in a way that leave room for slight implementation-dependant differences in the numerical results. For example the javadoc of Math.sin said "The computed result must be within 1 ulp of the exact result". I think that something similar for the transform methods (the number of ulp is yet to be determined) would be useful in order to leaves room for hardward-accelerated implementations. I'm thinking especially about the "fused add-multiply" operation found on many modern processor, which doesn't produce exactly the same result than multiplication followed by addition in Java. It would be nice if Transform implementations were allowed to use such operations on platforms that support it, despite the slight difference in numerical results. > Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, > MAT_3D_3x4, MAT_3D_4x4, do you agree? I don't really have better idea at this time... I wonder if we could find a way to merge with the VAT_* constants... Martin From mp at jugs.org Mon Jul 23 04:38:05 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Mon, 23 Jul 2012 13:38:05 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500D155C.3000906@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> Message-ID: <500D379D.9030304@jugs.org> Am 23.07.2012 11:11, schrieb Pavel Safrata: > > We need to add manual transformation methods to Transfrom class. This > is very important, I can't believe I've forgotten them.. > public Point3D transform(Point3D point) > public Bounds transform(Bounds bounds) > Any other? What about Point2D and the other geometries? What about "inverse"? Michael -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From pavel.safrata at oracle.com Mon Jul 23 05:01:59 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 23 Jul 2012 14:01:59 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500D22EB.3040109@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> Message-ID: <500D3D37.9050207@oracle.com> On 23.7.2012 12:09, Martin Desruisseaux wrote: > Le 23/07/12 11:11, Pavel Safrata a ?crit : >> We need to add manual transformation methods to Transfrom class. This >> is very important, I can't believe I've forgotten them.. > I noticed that those methods were missing, but I though that it was on > intend :) > >> public Point3D transform(Point3D point) >> public Bounds transform(Bounds bounds) >> Any other? > I think that the following one is very important for performance reasons: > > void transform(double[] srcPts, int srcOffset, double[] dstPts, int > dstOffset, int numPts); > > with semantic identical to the one currently in the Java2D > AffineTransform. Unlike in J2D our Pts will have three coordinates, right? Or do we want transform2D and transform3D? > The other variants working on float arrays and the ones mixing > float/double arrays would also be useful. Alternatively, methods > working on java.nio.Float/DoubleBuffer instead than arrays would also > be okay if performances are the same (this would avoid the need for > src/dstOffset and numPts arguments). I'm not sure about the floats. I don't mind adding those methods but is it OK for us to work with floats here and nowhere else? Shouldn't we then allow for floats at least for all the other arrays in Affine class? > > Maybe it would be worth to phrase the javadoc in a way that leave room > for slight implementation-dependant differences in the numerical > results. For example the javadoc of Math.sin said "The computed result > must be within 1 ulp of the exact result". I think that something > similar for the transform methods (the number of ulp is yet to be > determined) would be useful in order to leaves room for > hardward-accelerated implementations. I'm thinking especially about > the "fused add-multiply" operation found on many modern processor, > which doesn't produce exactly the same result than multiplication > followed by addition in Java. It would be nice if Transform > implementations were allowed to use such operations on platforms that > support it, despite the slight difference in numerical results. To me this sounds a bit frightening. I may be wrong but I believe that the "ulps" are there to deal with representability of certain numbers in floating-point types but not with different math engines producing different results - I believe the results may be up to one ulp wrong but are reliably stable among all platforms. I'm a bit afraid that providing unstable results would violate at least some unwritten conventions. But I'm not an expert here, I might be wrong. > > >> Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, >> MAT_3D_3x4, MAT_3D_4x4, do you agree? > I don't really have better idea at this time... I wonder if we could > find a way to merge with the VAT_* constants... We may use MAT for the getRow/getCol - it would specify from what matrix the col/row will be taken (each pair of values would provide similar behavior except for one of them allowing to read the last line). Thanks, Pavel > Martin > From martin.desruisseaux at geomatys.fr Mon Jul 23 06:20:45 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Mon, 23 Jul 2012 15:20:45 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500D3D37.9050207@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> <500D3D37.9050207@oracle.com> Message-ID: <500D4FAD.7010808@geomatys.fr> Le 23/07/12 14:01, Pavel Safrata a ?crit : > On 23.7.2012 12:09, Martin Desruisseaux wrote: > Unlike in J2D our Pts will have three coordinates, right? Or do we > want transform2D and transform3D? Yes, I was thinking about 3D-points. Maybe it is not necessary to support 2D-points, since the existing Java2D classes can fit that need... > I'm not sure about the floats. I don't mind adding those methods but > is it OK for us to work with floats here and nowhere else? Shouldn't > we then allow for floats at least for all the other arrays in Affine > class? I didn't though about the fact that 'float' are used nowhere else in JavaFX... This is a good point. Does JavaFX plans to support big geometries someday? For example world-wide coast lines, in which case using 'float' instead of 'double' make a huge difference on memory usage? > To me this sounds a bit frightening. I may be wrong but I believe that > the "ulps" are there to deal with representability of certain numbers > in floating-point types but not with different math engines producing > different results - I believe the results may be up to one ulp wrong > but are reliably stable among all platforms. I'm a bit afraid that > providing unstable results would violate at least some unwritten > conventions. But I'm not an expert here, I might be wrong. My (maybe naive) understanding was that StrictMath reliably produces stable results among all platforms, while Math allow some platform-dependent flexibility. In our implementation of a map projection library making extensive use of Math.sin and the like, I do have noticed slight platform-dependent variations. Transform doesn't have to use the "ulps" wording; the actual question is whatever Transform should allow hardward accelerations at the expense of strict cross-platform stability. It may be worth to note that if my understanding of java.lang.Math trigonometric functions is not wrong, then this slight cross-platform variability already exists in Transforms having a rotation calculated from an angle. > We may use MAT for the getRow/getCol - it would specify from what > matrix the col/row will be taken (each pair of values would provide > similar behavior except for one of them allowing to read the last line). This interpretation works for me. Anyone else? Martin From david.grieve at oracle.com Mon Jul 23 06:32:06 2012 From: david.grieve at oracle.com (David Grieve) Date: Mon, 23 Jul 2012 09:32:06 -0400 Subject: Color.toWeb & Color.toHexString In-Reply-To: <500528BB.6070502@oracle.com> References: <4FFC4124.6040207@oracle.com> <5004E608.6020804@oracle.com> <500528BB.6070502@oracle.com> Message-ID: <6F5C0A13-B78C-4E7B-8C19-86D1BD6BE3F8@oracle.com> Alpha isn't standard in a hex color, but the JavaFX CSS parser will parse #rgba or #rrggbbaa On Jul 17, 2012, at 4:56 AM, Pavel Safrata wrote: > > On 17.7.2012 6:11, Jim Graham wrote: >> I had similar questions to Rich, but I had one additional question: >> >> On 7/10/2012 7:50 AM, Pavel Safrata wrote: >>> public String toHexString() >>> >>> This method will return a string rrggbb without the leading hash. It >>> will ignore opacity and will round the values to the nearest color that >>> can be represented with such string. An example of use is displaying a >>> web-based color value in a color picker. >> >> Why ignore opacity? > > This one is disputable. I based it on the mentioned use-case where you edit the color in a color picker and I've never seen an application where opacity would be part of that field. Also AFAIK expressing opacity as 256-based value is not a common thing at all - for instance it wouldn't be parsed by any CSS engine, would it? But I'm not sure this justifies for ignoring the opacity, maybe we should produce the string expressing the color as close as possible. > > Thanks, > Pavel > >> >> ...jim > > 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 jmartine_1026 at yahoo.com Mon Jul 23 06:55:06 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Mon, 23 Jul 2012 06:55:06 -0700 (PDT) Subject: Auto-update of native application bundles In-Reply-To: <1343050534.25503.YahooMailNeo@web161503.mail.bf1.yahoo.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> <1342929638.55082.YahooMailNeo@web160904.mail.bf1.yahoo.com> <1343050534.25503.YahooMailNeo@web161503.mail.bf1.yahoo.com> Message-ID: <1343051706.56848.YahooMailNeo@web161504.mail.bf1.yahoo.com> Dan, > ?What do people think about this, what do we need to make things "safe" and if we do add security and jar signing should this be mandatory or optional? I think I need to understand the process better to really give this a proper response. ?Specifically what is the C++ code in the AU framework used for? ?Also, are the compiled time deltas contained into jars that then get merged with the currently installed jars? ?So if I have a jar with 200 files and only 50 of them have changed does the framework download the 50 file delta jar and some how merge the two jars into a new one? > ?Can you elaborate on what you mean by the 'main title screen'? If you consider a video game the title screen is that screen that appears after the game loads where the user has to click on start to begin playing. ?Instead of a popup my original thought was to have the "update available" link built right into the title screen. ?That way the developer can visualize this how ever they want... big flashing letters in the middle of the screen, or non-discrete small font msg at the bottom corner. ? So it would be part of applications main code that the developer would have to tie into the framework (if frameWork.isUpdateAvailable(), displayUpdateLink()). > ?I'd also be interested to know about Terms & Conditions pages - do people need this, should it be shown before the upgrade (seems logical), and does there need to be some record of the T&C acceptance legally, or is it generally enough that they can;t get past that page without clicking 'accept'?? This would be good as part of the installation process. ?Both the initial installation and future updates. ?The user would have to click on a radio button saying they read it before the installation wizard continues. ?I imagine this would have to be built into the Inno Setup script (I do not know if it has that capability)? ?Is Inno Setup used for the AU updates? ? > ?Basically, instead of adding the root of the scene directly to the Scene, I create a StackPane to wrapper it. When the "popup" is shown it is added to the top layer of this stackpane and so covers everything underneath. I use a semi-transparent pane to contain the popup and it is this semi-transparent pane that greys out the underlying scene and blocks mouse input, etc. All pretty basic stuff. ? Do you create a?separate Stage for this? ?I guess where I am stumped is that the way I picture JFX apps working is that you have this Stage that has a scene that has a root node and everything goes in root. ?But everything that goes in root is within the borders of main window. ?How has your popup left the main window? ?I imagine you would have to create a new window/stage to break free of the borders of the main one? ?I'm sure I'm missing some key piece of information here. thanks jose ________________________________ From: Daniel Zwolenski To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" Sent: Sunday, July 22, 2012 5:09 AM Subject: Re: Auto-update of native application bundles Thanks Jose for you feedback - much appreciated.? One topic I forgot to mention in the previous email - currently there is no signing and validation of the download. It assumes the URL you reference for AU is trustworthy and if you download something from that you are getting what you asked for and therefore it's ok to run that code. I tend to feel this is ok but I am generally on the relaxed end in this area. My logic is there's no guarantee the original install was not a hack/nasty, so why complicate the later downloads by trying to guarantee they are from the same source.? What do people think about this, what do we need to make things "safe" and if we do add security and jar signing should this be mandatory or optional? I, for one, would prefer not to complicate my build for an app that is only going to be installed/used on an intranet and VPN and therefore is probably safe enough without signing. ? Right from the main title screen they would see that an upgrade is available and given the option to upgrade now. ?This mimics some of my favorite apps. Can you elaborate on what you mean by the 'main title screen'? I'm guessing you are saying that a popup should be shown on startup if an upgrade is available but please let me know if I misunderstood. ? ? Release notes. ?I am used to how IOS does it, a user can see the list of changes before they upgrade an app. ? Good to know. I left out release notes as I was not sure exactly how people would want to use them. Adding it to the pre-install step makes sense.? ? this should cover all releases between current and latest? ? A simple solution would be just to link to a webpage and the developer is responsible for maintaining this page. This would allow you to completely style and manage this page as you want (e.g. something like?http://www.jetbrains.com/idea/whatsnew/index.html). Trying to record and derive individual release details and merge them would complicate the build process quite a lot I imagine and in some cases may not make sense. I'd be interested to hear more on how people would use this feature and what would work best for them.? I'd also be interested to know about Terms & Conditions pages - do people need this, should it be shown before the upgrade (seems logical), and does there need to be some record of the T&C acceptance legally, or is it generally enough that they can;t get past that page without clicking 'accept'?? Extra credit: option to upgrade to an?intermediary?version.... i do not know how popular this would be, I know for some apps in the past I had to hunt down version?in between?currently-installed and latest. Good use case to know about but I'm thinking this would not be part of the default work-flow. It adds complexity to a lot of levels that I'm not sure would be totally worth it. We definitely should make the underlying framework customisable enough however that this could be implemented by the developer. Happy to hear more thoughts on this one, and if the base framework allows for it (which it will) then it could always be added in a later version.? >?? 2. what ways would you likely want to customise this experience for more? specialised scenarios? > > >When a user purchases a license for my app they will be allowed to download future updates up to a certain point ?So if they have a very old license then they can't upgrade to latest. ?Do not know if this is something you want to build into the framework, but it at least must be implementable. ?If the user chooses to buy a new license to upgrade, would be cool if they just enter the new license and then they get to upgrade. ?So I guess I'm saying license based upgrade would be cool or at least not blocked by the framework. This is a good point. I definitely think the base framework should/will allow for this to be implemented on top of what comes by default. Thinking about it there is really an enhanced process that is common for most paid-for applications as opposed to your standard freebie or back-office application. Not sure this should be part of the core library, but perhaps - Igor and Richard might have some ideas on this as we get further along. A way for developers to easily licence/charge for their apps may well encourage more developers (as seen by the iOS app store). ? Perhaps though, this payment based AU system would be a nice open source project that extends the base functionality. It could then make use of third party licence, ssl, hashing and payment-gateway libraries to implement some powerful stuff on this. For example,?I don't see any technical reason why someone keen couldn't build their own 'pay now' screen as part of the upgrade wizard and hook this into a payment provider (such as PayPal). That would be pretty sweet.? ? On a?separate?topic...?how did you implement your details popup? ?I notice how it displayed outside of your main window and how it would remain within my desktop's borders. ? I just borrowed the old lightbox concept from web land (see?http://gettopup.com/) Basically, instead of adding the root of the scene directly to the Scene, I create a StackPane to wrapper it. When the "popup" is shown it is added to the top layer of this stackpane and so covers everything underneath. I use a semi-transparent pane to contain the popup and it is this semi-transparent pane that greys out the underlying scene and blocks mouse input, etc. All pretty basic stuff. ? I've used these a lot instead of dialogs, they have the advantage that they can be animated in/out and can be any shape, etc. They have the disadvantage that they can't really be application modal if you have multiple top-level windows (i.e. scenes) and I don't know how well they would block keyboard input such as shortcut keys.? I've thought about open sourcing the code for this (it's very simple) but never gotten round to it. If you are interested let me know.? From pavel.safrata at oracle.com Mon Jul 23 06:58:16 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 23 Jul 2012 15:58:16 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500D379D.9030304@jugs.org> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D379D.9030304@jugs.org> Message-ID: <500D5878.3000802@oracle.com> Hello, On 23.7.2012 13:38, Dr. Michael Paus wrote: > Am 23.07.2012 11:11, schrieb Pavel Safrata: >> >> We need to add manual transformation methods to Transfrom class. This >> is very important, I can't believe I've forgotten them.. >> public Point3D transform(Point3D point) >> public Bounds transform(Bounds bounds) >> Any other? > > What about Point2D and the other geometries? Why not, but would it return Point2D and throw an exception for 3D transform? Or would it return Point3D? I'd probably vote for the first option. What other geometries would you like to use? > > What about "inverse"? Do you mean that you would like to have a convenience method for createInverseTransform().transform(...)? Thanks, Pavel > > Michael > From pavel.safrata at oracle.com Mon Jul 23 06:59:29 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 23 Jul 2012 15:59:29 +0200 Subject: Color.toWeb & Color.toHexString In-Reply-To: <6F5C0A13-B78C-4E7B-8C19-86D1BD6BE3F8@oracle.com> References: <4FFC4124.6040207@oracle.com> <5004E608.6020804@oracle.com> <500528BB.6070502@oracle.com> <6F5C0A13-B78C-4E7B-8C19-86D1BD6BE3F8@oracle.com> Message-ID: <500D58C1.40300@oracle.com> Yes, I know, the Color.web() parses it as well. Pavel On 23.7.2012 15:32, David Grieve wrote: > Alpha isn't standard in a hex color, but the JavaFX CSS parser will > parse #rgba or #rrggbbaa > > On Jul 17, 2012, at 4:56 AM, Pavel Safrata wrote: > >> >> On 17.7.2012 6:11, Jim Graham wrote: >>> I had similar questions to Rich, but I had one additional question: >>> >>> On 7/10/2012 7:50 AM, Pavel Safrata wrote: >>>> public String toHexString() >>>> >>>> This method will return a string rrggbb without the leading hash. It >>>> will ignore opacity and will round the values to the nearest color that >>>> can be represented with such string. An example of use is displaying a >>>> web-based color value in a color picker. >>> >>> Why ignore opacity? >> >> This one is disputable. I based it on the mentioned use-case where >> you edit the color in a color picker and I've never seen an >> application where opacity would be part of that field. Also AFAIK >> expressing opacity as 256-based value is not a common thing at all - >> for instance it wouldn't be parsed by any CSS engine, would it? But >> I'm not sure this justifies for ignoring the opacity, maybe we should >> produce the string expressing the color as close as possible. >> >> Thanks, >> Pavel >> >>> >>> ...jim >> >> > > > 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 pedro.duquevieira at gmail.com Mon Jul 23 07:30:20 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 23 Jul 2012 15:30:20 +0100 Subject: Transform point using localToSceneTransform Message-ID: Hi, Thanks for the info Pavel, I'll be using the internal method for now than. I thought I would try to help out and post some other suggestions for the transform class. I have read this discussion but not with the necessary attention so apologies if I mention something that has already been discussed, or bring up discussion topics that have already reached a conclusion: 1- public Vector3D transform(Vector3D point) This implies having a Vector class which I think is appropriate. Vector objects may be used to represent translation, surface normals, pick rays, or other things 2- I don't like the append, prepend naming for the following reason: are you adding or subtracting or multiplying,.. matrixs? I suggest "multiply" as the name of the method. 3- public double determinant() Calculates and returns the determinant of this transform 4- public boolean equals(Transform t) 5- invert() Inverts this transform in place 6- multiply(double scalar) Multiplies each element of this transform by a scalar. 7- subtract(Transform t) substracts this matrix with matrix t 8- add(Transform t) adds this matrix with matrix t 9- transpose() Transposes this matrix Thanks, best regards, Hello, > currently there is no API for this. It is planned for the 3.0 release > (together with other matrix algebra operations - thanks for reminding me > by the way). So right now you unfortunately need to do the math yourself. > Regards, > Pavel > P.S. I didn't tell you this but as a temporary workaround you can use an > undocumented internal (but publicly accessible) method > impl_transform(Point3D). Please note that this method will be removed in > the next version (with the addition of the proper public methods). > On 21.7.2012 0:02, Pedro Duque Vieira wrote: > > Hi, > > > > I need to transform a point using the localToSceneTransform of a node, > > however I don't see any method on Transform class to accomplish this. > > Is there an easy way or do I have to do the math myself? > > > > Thanks, best regards, > > -- Pedro Duque Vieira From martin.desruisseaux at geomatys.fr Mon Jul 23 07:44:24 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Mon, 23 Jul 2012 16:44:24 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: References: Message-ID: <500D6348.5010309@geomatys.fr> Hello Pedro Le 23/07/12 16:30, Pedro Duque Vieira a ?crit : > 2- I don't like the append, prepend naming for the following reason: are > you adding or subtracting or multiplying,.. matrixs? I suggest "multiply" > as the name of the method. They are matrix multiplications, but except in the case of "Affine.append/prepend(Affine)" the matrix is implicit. For example "appendTranslation" implicitly built a translation matrix to be multiplied with the current Affine instance. They are multiplication in both cases. The problem is to express whatever we are doing AxB or BxA. > 3- public double determinant() > Calculates and returns the determinant of this transform I think this method is already presents in Affine. Do you propose it provides it in the Transform parent class? > 4- public boolean equals(Transform t) Right. But is overriding equals(Object) sufficient? > 5- invert() > Inverts this transform in place Like 'determinant()', do you propose to move this method from Affine to the Transform parent class? > 6- multiply(double scalar) > Multiplies each element of this transform by a scalar. > > 7- subtract(Transform t) > substracts this matrix with matrix t > > 8- add(Transform t) > adds this matrix with matrix t > > 9- transpose() > Transposes this matrix A problem is that those operations can not be implemented in the Affine class with the usual Matrix semantic, since they would change the '1' value in the last column of the last row into something else... Furthermore I wonder what they geometrically means? (e.g. the 'transpose' operation would move the 'scaleX' value to the 'translateX' position, etc.). Thanks for your feedbacks, Martin From zonski at gmail.com Mon Jul 23 07:46:35 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 24 Jul 2012 00:46:35 +1000 Subject: Auto-update of native application bundles In-Reply-To: <1343050534.25503.YahooMailNeo@web161503.mail.bf1.yahoo.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> <1342929638.55082.YahooMailNeo@web160904.mail.bf1.yahoo.com> <1343050534.25503.YahooMailNeo@web161503.mail.bf1.yahoo.com> Message-ID: > > Specifically what is the C++ code in the AU framework used for? > The Java part of the AU does all the dialogs and visual display that you see. It also does the version checking and the downloading and unzipping of the new update. The final step however is to copy the new files over the top of the old ones. This copies your JARs and also the JRE (if there is a new one). Since your app is running the JARs and the JRE are locked by the running Java process, so we can't do the overwrite in the Java code. This is where the C++ code comes in: the last thing the Java does before it kills itself is to launch a small C++ process that does this final copy of the files. Additionally on Windows, if you are writing to 'Program Files' you need to get permission from an ugly Windows thing called the User Access Control (UAC). This is what pops up the dialog that says "Do you want to allow this program to make changes?". You can't trigger this through Java code, so the C++ code is also responsible for this. Finally, when everything is copied over, the C++ code is then responsible for re-launching the newly updated application. The actual code is very simple (it's a single class with only a handful of lines of real code in it). This is what would need to be ported to linux and to OSx to make this solution cross platform. C++/ObjectiveC volunteers wanted (my C++ is lame). Also, are the compiled time deltas contained into jars that then get merged > with the currently installed jars? So if I have a jar with 200 files and > only 50 of them have changed does the framework download the 50 file delta > jar and some how merge the two jars into a new one? > I think Igor will be best to comment on this one. Igor, how do you see deltas working in the compile-time version of the solution, do we define specific JARs to be included or would we use some kind of binary diff and patch process (I think you mentioned this early on)? > Can you elaborate on what you mean by the 'main title screen'? > > If you consider a video game the title screen is that screen that appears > after the game loads where the user has to click on start to begin playing. > Instead of a popup my original thought was to have the "update available" > link built right into the title screen. That way the developer can > visualize this how ever they want... big flashing letters in the middle of > the screen, or non-discrete small font msg at the bottom corner. So it > would be part of applications main code that the developer would have to > tie into the framework (if frameWork.isUpdateAvailable(), > displayUpdateLink()). > Ok, the framework I'm working on will allow this to be built this way. > > I'd also be interested to know about Terms & Conditions pages - do > people need this, should it be shown before the upgrade (seems logical), > and does there need to be some record of the T&C acceptance legally, or is > it generally enough that they can;t get past that page without clicking > 'accept'? > > This would be good as part of the installation process. Both the initial > installation and future updates. The user would have to click on a radio > button saying they read it before the installation wizard continues. I > imagine this would have to be built into the Inno Setup script (I do not > know if it has that capability)? Is Inno Setup used for the AU updates? > I believe there is a request to have this added to the native installer with Igor's name on it. > Basically, instead of adding the root of the scene directly to the > Scene, I create a StackPane to wrapper it. When the "popup" is shown it is > added to the top layer of this stackpane and so covers everything > underneath. I use a semi-transparent pane to contain the popup and it is > this semi-transparent pane that greys out the underlying scene and blocks > mouse input, etc. All pretty basic stuff. > > Do you create a separate Stage for this? I guess where I am stumped is > that the way I picture JFX apps working is that you have this Stage that > has a scene that has a root node and everything goes in root. But > everything that goes in root is within the borders of main window. How has > your popup left the main window? I imagine you would have to create a new > window/stage to break free of the borders of the main one? I'm sure I'm > missing some key piece of information here. > The dialog is fully contained within the scene. If you shrank the containing window it would clip the dialog. It is styled to look like it is floating but it is no different to a button or label within the Scene (or at least the code is no different, if it isn't getting clipped then I would be very impressed :) ). From pavel.safrata at oracle.com Mon Jul 23 07:51:26 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 23 Jul 2012 16:51:26 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: References: Message-ID: <500D64EE.2080205@oracle.com> Hi Pedro, On 23.7.2012 16:30, Pedro Duque Vieira wrote: > Hi, > > Thanks for the info Pavel, I'll be using the internal method for now than. > > I thought I would try to help out and post some other suggestions for the > transform class. I have read this discussion but not with the necessary > attention so apologies if I mention something that has already been > discussed, or bring up discussion topics that have already reached a > conclusion: > > 1- public Vector3D transform(Vector3D point) > > This implies having a Vector class which I think is appropriate. Vector > objects may be used to represent translation, surface normals, pick rays, > or other things Is the existing Point3D not sufficient? > > 2- I don't like the append, prepend naming for the following reason: are > you adding or subtracting or multiplying,.. matrixs? I suggest "multiply" > as the name of the method. We are appending the transformation ("transforming" the matrix). It is more natural for transforms to be concatenated/appended than multiplied because you may generally use them without being aware of their matrix nature. > 3- public double determinant() > Calculates and returns the determinant of this transform Is part of the proposal. > > 4- public boolean equals(Transform t) I think we should not provide equals/hashCode for mutable objects. > > 5- invert() > Inverts this transform in place Is part of the proposal. > > 6- multiply(double scalar) > Multiplies each element of this transform by a scalar. > > 7- subtract(Transform t) > substracts this matrix with matrix t > > 8- add(Transform t) > adds this matrix with matrix t > > 9- transpose() > Transposes this matrix Are those methods useful for some transformation stuff? This is not a MatrixMath class, this is Transform... Thanks, Pavel > > Thanks, best regards, > > Hello, >> currently there is no API for this. It is planned for the 3.0 release >> (together with other matrix algebra operations - thanks for reminding me >> by the way). So right now you unfortunately need to do the math yourself. >> Regards, >> Pavel >> P.S. I didn't tell you this but as a temporary workaround you can use an >> undocumented internal (but publicly accessible) method >> impl_transform(Point3D). Please note that this method will be removed in >> the next version (with the addition of the proper public methods). >> On 21.7.2012 0:02, Pedro Duque Vieira wrote: >>> Hi, >>> >>> I need to transform a point using the localToSceneTransform of a node, >>> however I don't see any method on Transform class to accomplish this. >>> Is there an easy way or do I have to do the math myself? >>> >>> Thanks, best regards, >>> From mp at jugs.org Mon Jul 23 07:53:25 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Mon, 23 Jul 2012 16:53:25 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500D5878.3000802@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D379D.9030304@jugs.org> <500D5878.3000802@oracle.com> Message-ID: <500D6565.70002@jugs.org> Am 23.07.2012 15:58, schrieb Pavel Safrata: > Hello, > > On 23.7.2012 13:38, Dr. Michael Paus wrote: >> Am 23.07.2012 11:11, schrieb Pavel Safrata: >>> >>> We need to add manual transformation methods to Transfrom class. >>> This is very important, I can't believe I've forgotten them.. >>> public Point3D transform(Point3D point) >>> public Bounds transform(Bounds bounds) >>> Any other? >> >> What about Point2D and the other geometries? > > Why not, but would it return Point2D and throw an exception for 3D > transform? Or would it return Point3D? I'd probably vote for the first > option. Me too. If you are using Point2D you probably expect to stay in the 2D space. > What other geometries would you like to use? You support Bounds but not Rectangle2D. But I am not sure whether it really makes sense to consider this. > >> >> What about "inverse"? > > Do you mean that you would like to have a convenience method for > createInverseTransform().transform(...)? > > Thanks, > Pavel > >> >> Michael >> > > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From martin.desruisseaux at geomatys.fr Mon Jul 23 07:58:21 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Mon, 23 Jul 2012 16:58:21 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: <500D64EE.2080205@oracle.com> References: <500D64EE.2080205@oracle.com> Message-ID: <500D668D.2090808@geomatys.fr> Le 23/07/12 16:51, Pavel Safrata a ?crit : >> 1- public Vector3D transform(Vector3D point) >> >> This implies having a Vector class which I think is appropriate. Vector >> objects may be used to represent translation, surface normals, pick >> rays, >> or other things > Is the existing Point3D not sufficient? Just for information purpose, I interpret this request as functionally equivalent to the current "deltaTransform" method in Java2D AffineTransform. Transforming a vector is like transforming a points without the translation terms. They are used for transforming distances between points rather than the points directly. Whatever it is useful enough is another question. On my side, my usage of AffineTransform2D.deltaTransform has been very rare. But when this need arise it is useful. Martin From pavel.safrata at oracle.com Mon Jul 23 08:14:59 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 23 Jul 2012 17:14:59 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500D4FAD.7010808@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> <500D3D37.9050207@oracle.com> <500D4FAD.7010808@geomatys.fr> Message-ID: <500D6A73.8060304@oracle.com> On 23.7.2012 15:20, Martin Desruisseaux wrote: > Le 23/07/12 14:01, Pavel Safrata a ?crit : >> On 23.7.2012 12:09, Martin Desruisseaux wrote: >> Unlike in J2D our Pts will have three coordinates, right? Or do we >> want transform2D and transform3D? > Yes, I was thinking about 3D-points. Maybe it is not necessary to > support 2D-points, since the existing Java2D classes can fit that need... The purpose of this discussion is for users to have all needed math in our transformations so they don't need to use other transformation libraries to do the basic math. An FX application will (and should) use FX transforms and they should provide all the necessary features; mixing the FX code with J2D transforms, that are unusable with our nodes, is not a nice thing to do. So if we don't provide the 2D case here, we need to have different reason :-) > > >> I'm not sure about the floats. I don't mind adding those methods but >> is it OK for us to work with floats here and nowhere else? Shouldn't >> we then allow for floats at least for all the other arrays in Affine >> class? > I didn't though about the fact that 'float' are used nowhere else in > JavaFX... This is a good point. > > Does JavaFX plans to support big geometries someday? For example > world-wide coast lines, in which case using 'float' instead of > 'double' make a huge difference on memory usage? I'm afraid I don't see the big picture here. But maybe we can leave the 'float' variants out for now (we can always add them later). > > >> To me this sounds a bit frightening. I may be wrong but I believe >> that the "ulps" are there to deal with representability of certain >> numbers in floating-point types but not with different math engines >> producing different results - I believe the results may be up to one >> ulp wrong but are reliably stable among all platforms. I'm a bit >> afraid that providing unstable results would violate at least some >> unwritten conventions. But I'm not an expert here, I might be wrong. > My (maybe naive) understanding was that StrictMath reliably produces > stable results among all platforms, while Math allow some > platform-dependent flexibility. In our implementation of a map > projection library making extensive use of Math.sin and the like, I do > have noticed slight platform-dependent variations. You are right, the javadoc claims so. > > Transform doesn't have to use the "ulps" wording; the actual question > is whatever Transform should allow hardward accelerations at the > expense of strict cross-platform stability. It may be worth to note > that if my understanding of java.lang.Math trigonometric functions is > not wrong, then this slight cross-platform variability already exists > in Transforms having a rotation calculated from an angle. I agree that it sounds good to leave the door to hw acceleration open. For start it may be enough to just mention that possibility in the documentation, without specifying the exact error range. Vast majority of users won't probably be very concerned about invisible value nuances. Thanks, Pavel > > >> We may use MAT for the getRow/getCol - it would specify from what >> matrix the col/row will be taken (each pair of values would provide >> similar behavior except for one of them allowing to read the last line). > This interpretation works for me. Anyone else? > > Martin > From martin.desruisseaux at geomatys.fr Mon Jul 23 08:28:31 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Mon, 23 Jul 2012 17:28:31 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500D6A73.8060304@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> <500D3D37.9050207@oracle.com> <500D4FAD.7010808@geomatys.fr> <500D6A73.8060304@oracle.com> Message-ID: <500D6D9F.7000704@geomatys.fr> Le 23/07/12 17:14, Pavel Safrata a ?crit : > The purpose of this discussion is for users to have all needed math in > our transformations so they don't need to use other transformation > libraries to do the basic math. An FX application will (and should) > use FX transforms and they should provide all the necessary features; > mixing the FX code with J2D transforms, that are unusable with our > nodes, is not a nice thing to do. So if we don't provide the 2D case > here, we need to have different reason :-) This is fair. I'm neutral on this issue, since we are likely to have non-JavaFX transforms (map projections) in the mix anyway... >> Does JavaFX plans to support big geometries someday? For example >> world-wide coast lines, in which case using 'float' instead of >> 'double' make a huge difference on memory usage? > I'm afraid I don't see the big picture here. But maybe we can leave > the 'float' variants out for now (we can always add them later). I agree. > I agree that it sounds good to leave the door to hw acceleration open. > For start it may be enough to just mention that possibility in the > documentation, without specifying the exact error range. Vast majority > of users won't probably be very concerned about invisible value nuances. Yes I agree too. Thanks, Martin From pedro.duquevieira at gmail.com Mon Jul 23 08:47:51 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 23 Jul 2012 16:47:51 +0100 Subject: Transform point using localToSceneTransform Message-ID: > > > 1- public Vector3D transform(Vector3D point) > > > > This implies having a Vector class which I think is appropriate. Vector > > objects may be used to represent translation, surface normals, pick rays, > > or other things > Is the existing Point3D not sufficient? No. Imagine someone reading a piece of code that represents surface normals and pick rays as a Point3D, not very understandable. Also it's useful to compute angles between vectors, cross product, magnitude of the vector, ... > 6- multiply(double scalar) > > Multiplies each element of this transform by a scalar. > > > > 7- subtract(Transform t) > > substracts this matrix with matrix t > > > > 8- add(Transform t) > > adds this matrix with matrix t > > > > 9- transpose() > > Transposes this matrix > Are those methods useful for some transformation stuff? This is not a > MatrixMath class, this is Transform... Not sure, it's been a while since I've worked with 3d graphics libraries. Java3d has this methods on the Transform3d class. Thanks, cheers, -- Pedro Duque Vieira From martin.desruisseaux at geomatys.fr Mon Jul 23 08:57:12 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Mon, 23 Jul 2012 17:57:12 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: References: Message-ID: <500D7458.1070600@geomatys.fr> Le 23/07/12 17:47, Pedro Duque Vieira a ?crit : >> Are those methods useful for some transformation stuff? This is not a >> MatrixMath class, this is Transform... > Not sure, it's been a while since I've worked with 3d graphics libraries. > Java3d has this methods on the Transform3d class. Well... the Java3D Transform3D class is implemented by a full 4x4 matrix, which is more general than an Affine transform. As said previously, those methods can not be implemented in an Affine class... Martin From ozemale at ozemail.com.au Mon Jul 23 10:53:20 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Tue, 24 Jul 2012 03:53:20 +1000 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <500D1784.2060105@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> Message-ID: <004501cd68fc$0c29b680$247d2380$@com.au> Just "zoomProperty" sounds right but, as I said, I think it should be at Node level so that other node types can use it too, especially ImageView and graphics nodes. It should zoom the contents only (not the scroll bars though the latter should update accordingly to reflect the changes in the dimensions of the content and the new relative position). -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter Zhelezniakov Sent: Monday, 23 July 2012 19:21 To: Leonid Popov Cc: openjfx-dev at openjdk.java.net; Sergey Malenkov Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) On 07/20/12 20:14, Leonid Popov wrote: > It sounds reasonable, assuming that scaleX/scaleY have slightly > different semantics (they apply to the whole view, including > scrollbars, while the proposed property should affect WebView contents > only). Any other opinions on scale vs. zoom? I named it scaleProperty for consistency as we already had fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive than 'scale'. I don't have strong preference now. Should we name it just zoomProperty, or maybe zoomFactorProperty? Native speakers please advise! Thanks! -- Peter From ozemale at ozemail.com.au Mon Jul 23 10:55:52 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Tue, 24 Jul 2012 03:55:52 +1000 Subject: FW: API REVIEW: WebView.scale property (for JavaFX 3.0 now) Message-ID: <004601cd68fc$670858e0$35190aa0$@com.au> Sorry, I didn't see Peter's later message which may have addressed this. Anyway, "zoomProperty" sounds like the correct name for this property. Thanks, -jct -----Original Message----- From: John C. Turnbull [mailto:ozemale at ozemail.com.au] Sent: Tuesday, 24 July 2012 03:53 To: 'Peter Zhelezniakov'; 'Leonid Popov' Cc: 'openjfx-dev at openjdk.java.net'; 'Sergey Malenkov' Subject: RE: API REVIEW: WebView.scale property (for JavaFX 3.0 now) Just "zoomProperty" sounds right but, as I said, I think it should be at Node level so that other node types can use it too, especially ImageView and graphics nodes. It should zoom the contents only (not the scroll bars though the latter should update accordingly to reflect the changes in the dimensions of the content and the new relative position). -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter Zhelezniakov Sent: Monday, 23 July 2012 19:21 To: Leonid Popov Cc: openjfx-dev at openjdk.java.net; Sergey Malenkov Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) On 07/20/12 20:14, Leonid Popov wrote: > It sounds reasonable, assuming that scaleX/scaleY have slightly > different semantics (they apply to the whole view, including > scrollbars, while the proposed property should affect WebView contents > only). Any other opinions on scale vs. zoom? I named it scaleProperty for consistency as we already had fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive than 'scale'. I don't have strong preference now. Should we name it just zoomProperty, or maybe zoomFactorProperty? Native speakers please advise! Thanks! -- Peter From kevin.rushforth at oracle.com Mon Jul 23 11:25:49 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Jul 2012 11:25:49 -0700 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <004501cd68fc$0c29b680$247d2380$@com.au> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> <004501cd68fc$0c29b680$247d2380$@com.au> Message-ID: <500D972D.6080009@oracle.com> Kirill already answered the question of its being a node property: Node already has xScale and yScale properties...this is something subtly different. I think either zoom or zoomFactor would be fine (I would note that zoom is shorter, so might be better if it won't be confusing). -- Kevin John C. Turnbull wrote: > Just "zoomProperty" sounds right but, as I said, I think it should be at > Node level so that other node types can use it too, especially ImageView and > graphics nodes. It should zoom the contents only (not the scroll bars > though the latter should update accordingly to reflect the changes in the > dimensions of the content and the new relative position). > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter > Zhelezniakov > Sent: Monday, 23 July 2012 19:21 > To: Leonid Popov > Cc: openjfx-dev at openjdk.java.net; Sergey Malenkov > Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) > > On 07/20/12 20:14, Leonid Popov wrote: > >> It sounds reasonable, assuming that scaleX/scaleY have slightly >> different semantics (they apply to the whole view, including >> scrollbars, while the proposed property should affect WebView contents >> only). Any other opinions on scale vs. zoom? >> > > I named it scaleProperty for consistency as we already had > fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive > than 'scale'. I don't have strong preference now. > > Should we name it just zoomProperty, or maybe zoomFactorProperty? Native > speakers please advise! > > Thanks! > -- > Peter > > From pedro.duquevieira at gmail.com Mon Jul 23 12:29:01 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 23 Jul 2012 20:29:01 +0100 Subject: Transform point using localToSceneTransform Message-ID: > > > Uses of matrix transpose: - Goraud and Phong shading models use this. - Also one example I've found: An application of a transpose matrix is animated firing guns in a 1st-person view. The eye matrix maps world-to-eye coordinates. The tracer rounds from the gun are modeled starting from a local coordinate system. What is needed is a local matrix that maps local-to-world coordinates and it must be aligned with the eye matrix. The transpose of the eye matrix can be used as the local matrix. Although the transposed eye matrix apparently maps eye-to-world coordinates, it will work as the result of the transformation is in world coordinates (on the output side). Local coordinates are substituted for eye coordinates on the input side. A copy of the eye matrix used as the local matrix would not work because the two transformations from local-to-world and world-to-eye would nonsensically pass thru the eye matrix (which is meant for the latter transformation only). Cheers, -- Pedro Duque Vieira From james.graham at oracle.com Mon Jul 23 15:02:25 2012 From: james.graham at oracle.com (Jim Graham) Date: Mon, 23 Jul 2012 15:02:25 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <500D3D37.9050207@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> <500D3D37.9050207@oracle.com> Message-ID: <500DC9F1.1010406@oracle.com> On 7/23/2012 5:01 AM, Pavel Safrata wrote: >> I think that the following one is very important for performance reasons: >> >> void transform(double[] srcPts, int srcOffset, double[] dstPts, int >> dstOffset, int numPts); >> >> with semantic identical to the one currently in the Java2D >> AffineTransform. > > Unlike in J2D our Pts will have three coordinates, right? Or do we want > transform2D and transform3D? I'm fine with double-only for now given the rest of the FX APIs. As far as whether the array is 2D or 3D, I'll leave that up to the engineers who are planning to use it. Would 3D-only be confusing to them? I could live with it either way, but it may be a culture shock coming from J2D. > To me this sounds a bit frightening. I may be wrong but I believe that > the "ulps" are there to deal with representability of certain numbers in > floating-point types but not with different math engines producing > different results - I believe the results may be up to one ulp wrong but > are reliably stable among all platforms. I'm a bit afraid that providing > unstable results would violate at least some unwritten conventions. But > I'm not an expert here, I might be wrong. ulp is a unit representing the minimal difference in values. It's simply the only way you can realistically state errors in a floating point world given its sliding scale of how many bits past the decimal point it offers. Stating the error should be within 1E-N is wrong because the nearest representable value may not be within that error bound from the true result depending on the magnitude of the result. You might be able to guarantee that if the result is around 10, but not if the result is around a billion since numbers of that magnitude have fewer bits to devote to the fractional part. So errors are typically stated as multiples of ulp. So, saying "within 2^N ulp is the same as saying that the lowest N bits might be wrong". >>> Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, >>> MAT_3D_3x4, MAT_3D_4x4, do you agree? >> I don't really have better idea at this time... I wonder if we could >> find a way to merge with the VAT_* constants... > > We may use MAT for the getRow/getCol - it would specify from what matrix > the col/row will be taken (each pair of values would provide similar > behavior except for one of them allowing to read the last line). Also, I don't think you can accurately determine which values to read without the full MAT since the 3rd row (index == 2?) of a matrix with Z is different from the same index row of a matrix that doesn't have Z. So, I think it makes sense to use the MAT types for both methods (the matrix and the row/col methods). With respect to methods that don't take a MAT type - I think we should simply say that the default is MAT_4x4 rather than infer it from the size of the array - that is cleaner and avoids mistakes where they forgot how big their array was (as in, they allocated a temp array and left it around for future use and some other programmer came in and decided that the array should be bigger without noticing that it affects the values that the former code would get)... ...jim From james.graham at oracle.com Mon Jul 23 15:03:03 2012 From: james.graham at oracle.com (Jim Graham) Date: Mon, 23 Jul 2012 15:03:03 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <500D155C.3000906@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> Message-ID: <500DCA17.6050705@oracle.com> Also, what about inverseTransform(point/bounds) methods? And deltaTransform()? ...jim On 7/23/2012 2:11 AM, Pavel Safrata wrote: > Hello, > looks like we reached the agreement on a (well documented) > append/prepend terminology with the original proposal semantics reversed. > > Before I post the final proposal, following changes need to be discussed: > > We need to add manual transformation methods to Transfrom class. This is > very important, I can't believe I've forgotten them.. > public Point3D transform(Point3D point) > public Bounds transform(Bounds bounds) > Any other? > > Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, > MAT_3D_3x4, MAT_3D_4x4, do you agree? > > Keep the methods accepting arrays recognizing their types according to > their length and add > public Affine(double[] array, MatrixArrayType type, int beginIndex) > public void setToTransform(double[] array, MatrixArrayType type, int > beginIndex) > public void append(double[] array, MatrixArrayType type, int beginIndex) > public void prepend(double[] array, MatrixArrayType type, int beginIndex) > Do you agree? Or would you prefer different set of array-accepting methods? > > Regarding the getRow/getColumn: we again face the problem whether to > return 3 or 4 elements. Consistently with the toArray, I propose > VectorArrayType = { VAT_2D, VAT_3D } > public double[] getRow(int row, VectorArrayType type), > public double[] getRow(int row, VectorArrayType type, double[] array) > public double[] getColumn(int col, VectorArrayType type), > public double[] getColumn(int col, VectorArrayType type, double[] array) > Do you agree? > > Thanks, > Pavel > > On 21.7.2012 2:52, Martin Desruisseaux wrote: >> Hello Jim >> >> No worry, I don't think that anyone felt sent off. I think that >> peoples know that emails can give all kind of impression not always >> accurate. >> >> I wasn't aware that a concept of transformation chains could be >> associated to nodes. Given that this chain is in reverse order >> compared to the one I was familiar with, I understand the difference >> in interpretation of "append". I agree that consistency is important. >> I have no problem with any choice, but I would just like the >> explanation about transformation chains (in the JavaFX sense) to >> appear somewhere in the javadoc, for helping some developers >> (including myself) to do the right association in their mind. >> >> Thanks and regards, >> >> Martin >> >> >> >> Le 21/07/12 02:02, Jim Graham a ?crit : >>> When I wrote my first reply in this thread I tried to warn people >>> that I was coming back from vacation to a long thread and I hadn't >>> double checked all of the math that was being proposed, so I was >>> commenting from a general perspective that wasn't necessarily in >>> agreement or conflict with the current proposal at the time. I hope >>> that I didn't send people off on a wild goose chase based on my list >>> of points that may have come from a negative "we shouldn't do this or >>> that" kind of perspective. >>> >>> To switch things around, let me make some positive statements of >>> something that I would find acceptable and which I think may have >>> actually been formally proposed here (but I didn't "do the math" to >>> verify that). >>> >>> I believe that the following produce equivalent transforms: >>> >>> -------------- >>> Node.getTransforms().add(new Scale(sx,sy)); >>> Node.getTransforms().add(new Translate(tx,ty)); >>> --- >>> t = new java.awt.geom.AffineTransform(); >>> t.scale(sx, sy); >>> t.translate(tx, ty); >>> --- >>> t = new java.awt.geom.AffineTransform(); >>> tmp = new java.awt.geom.AffineTransform(); >>> tmp.setToScale(sx, sy); >>> t.concatenate(tmp); >>> tmp.setToTranslate(tx, ty); >>> t.concatenate(tmp); >>> --- >>> Node n...; >>> Group g = new Group(n); >>> g.setScale(sx, sy); >>> n.setTranslate(tx, ty); >>> -------------- >>> >>> We also have the fact that "preConcatenate()" is mathematically >>> reversed, and also inside-out from the perspective of what is being >>> manipluated, as compared to concatenate(). >>> >>> So, if "appendFoo(...)" was essentially equivalent to: >>> >>> - Node.getTransforms().add(new Foo(...)); >>> - t.foo(...); >>> - t.concatenate(tmp.setToFoo(...)); >>> >>> and "prependFoo(...)" was essentially equivalent to: >>> >>> - Node.getTransforms().add(0, new Foo(...)); >>> - we don't have a Java2D reverse for t.foo(); >>> - t.preConcatenate(tmp.setToFoo(...)); >>> >>> then I could be happy. It may not have complete unambiguity in an >>> absolute sense, but it would at least establish an internal >>> consistency and harmony of naming conventions with respect to the >>> JavaFX Node transform attributes and with the prior art in the Java >>> geometry family (AffineTransform)... >>> >>> I feel that append, while we can argue the semantics of what it might >>> mean mathematically, sounds like the more natural verb of the two >>> forms of methods (comparing appendFoo to prependFoo), and in general >>> it is the set of methods that they probably want to be using if they >>> come from Java2D, or if they are writing code that takes a transform >>> from somewhere else that defines their "transformation context" and >>> they want to work within that (if you prepend, then you override the >>> context someone set up for you, if you append, then you take their >>> context and work relative to it). >>> >>> Is that what was being proposed before I came in and stomped on the >>> discussion? >>> >>> ...jim >>> >> > > From martin.desruisseaux at geomatys.fr Mon Jul 23 15:11:32 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 24 Jul 2012 00:11:32 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: References: Message-ID: <500DCC14.6060201@geomatys.fr> I didn't knew those usages, thanks for teaching me! Martin Le 23/07/12 21:29, Pedro Duque Vieira a ?crit : > Uses of matrix transpose: > - Goraud and Phong shading models use this. > - Also one example I've found: > An application of a transpose matrix is animated firing guns in a > 1st-person view. The eye matrix maps world-to-eye coordinates. The tracer > rounds from the gun are modeled starting from a local coordinate system. > What is needed is a local matrix that maps local-to-world coordinates and > it must be aligned with the eye matrix. The transpose of the eye matrix can > be used as the local matrix. Although the transposed eye matrix apparently > maps eye-to-world coordinates, it will work as the result of the > transformation is in world coordinates (on the output side). Local > coordinates are substituted for eye coordinates on the input side. A copy > of the eye matrix used as the local matrix would not work because the two > transformations from local-to-world and world-to-eye would nonsensically > pass thru the eye matrix (which is meant for the latter transformation > only). From pavel.safrata at oracle.com Tue Jul 24 03:26:54 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 24 Jul 2012 12:26:54 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: <500D668D.2090808@geomatys.fr> References: <500D64EE.2080205@oracle.com> <500D668D.2090808@geomatys.fr> Message-ID: <500E786E.2060408@oracle.com> On 23.7.2012 16:58, Martin Desruisseaux wrote: > Le 23/07/12 16:51, Pavel Safrata a ?crit : >>> 1- public Vector3D transform(Vector3D point) >>> >>> This implies having a Vector class which I think is appropriate. Vector >>> objects may be used to represent translation, surface normals, pick >>> rays, >>> or other things >> Is the existing Point3D not sufficient? > > Just for information purpose, I interpret this request as functionally > equivalent to the current "deltaTransform" method in Java2D > AffineTransform. Transforming a vector is like transforming a points > without the translation terms. They are used for transforming > distances between points rather than the points directly. > > Whatever it is useful enough is another question. On my side, my usage > of AffineTransform2D.deltaTransform has been very rare. But when this > need arise it is useful. Thanks for clarifying. I've also seen a few cases where deltaTransform was useful. It may be a good thing to have after all. Whether as deltaTransform(Point3D) or transform(Vector3D) I'm going to discuss in my next email. Pavel > > Martin > From pavel.safrata at oracle.com Tue Jul 24 03:29:09 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 24 Jul 2012 12:29:09 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: References: Message-ID: <500E78F5.5090107@oracle.com> On 23.7.2012 17:47, Pedro Duque Vieira wrote: >>> 1- public Vector3D transform(Vector3D point) >>> >>> This implies having a Vector class which I think is appropriate. Vector >>> objects may be used to represent translation, surface normals, pick rays, >>> or other things >> Is the existing Point3D not sufficient? > > No. Imagine someone reading a piece of code that represents surface normals > and pick rays as a Point3D, not very understandable. Also it's useful to > compute angles between vectors, cross product, magnitude of the vector, ... > > We already use Point3D as a vector. It seems that publicly it's currently only in Rotate - as rotation axis. So we can either continue to do that - J2D does this as well - and possibly provide the vector methods in Point3D, or we need to introduce new Vector3D and Vector2D and deprecate the now wrong Point3D usage in Rotate. To me it seems it might really be clearer to introduce the vectors, but I think Richard should comment when abandoning old API comes to play.. Thanks, Pavel From pavel.safrata at oracle.com Tue Jul 24 03:44:43 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 24 Jul 2012 12:44:43 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500DC9F1.1010406@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> <500D3D37.9050207@oracle.com> <500DC9F1.1010406@oracle.com> Message-ID: <500E7C9B.2030404@oracle.com> On 24.7.2012 0:02, Jim Graham wrote: > On 7/23/2012 5:01 AM, Pavel Safrata wrote: >>> I think that the following one is very important for performance >>> reasons: >>> >>> void transform(double[] srcPts, int srcOffset, double[] dstPts, int >>> dstOffset, int numPts); >>> >>> with semantic identical to the one currently in the Java2D >>> AffineTransform. >> >> Unlike in J2D our Pts will have three coordinates, right? Or do we want >> transform2D and transform3D? > > I'm fine with double-only for now given the rest of the FX APIs. > > As far as whether the array is 2D or 3D, I'll leave that up to the > engineers who are planning to use it. Would 3D-only be confusing to > them? I could live with it either way, but it may be a culture shock > coming from J2D. We generally have the 2D/3D option everywhere so I think we should not make an exception here. > >> To me this sounds a bit frightening. I may be wrong but I believe that >> the "ulps" are there to deal with representability of certain numbers in >> floating-point types but not with different math engines producing >> different results - I believe the results may be up to one ulp wrong but >> are reliably stable among all platforms. I'm a bit afraid that providing >> unstable results would violate at least some unwritten conventions. But >> I'm not an expert here, I might be wrong. > > ulp is a unit representing the minimal difference in values. It's > simply the only way you can realistically state errors in a floating > point world given its sliding scale of how many bits past the decimal > point it offers. > > Stating the error should be within 1E-N is wrong because the nearest > representable value may not be within that error bound from the true > result depending on the magnitude of the result. You might be able to > guarantee that if the result is around 10, but not if the result is > around a billion since numbers of that magnitude have fewer bits to > devote to the fractional part. So errors are typically stated as > multiples of ulp. So, saying "within 2^N ulp is the same as saying > that the lowest N bits might be wrong". > >>>> Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, >>>> MAT_3D_3x4, MAT_3D_4x4, do you agree? >>> I don't really have better idea at this time... I wonder if we could >>> find a way to merge with the VAT_* constants... >> >> We may use MAT for the getRow/getCol - it would specify from what matrix >> the col/row will be taken (each pair of values would provide similar >> behavior except for one of them allowing to read the last line). > > Also, I don't think you can accurately determine which values to read > without the full MAT since the 3rd row (index == 2?) of a matrix with > Z is different from the same index row of a matrix that doesn't have > Z. So, I think it makes sense to use the MAT types for both methods > (the matrix and the row/col methods). The earlier VAT proposal contained VAT_2D (without Z) and VAT_3D (with Z), so I think it was sufficient, but seems that we agree on MAT usage. > > With respect to methods that don't take a MAT type - I think we should > simply say that the default is MAT_4x4 rather than infer it from the > size of the array - that is cleaner and avoids mistakes where they > forgot how big their array was (as in, they allocated a temp array and > left it around for future use and some other programmer came in and > decided that the array should be bigger without noticing that it > affects the values that the former code would get)... The MAT was introduced because there is no obvious choice of the default type. The 4x4 type forces you to always add four useless values to your array (that have no corresponding members in the class you are constructing). I agree that the described problem may occur. So I think I'd rather get rid of the simple methods completely and provide only the ones using MAT. We can on the other hand provide two variants, one with the beginIndex, second without it. Thanks, Pavel > > ...jim From pavel.safrata at oracle.com Tue Jul 24 03:54:24 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 24 Jul 2012 12:54:24 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500DCA17.6050705@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500DCA17.6050705@oracle.com> Message-ID: <500E7EE0.9030005@oracle.com> inverseTransform: currently you can do createInverse().transform(...) I think it may be better to leave it like that because inversion is an expensive operation and user now has to control how often is it called and when the inverted matrix can be gc'd. If we introduced some convenience method we would probably need some inverse matrix caching (with considerable space requirements). But this is already second request so it might be worth it. Any other opinions? deltaTransform: this discussion goes on under "Transform point using localToSceneTransform" subject. Please join there. Thanks, Pavel On 24.7.2012 0:03, Jim Graham wrote: > Also, what about inverseTransform(point/bounds) methods? And > deltaTransform()? > > ...jim > > On 7/23/2012 2:11 AM, Pavel Safrata wrote: >> Hello, >> looks like we reached the agreement on a (well documented) >> append/prepend terminology with the original proposal semantics >> reversed. >> >> Before I post the final proposal, following changes need to be >> discussed: >> >> We need to add manual transformation methods to Transfrom class. This is >> very important, I can't believe I've forgotten them.. >> public Point3D transform(Point3D point) >> public Bounds transform(Bounds bounds) >> Any other? >> >> Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, >> MAT_3D_3x4, MAT_3D_4x4, do you agree? >> >> Keep the methods accepting arrays recognizing their types according to >> their length and add >> public Affine(double[] array, MatrixArrayType type, int beginIndex) >> public void setToTransform(double[] array, MatrixArrayType type, int >> beginIndex) >> public void append(double[] array, MatrixArrayType type, int beginIndex) >> public void prepend(double[] array, MatrixArrayType type, int >> beginIndex) >> Do you agree? Or would you prefer different set of array-accepting >> methods? >> >> Regarding the getRow/getColumn: we again face the problem whether to >> return 3 or 4 elements. Consistently with the toArray, I propose >> VectorArrayType = { VAT_2D, VAT_3D } >> public double[] getRow(int row, VectorArrayType type), >> public double[] getRow(int row, VectorArrayType type, double[] array) >> public double[] getColumn(int col, VectorArrayType type), >> public double[] getColumn(int col, VectorArrayType type, double[] array) >> Do you agree? >> >> Thanks, >> Pavel >> >> On 21.7.2012 2:52, Martin Desruisseaux wrote: >>> Hello Jim >>> >>> No worry, I don't think that anyone felt sent off. I think that >>> peoples know that emails can give all kind of impression not always >>> accurate. >>> >>> I wasn't aware that a concept of transformation chains could be >>> associated to nodes. Given that this chain is in reverse order >>> compared to the one I was familiar with, I understand the difference >>> in interpretation of "append". I agree that consistency is important. >>> I have no problem with any choice, but I would just like the >>> explanation about transformation chains (in the JavaFX sense) to >>> appear somewhere in the javadoc, for helping some developers >>> (including myself) to do the right association in their mind. >>> >>> Thanks and regards, >>> >>> Martin >>> >>> >>> >>> Le 21/07/12 02:02, Jim Graham a ?crit : >>>> When I wrote my first reply in this thread I tried to warn people >>>> that I was coming back from vacation to a long thread and I hadn't >>>> double checked all of the math that was being proposed, so I was >>>> commenting from a general perspective that wasn't necessarily in >>>> agreement or conflict with the current proposal at the time. I hope >>>> that I didn't send people off on a wild goose chase based on my list >>>> of points that may have come from a negative "we shouldn't do this or >>>> that" kind of perspective. >>>> >>>> To switch things around, let me make some positive statements of >>>> something that I would find acceptable and which I think may have >>>> actually been formally proposed here (but I didn't "do the math" to >>>> verify that). >>>> >>>> I believe that the following produce equivalent transforms: >>>> >>>> -------------- >>>> Node.getTransforms().add(new Scale(sx,sy)); >>>> Node.getTransforms().add(new Translate(tx,ty)); >>>> --- >>>> t = new java.awt.geom.AffineTransform(); >>>> t.scale(sx, sy); >>>> t.translate(tx, ty); >>>> --- >>>> t = new java.awt.geom.AffineTransform(); >>>> tmp = new java.awt.geom.AffineTransform(); >>>> tmp.setToScale(sx, sy); >>>> t.concatenate(tmp); >>>> tmp.setToTranslate(tx, ty); >>>> t.concatenate(tmp); >>>> --- >>>> Node n...; >>>> Group g = new Group(n); >>>> g.setScale(sx, sy); >>>> n.setTranslate(tx, ty); >>>> -------------- >>>> >>>> We also have the fact that "preConcatenate()" is mathematically >>>> reversed, and also inside-out from the perspective of what is being >>>> manipluated, as compared to concatenate(). >>>> >>>> So, if "appendFoo(...)" was essentially equivalent to: >>>> >>>> - Node.getTransforms().add(new Foo(...)); >>>> - t.foo(...); >>>> - t.concatenate(tmp.setToFoo(...)); >>>> >>>> and "prependFoo(...)" was essentially equivalent to: >>>> >>>> - Node.getTransforms().add(0, new Foo(...)); >>>> - we don't have a Java2D reverse for t.foo(); >>>> - t.preConcatenate(tmp.setToFoo(...)); >>>> >>>> then I could be happy. It may not have complete unambiguity in an >>>> absolute sense, but it would at least establish an internal >>>> consistency and harmony of naming conventions with respect to the >>>> JavaFX Node transform attributes and with the prior art in the Java >>>> geometry family (AffineTransform)... >>>> >>>> I feel that append, while we can argue the semantics of what it might >>>> mean mathematically, sounds like the more natural verb of the two >>>> forms of methods (comparing appendFoo to prependFoo), and in general >>>> it is the set of methods that they probably want to be using if they >>>> come from Java2D, or if they are writing code that takes a transform >>>> from somewhere else that defines their "transformation context" and >>>> they want to work within that (if you prepend, then you override the >>>> context someone set up for you, if you append, then you take their >>>> context and work relative to it). >>>> >>>> Is that what was being proposed before I came in and stomped on the >>>> discussion? >>>> >>>> ...jim >>>> >>> >> >> From martin.desruisseaux at geomatys.fr Tue Jul 24 03:57:57 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 24 Jul 2012 12:57:57 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500E7C9B.2030404@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> <500D3D37.9050207@oracle.com> <500DC9F1.1010406@oracle.com> <500E7C9B.2030404@oracle.com> Message-ID: <500E7FB5.6030802@geomatys.fr> Le 24/07/12 12:44, Pavel Safrata a ?crit : > The MAT was introduced because there is no obvious choice of the > default type. The 4x4 type forces you to always add four useless > values to your array (that have no corresponding members in the class > you are constructing). I agree that the described problem may occur. > So I think I'd rather get rid of the simple methods completely and > provide only the ones using MAT. We can on the other hand provide two > variants, one with the beginIndex, second without it. I agree that removing the simple methods would be safer. About the variants without 'beginIndex', is it really worth to duplicate maybe 4 methods just for saving "0," in method calls that are expected to be less frequent than other methods (translate, transform, etc.)? Martin From pavel.safrata at oracle.com Tue Jul 24 04:30:47 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Tue, 24 Jul 2012 13:30:47 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500E7FB5.6030802@geomatys.fr> References: <4FFC437E.2070505@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> <500D3D37.9050207@oracle.com> <500DC9F1.1010406@oracle.com> <500E7C9B.2030404@oracle.com> <500E7FB5.6030802@geomatys.fr> Message-ID: <500E8767.60000@oracle.com> On 24.7.2012 12:57, Martin Desruisseaux wrote: > Le 24/07/12 12:44, Pavel Safrata a ?crit : >> The MAT was introduced because there is no obvious choice of the >> default type. The 4x4 type forces you to always add four useless >> values to your array (that have no corresponding members in the class >> you are constructing). I agree that the described problem may occur. >> So I think I'd rather get rid of the simple methods completely and >> provide only the ones using MAT. We can on the other hand provide two >> variants, one with the beginIndex, second without it. > > I agree that removing the simple methods would be safer. About the > variants without 'beginIndex', is it really worth to duplicate maybe 4 > methods just for saving "0," in method calls that are expected to be > less frequent than other methods (translate, transform, etc.)? > Right, probably not. Thanks, Pavel > Martin > From pedro.duquevieira at gmail.com Tue Jul 24 05:04:59 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 24 Jul 2012 13:04:59 +0100 Subject: Affine transforms - matrix algebra Message-ID: Hi again my fellow javafx Gurus, I remembered it could also be interesting to have: Point3D: - public Vector3D subtract(Point3D) Subtracting 2 points, gives you a vector which in turn can be used to calculate the distance between the 2 points and the direction. - public void add(Vector3D) Translates the Point by the given vector Vector3D: -double angle(Vector3d v1) Returns the angle between this vector and the vector parameter -void crossProduct(Vector3d v1, Vector3d v2) Sets this vector to the vector cross product of vectors v1 and v2. - double dotProduct(Vector3d v1) Returns the dot product of this vector and vector v1. - double length() Returns the length of this vector. - void normalize() Normalizes this vector Thanks, best regards, -- Pedro Duque Vieira From leonid.popov at oracle.com Tue Jul 24 07:13:02 2012 From: leonid.popov at oracle.com (Leonid Popov) Date: Tue, 24 Jul 2012 18:13:02 +0400 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <500D972D.6080009@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> <004501cd68fc$0c29b680$247d2380$@com.au> <500D972D.6080009@oracle.com> Message-ID: <500EAD6E.80207@oracle.com> So, here's a proposed API change for WebView with zoom instead of scale: class javafx.scene.web.WebView { /** * Zoom factor applied to the Web page. The zoom affects logical bounds * of the Web page, but not bounds of the {@code WebView} node. * * @defaultValue 1.0 */ public final void setZoom(double value); public final double getZoom(); public DoubleProperty zoomProperty(); } If no objections come, I'll prepare a changeset soon. Thanks, Leonid On 7/23/2012 10:25 PM, Kevin Rushforth wrote: > Kirill already answered the question of its being a node property: > Node already has xScale and yScale properties...this is something > subtly different. > > I think either zoom or zoomFactor would be fine (I would note that > zoom is shorter, so might be better if it won't be confusing). > > -- Kevin > > > John C. Turnbull wrote: >> Just "zoomProperty" sounds right but, as I said, I think it should be at >> Node level so that other node types can use it too, especially ImageView and >> graphics nodes. It should zoom the contents only (not the scroll bars >> though the latter should update accordingly to reflect the changes in the >> dimensions of the content and the new relative position). >> >> -jct >> >> -----Original Message----- >> From:openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter >> Zhelezniakov >> Sent: Monday, 23 July 2012 19:21 >> To: Leonid Popov >> Cc:openjfx-dev at openjdk.java.net; Sergey Malenkov >> Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) >> >> On 07/20/12 20:14, Leonid Popov wrote: >> >>> It sounds reasonable, assuming that scaleX/scaleY have slightly >>> different semantics (they apply to the whole view, including >>> scrollbars, while the proposed property should affect WebView contents >>> only). Any other opinions on scale vs. zoom? >>> >> >> I named it scaleProperty for consistency as we already had >> fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive >> than 'scale'. I don't have strong preference now. >> >> Should we name it just zoomProperty, or maybe zoomFactorProperty? Native >> speakers please advise! >> >> Thanks! >> -- >> Peter >> >> From hang.vo at oracle.com Tue Jul 24 08:04:30 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 24 Jul 2012 15:04:30 +0000 Subject: hg: openjfx/2.2/graphics/rt: [DOC-ONLY]: RT-23402: minor improvement to SwipeEvent and GestureEvent doc. Message-ID: <20120724150434.E1B03471D3@hg.openjdk.java.net> Changeset: 15b6051f1219 Author: Pavel Safrata Date: 2012-07-24 16:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/15b6051f1219 [DOC-ONLY]: RT-23402: minor improvement to SwipeEvent and GestureEvent doc. ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/SwipeEvent.java From thoughtslinger at gmail.com Tue Jul 24 09:31:34 2012 From: thoughtslinger at gmail.com (Rick Walker) Date: Tue, 24 Jul 2012 12:31:34 -0400 Subject: Auto-update of native application bundles Message-ID: Auto-Updater Feedback / Wishlist: We are keenly interested in the auto-updater and we greatly appreciate the efforts of all, especially Igor and Daniel. We anticipate posting app updates on a tight cycle ? a week or two will be routine. So a clean, reliable auto-updater will make our users? lives vastly simpler. Our app will require the user to log in and authenticate before launching the auto-updater. We would prefer to zip up our latest app jars and post to a predetermined location on our server. If the JRE does not change with an update, the updater should ignore it and retrieve only our app jars and/or updated T&C (see below). Regarding jar signing, we expect to retrieve our app jars from our server. Even though we generally sign jars, we do not imagine performing a jar-signing check with each auto-update. We want to be able to tightly control auto-updates - we may ask users to pay for some updates. We are concerned that, by placing our jars at a url accessible to the auto-updater, we might also be inadvertently exposing them to anyone who might point a browser at the same url. Adding some level of indirection might help. Regarding updates to Terms and Conditions or EULA, it would be a great advantage to post an RTF (perhaps with a version number included in the file name) alongside our updated app jars so that the updater could determine whether the user ought to view and agree to the new T&C. I believe we include an RTF on the installer side (with NSIS or Inno) so it?s no extra work to also post it for the updater. We also routinely post updated T&C on our website, so I suppose a simple alternative might be for the auto-updater to simply point to that url. >From our perspective, it seems there are three components in play for the updater, each separately tracked for current version: the JRE, our app jars, and the T&C. Regarding user notification, we plan to use auto-updating to make sure that all users are using the same version of our app ? just as if we deployed as an applet. User notification can therefore be bare bones ? ?a required update is now available?. A "what's changed" document isn't required in our case. The download display can be modal ? there is no need for the download to take place in the background. An incremental progress indicator would be nicer than an indeterminate display. Graceful recovery in the event of a failure state (stalled download, file i/o probs etc) is of course essential. Cheers to all, Rick From hang.vo at oracle.com Tue Jul 24 09:33:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 24 Jul 2012 16:33:37 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120724163342.6209E471D6@hg.openjdk.java.net> Changeset: 4e47913d1062 Author: hudson Date: 2012-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4e47913d1062 Added tag 2.2-b18 for changeset 7839d55ac4c0 ! .hgtags Changeset: f724f741f885 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-07-24 09:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f724f741f885 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt From james.graham at oracle.com Tue Jul 24 10:01:09 2012 From: james.graham at oracle.com (Jim Graham) Date: Tue, 24 Jul 2012 10:01:09 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <500E7C9B.2030404@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500D22EB.3040109@geomatys.fr> <500D3D37.9050207@oracle.com> <500DC9F1.1010406@oracle.com> <500E7C9B.2030404@oracle.com> Message-ID: <500ED4D5.70202@oracle.com> On 7/24/2012 3:44 AM, Pavel Safrata wrote: >> With respect to methods that don't take a MAT type - I think we should >> simply say that the default is MAT_4x4 rather than infer it from the >> size of the array - that is cleaner and avoids mistakes where they >> forgot how big their array was (as in, they allocated a temp array and >> left it around for future use and some other programmer came in and >> decided that the array should be bigger without noticing that it >> affects the values that the former code would get)... > > The MAT was introduced because there is no obvious choice of the default > type. The 4x4 type forces you to always add four useless values to your > array (that have no corresponding members in the class you are > constructing). I agree that the described problem may occur. So I think > I'd rather get rid of the simple methods completely and provide only the > ones using MAT. We can on the other hand provide two variants, one with > the beginIndex, second without it. I'm OK with no default methods, but perhaps if the default were 3x4 then there would be fewer "wasted" values? I went with 4x4 as the fullest version, but 3x4 would be the "fullest within the sense of how many entries FX uses". But, either way, I'm OK with no defaults - I just didn't want the decision to be made because of those extra 4 values alone... ...jim From james.graham at oracle.com Tue Jul 24 10:12:20 2012 From: james.graham at oracle.com (Jim Graham) Date: Tue, 24 Jul 2012 10:12:20 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <500E7EE0.9030005@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500DCA17.6050705@oracle.com> <500E7EE0.9030005@oracle.com> Message-ID: <500ED774.8020007@oracle.com> On 7/24/2012 3:54 AM, Pavel Safrata wrote: > inverseTransform: > currently you can do createInverse().transform(...) > I think it may be better to leave it like that because inversion is an > expensive operation and user now has to control how often is it called > and when the inverted matrix can be gc'd. If we introduced some > convenience method we would probably need some inverse matrix caching > (with considerable space requirements). But this is already second > request so it might be worth it. Any other opinions? For some transforms the inversion is trivial so creating the object is fairly expensive. For example, if it is translation-only then the inverseTransform is simply subtracting a bunch of values from the points in question. Many other 2D transforms are not that expensive to calculate "on the fly" for small numbers of points and you can save an object creation. > deltaTransform: > this discussion goes on under "Transform point using > localToSceneTransform" subject. Please join there. Ah, I see it came up there. I'm neutral on whether we need Vector or not (not really a 3d-background person, but I see the point). But, whether we have a Vector class and whether it makes sense to interpret transform(Vector) as a delta transform, I think we need deltaTransform to mirror the existing cases because sometimes you want the non-translated transform for other cases as well. My gut feel is that if we have Vector then rather than having a "transform(Vector)" method that does a delta transform we should simply name its method "deltaTransform(Vector)" and maybe decide not to have a "transform(Vector)" method at all - that way we don't have conflicting operations for the "transform" name... ...jim From james.graham at oracle.com Tue Jul 24 10:14:42 2012 From: james.graham at oracle.com (Jim Graham) Date: Tue, 24 Jul 2012 10:14:42 -0700 Subject: Transform point using localToSceneTransform In-Reply-To: <500E78F5.5090107@oracle.com> References: <500E78F5.5090107@oracle.com> Message-ID: <500ED802.2090301@oracle.com> I've already commented on this in the matrix algebra thread, but I wanted to throw into this discussion the following point: I'm neutral on whether or not we need Vector - I'll leave that to the people with extensive 3D experience to comment. But, if transformation of vectors makes better sense to do a delta transform, and if we are adding deltaTransform() methods for other types (which I think we should do), then I think the "transform" method that does a "delta transform" on a Vector should actually be named "deltaTransform" for consistency, even if it is obvious that a vector should only be transformed that way... ...jim On 7/24/2012 3:29 AM, Pavel Safrata wrote: > > On 23.7.2012 17:47, Pedro Duque Vieira wrote: >>>> 1- public Vector3D transform(Vector3D point) >>>> >>>> This implies having a Vector class which I think is appropriate. Vector >>>> objects may be used to represent translation, surface normals, pick >>>> rays, >>>> or other things >>> Is the existing Point3D not sufficient? >> >> No. Imagine someone reading a piece of code that represents surface >> normals >> and pick rays as a Point3D, not very understandable. Also it's useful to >> compute angles between vectors, cross product, magnitude of the >> vector, ... >> >> > > We already use Point3D as a vector. It seems that publicly it's > currently only in Rotate - as rotation axis. So we can either continue > to do that - J2D does this as well - and possibly provide the vector > methods in Point3D, or we need to introduce new Vector3D and Vector2D > and deprecate the now wrong Point3D usage in Rotate. To me it seems it > might really be clearer to introduce the vectors, but I think Richard > should comment when abandoning old API comes to play.. > > Thanks, > Pavel From richard.bair at oracle.com Tue Jul 24 10:42:12 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 24 Jul 2012 10:42:12 -0700 Subject: Affine transforms - matrix algebra In-Reply-To: <500ED774.8020007@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFC5A02.8040709@geomatys.fr> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500DCA17.6050705@oracle.com> <500E7EE0.9030005@oracle.com> <500ED774.8020007@o! racle.com> Message-ID: <0A0B979C-98D7-4415-A823-6DB002D419A7@oracle.com> > Ah, I see it came up there. I'm neutral on whether we need Vector or not (not really a 3d-background person, but I see the point) Haha, I see what you did there ;-) From hang.vo at oracle.com Tue Jul 24 10:48:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 24 Jul 2012 17:48:34 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120724174837.A53BF471D7@hg.openjdk.java.net> Changeset: b64bf5349e9e Author: "Joseph Andresen" Date: 2012-07-24 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b64bf5349e9e [JavaDoc] RT-21004 Canvas JavaDoc ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: eee434a2e013 Author: "Joseph Andresen" Date: 2012-07-24 10:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/eee434a2e013 [JavaDoc] RT-22655 ImagePattern JavaDoc ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java From richard.bair at oracle.com Tue Jul 24 10:56:29 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 24 Jul 2012 10:56:29 -0700 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <500EAD6E.80207@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> <004501cd68fc$0c29b680$247d2380$@com.au> <500D972D.6080009@oracle.com> <500EAD6E.80207@oracle.com> Message-ID: <3A7FE63C-0C31-4B49-B077-4E4CEFE6EB3B@oracle.com> Make sure the "zoomProperty" method is also final. What is the issue number again? Thanks! On Jul 24, 2012, at 7:13 AM, Leonid Popov wrote: > So, here's a proposed API change for WebView with zoom instead of scale: > > class javafx.scene.web.WebView { > /** > * Zoom factor applied to the Web page. The zoom affects logical bounds > * of the Web page, but not bounds of the {@code WebView} node. > * > * @defaultValue 1.0 > */ > public final void setZoom(double value); > public final double getZoom(); > public DoubleProperty zoomProperty(); > } > > If no objections come, I'll prepare a changeset soon. > > Thanks, > Leonid > > On 7/23/2012 10:25 PM, Kevin Rushforth wrote: >> Kirill already answered the question of its being a node property: Node already has xScale and yScale properties...this is something subtly different. >> >> I think either zoom or zoomFactor would be fine (I would note that zoom is shorter, so might be better if it won't be confusing). >> >> -- Kevin >> >> >> John C. Turnbull wrote: >>> Just "zoomProperty" sounds right but, as I said, I think it should be at >>> Node level so that other node types can use it too, especially ImageView and >>> graphics nodes. It should zoom the contents only (not the scroll bars >>> though the latter should update accordingly to reflect the changes in the >>> dimensions of the content and the new relative position). >>> >>> -jct >>> >>> -----Original Message----- >>> From:openjfx-dev-bounces at openjdk.java.net >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter >>> Zhelezniakov >>> Sent: Monday, 23 July 2012 19:21 >>> To: Leonid Popov >>> Cc:openjfx-dev at openjdk.java.net; Sergey Malenkov >>> Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) >>> >>> On 07/20/12 20:14, Leonid Popov wrote: >>> >>>> It sounds reasonable, assuming that scaleX/scaleY have slightly >>>> different semantics (they apply to the whole view, including >>>> scrollbars, while the proposed property should affect WebView contents >>>> only). Any other opinions on scale vs. zoom? >>>> >>> >>> I named it scaleProperty for consistency as we already had >>> fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive >>> than 'scale'. I don't have strong preference now. >>> >>> Should we name it just zoomProperty, or maybe zoomFactorProperty? Native >>> speakers please advise! >>> >>> Thanks! >>> -- >>> Peter >>> >>> > From hang.vo at oracle.com Tue Jul 24 11:03:33 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 24 Jul 2012 18:03:33 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120724180336.89154471D8@hg.openjdk.java.net> Changeset: 981229961e87 Author: kcr Date: 2012-07-24 10:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/981229961e87 Revert unintended change to Canvas.java in changeset b64bf5349e9e ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java Changeset: dbbe8fbc5a1b Author: kcr Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/dbbe8fbc5a1b [DOC-ONLY] RT-21572: Improve api docs for snapshot ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/SnapshotParameters.java ! javafx-ui-common/src/javafx/scene/SnapshotResult.java From leonid.popov at oracle.com Tue Jul 24 11:16:16 2012 From: leonid.popov at oracle.com (Leonid Popov) Date: Tue, 24 Jul 2012 22:16:16 +0400 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <3A7FE63C-0C31-4B49-B077-4E4CEFE6EB3B@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> <004501cd68fc$0c29b680$247d2380$@com.au> <500D972D.6080009@oracle.com> <500EAD6E.80207@oracle.com> <3A7FE63C-0C31-4B49-B077-4E4CEFE6EB3B@oracle.com> Message-ID: <500EE670.3070902@oracle.com> The issue is at http://javafx-jira.kenai.com/browse/RT-21499 I noticed that other similar methods of WebView, like fontScaleProperty() or minWidthProperty(), are not final. Should I made them final as well? Thanks, Leonid On 7/24/2012 9:56 PM, Richard Bair wrote: > Make sure the "zoomProperty" method is also final. > > What is the issue number again? > > Thanks! > > On Jul 24, 2012, at 7:13 AM, Leonid Popov wrote: > >> So, here's a proposed API change for WebView with zoom instead of scale: >> >> class javafx.scene.web.WebView { >> /** >> * Zoom factor applied to the Web page. The zoom affects logical bounds >> * of the Web page, but not bounds of the {@code WebView} node. >> * >> * @defaultValue 1.0 >> */ >> public final void setZoom(double value); >> public final double getZoom(); >> public DoubleProperty zoomProperty(); >> } >> >> If no objections come, I'll prepare a changeset soon. >> >> Thanks, >> Leonid >> >> On 7/23/2012 10:25 PM, Kevin Rushforth wrote: >>> Kirill already answered the question of its being a node property: Node already has xScale and yScale properties...this is something subtly different. >>> >>> I think either zoom or zoomFactor would be fine (I would note that zoom is shorter, so might be better if it won't be confusing). >>> >>> -- Kevin >>> >>> >>> John C. Turnbull wrote: >>>> Just "zoomProperty" sounds right but, as I said, I think it should be at >>>> Node level so that other node types can use it too, especially ImageView and >>>> graphics nodes. It should zoom the contents only (not the scroll bars >>>> though the latter should update accordingly to reflect the changes in the >>>> dimensions of the content and the new relative position). >>>> >>>> -jct >>>> >>>> -----Original Message----- >>>> From:openjfx-dev-bounces at openjdk.java.net >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter >>>> Zhelezniakov >>>> Sent: Monday, 23 July 2012 19:21 >>>> To: Leonid Popov >>>> Cc:openjfx-dev at openjdk.java.net; Sergey Malenkov >>>> Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) >>>> >>>> On 07/20/12 20:14, Leonid Popov wrote: >>>> >>>>> It sounds reasonable, assuming that scaleX/scaleY have slightly >>>>> different semantics (they apply to the whole view, including >>>>> scrollbars, while the proposed property should affect WebView contents >>>>> only). Any other opinions on scale vs. zoom? >>>>> >>>> I named it scaleProperty for consistency as we already had >>>> fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive >>>> than 'scale'. I don't have strong preference now. >>>> >>>> Should we name it just zoomProperty, or maybe zoomFactorProperty? Native >>>> speakers please advise! >>>> >>>> Thanks! >>>> -- >>>> Peter >>>> >>>> From hang.vo at oracle.com Tue Jul 24 11:48:52 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 24 Jul 2012 18:48:52 +0000 Subject: hg: openjfx/2.2/graphics/rt: [DOC-ONLY] RT-23646: CSS ref for 2.2 still shows Version 2.1 in header, pushed on behalf of David Grieve Message-ID: <20120724184854.571EA471D9@hg.openjdk.java.net> Changeset: 76eefd67ced5 Author: kcr Date: 2012-07-24 11:31 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/76eefd67ced5 [DOC-ONLY] RT-23646: CSS ref for 2.2 still shows Version 2.1 in header, pushed on behalf of David Grieve ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html From richard.bair at oracle.com Tue Jul 24 11:52:12 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 24 Jul 2012 11:52:12 -0700 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <500EE670.3070902@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> <004501cd68fc$0c29b680$247d2380$@com.au> <500D972D.6080009@oracle.com> <500EAD6E.80207@oracle.com> <3A7FE63C-0C31-4B49-B077-4E4CEFE6EB3B@oracle.com> <500EE670.3070902@oracle.com> Message-ID: <364F2CF0-1981-461A-A09A-FFBD5E4E4A45@oracle.com> Every getter, setter, and property method should be final. Thanks Richard On Jul 24, 2012, at 11:16 AM, Leonid Popov wrote: > The issue is at > http://javafx-jira.kenai.com/browse/RT-21499 > > I noticed that other similar methods of WebView, like fontScaleProperty() or minWidthProperty(), are not final. Should I made them final as well? > > Thanks, > Leonid > > On 7/24/2012 9:56 PM, Richard Bair wrote: >> Make sure the "zoomProperty" method is also final. >> >> What is the issue number again? >> >> Thanks! >> >> On Jul 24, 2012, at 7:13 AM, Leonid Popov wrote: >> >>> So, here's a proposed API change for WebView with zoom instead of scale: >>> >>> class javafx.scene.web.WebView { >>> /** >>> * Zoom factor applied to the Web page. The zoom affects logical bounds >>> * of the Web page, but not bounds of the {@code WebView} node. >>> * >>> * @defaultValue 1.0 >>> */ >>> public final void setZoom(double value); >>> public final double getZoom(); >>> public DoubleProperty zoomProperty(); >>> } >>> >>> If no objections come, I'll prepare a changeset soon. >>> >>> Thanks, >>> Leonid >>> >>> On 7/23/2012 10:25 PM, Kevin Rushforth wrote: >>>> Kirill already answered the question of its being a node property: Node already has xScale and yScale properties...this is something subtly different. >>>> >>>> I think either zoom or zoomFactor would be fine (I would note that zoom is shorter, so might be better if it won't be confusing). >>>> >>>> -- Kevin >>>> >>>> >>>> John C. Turnbull wrote: >>>>> Just "zoomProperty" sounds right but, as I said, I think it should be at >>>>> Node level so that other node types can use it too, especially ImageView and >>>>> graphics nodes. It should zoom the contents only (not the scroll bars >>>>> though the latter should update accordingly to reflect the changes in the >>>>> dimensions of the content and the new relative position). >>>>> >>>>> -jct >>>>> >>>>> -----Original Message----- >>>>> From:openjfx-dev-bounces at openjdk.java.net >>>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter >>>>> Zhelezniakov >>>>> Sent: Monday, 23 July 2012 19:21 >>>>> To: Leonid Popov >>>>> Cc:openjfx-dev at openjdk.java.net; Sergey Malenkov >>>>> Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) >>>>> >>>>> On 07/20/12 20:14, Leonid Popov wrote: >>>>> >>>>>> It sounds reasonable, assuming that scaleX/scaleY have slightly >>>>>> different semantics (they apply to the whole view, including >>>>>> scrollbars, while the proposed property should affect WebView contents >>>>>> only). Any other opinions on scale vs. zoom? >>>>>> >>>>> I named it scaleProperty for consistency as we already had >>>>> fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive >>>>> than 'scale'. I don't have strong preference now. >>>>> >>>>> Should we name it just zoomProperty, or maybe zoomFactorProperty? Native >>>>> speakers please advise! >>>>> >>>>> Thanks! >>>>> -- >>>>> Peter >>>>> >>>>> > From richard.bair at oracle.com Tue Jul 24 12:01:23 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 24 Jul 2012 12:01:23 -0700 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <364F2CF0-1981-461A-A09A-FFBD5E4E4A45@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> <004501cd68fc$0c29b680$247d2380$@com.au> <500D972D.6080009@oracle.com> <500EAD6E.80207@oracle.com> <3A7FE63C-0C31-4B49-B077-4E4CEFE6EB3B@oracle.com> <500EE670.3070902@oracle.com> <364F2CF0-1981-461A-A09A-FFBD5E4E4A45@oracle.com> Message-ID: <50F7B1E7-AF68-4C70-A54C-7B2E93043806@oracle.com> BTW, adding final to methods is an incompatible change so all such changes have to be weighed and approved. Richard On Jul 24, 2012, at 11:52 AM, Richard Bair wrote: > Every getter, setter, and property method should be final. > > Thanks > Richard > > On Jul 24, 2012, at 11:16 AM, Leonid Popov wrote: > >> The issue is at >> http://javafx-jira.kenai.com/browse/RT-21499 >> >> I noticed that other similar methods of WebView, like fontScaleProperty() or minWidthProperty(), are not final. Should I made them final as well? >> >> Thanks, >> Leonid >> >> On 7/24/2012 9:56 PM, Richard Bair wrote: >>> Make sure the "zoomProperty" method is also final. >>> >>> What is the issue number again? >>> >>> Thanks! >>> >>> On Jul 24, 2012, at 7:13 AM, Leonid Popov wrote: >>> >>>> So, here's a proposed API change for WebView with zoom instead of scale: >>>> >>>> class javafx.scene.web.WebView { >>>> /** >>>> * Zoom factor applied to the Web page. The zoom affects logical bounds >>>> * of the Web page, but not bounds of the {@code WebView} node. >>>> * >>>> * @defaultValue 1.0 >>>> */ >>>> public final void setZoom(double value); >>>> public final double getZoom(); >>>> public DoubleProperty zoomProperty(); >>>> } >>>> >>>> If no objections come, I'll prepare a changeset soon. >>>> >>>> Thanks, >>>> Leonid >>>> >>>> On 7/23/2012 10:25 PM, Kevin Rushforth wrote: >>>>> Kirill already answered the question of its being a node property: Node already has xScale and yScale properties...this is something subtly different. >>>>> >>>>> I think either zoom or zoomFactor would be fine (I would note that zoom is shorter, so might be better if it won't be confusing). >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> John C. Turnbull wrote: >>>>>> Just "zoomProperty" sounds right but, as I said, I think it should be at >>>>>> Node level so that other node types can use it too, especially ImageView and >>>>>> graphics nodes. It should zoom the contents only (not the scroll bars >>>>>> though the latter should update accordingly to reflect the changes in the >>>>>> dimensions of the content and the new relative position). >>>>>> >>>>>> -jct >>>>>> >>>>>> -----Original Message----- >>>>>> From:openjfx-dev-bounces at openjdk.java.net >>>>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter >>>>>> Zhelezniakov >>>>>> Sent: Monday, 23 July 2012 19:21 >>>>>> To: Leonid Popov >>>>>> Cc:openjfx-dev at openjdk.java.net; Sergey Malenkov >>>>>> Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) >>>>>> >>>>>> On 07/20/12 20:14, Leonid Popov wrote: >>>>>> >>>>>>> It sounds reasonable, assuming that scaleX/scaleY have slightly >>>>>>> different semantics (they apply to the whole view, including >>>>>>> scrollbars, while the proposed property should affect WebView contents >>>>>>> only). Any other opinions on scale vs. zoom? >>>>>>> >>>>>> I named it scaleProperty for consistency as we already had >>>>>> fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive >>>>>> than 'scale'. I don't have strong preference now. >>>>>> >>>>>> Should we name it just zoomProperty, or maybe zoomFactorProperty? Native >>>>>> speakers please advise! >>>>>> >>>>>> Thanks! >>>>>> -- >>>>>> Peter >>>>>> >>>>>> >> > From philip.race at oracle.com Tue Jul 24 12:21:23 2012 From: philip.race at oracle.com (Phil Race) Date: Tue, 24 Jul 2012 12:21:23 -0700 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <50F7B1E7-AF68-4C70-A54C-7B2E93043806@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> <004501cd68fc$0c29b680$247d2380$@com.au> <500D972D.6080009@oracle.com> <500EAD6E.80207@oracle.com> <3A7FE63C-0C31-4B49-B077-4E4CEFE6EB3B@oracle.com> <500EE670.3070902@oracle.com> <364F2CF0-1981-461A-A09A-FFBD5E4E4A45@oracle.com> <50F7B1E7-AF68-4C70-A54C-7B2E93043806@oracle.com> Message-ID: <500EF5B3.6000004@oracle.com> In general, that is true. However, WebView is a final class, so it makes no difference, ie its not really a change at all, and definitely not an incompatible one. -phil. On 7/24/2012 12:01 PM, Richard Bair wrote: > BTW, adding final to methods is an incompatible change so all such changes have to be weighed and approved. > > Richard > > On Jul 24, 2012, at 11:52 AM, Richard Bair wrote: > >> Every getter, setter, and property method should be final. >> >> Thanks >> Richard >> >> On Jul 24, 2012, at 11:16 AM, Leonid Popov wrote: >> >>> The issue is at >>> http://javafx-jira.kenai.com/browse/RT-21499 >>> >>> I noticed that other similar methods of WebView, like fontScaleProperty() or minWidthProperty(), are not final. Should I made them final as well? >>> >>> Thanks, >>> Leonid >>> >>> On 7/24/2012 9:56 PM, Richard Bair wrote: >>>> Make sure the "zoomProperty" method is also final. >>>> >>>> What is the issue number again? >>>> >>>> Thanks! >>>> >>>> On Jul 24, 2012, at 7:13 AM, Leonid Popov wrote: >>>> >>>>> So, here's a proposed API change for WebView with zoom instead of scale: >>>>> >>>>> class javafx.scene.web.WebView { >>>>> /** >>>>> * Zoom factor applied to the Web page. The zoom affects logical bounds >>>>> * of the Web page, but not bounds of the {@code WebView} node. >>>>> * >>>>> * @defaultValue 1.0 >>>>> */ >>>>> public final void setZoom(double value); >>>>> public final double getZoom(); >>>>> public DoubleProperty zoomProperty(); >>>>> } >>>>> >>>>> If no objections come, I'll prepare a changeset soon. >>>>> >>>>> Thanks, >>>>> Leonid >>>>> >>>>> On 7/23/2012 10:25 PM, Kevin Rushforth wrote: >>>>>> Kirill already answered the question of its being a node property: Node already has xScale and yScale properties...this is something subtly different. >>>>>> >>>>>> I think either zoom or zoomFactor would be fine (I would note that zoom is shorter, so might be better if it won't be confusing). >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> John C. Turnbull wrote: >>>>>>> Just "zoomProperty" sounds right but, as I said, I think it should be at >>>>>>> Node level so that other node types can use it too, especially ImageView and >>>>>>> graphics nodes. It should zoom the contents only (not the scroll bars >>>>>>> though the latter should update accordingly to reflect the changes in the >>>>>>> dimensions of the content and the new relative position). >>>>>>> >>>>>>> -jct >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From:openjfx-dev-bounces at openjdk.java.net >>>>>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter >>>>>>> Zhelezniakov >>>>>>> Sent: Monday, 23 July 2012 19:21 >>>>>>> To: Leonid Popov >>>>>>> Cc:openjfx-dev at openjdk.java.net; Sergey Malenkov >>>>>>> Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) >>>>>>> >>>>>>> On 07/20/12 20:14, Leonid Popov wrote: >>>>>>> >>>>>>>> It sounds reasonable, assuming that scaleX/scaleY have slightly >>>>>>>> different semantics (they apply to the whole view, including >>>>>>>> scrollbars, while the proposed property should affect WebView contents >>>>>>>> only). Any other opinions on scale vs. zoom? >>>>>>>> >>>>>>> I named it scaleProperty for consistency as we already had >>>>>>> fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive >>>>>>> than 'scale'. I don't have strong preference now. >>>>>>> >>>>>>> Should we name it just zoomProperty, or maybe zoomFactorProperty? Native >>>>>>> speakers please advise! >>>>>>> >>>>>>> Thanks! >>>>>>> -- >>>>>>> Peter >>>>>>> >>>>>>> From richard.bair at oracle.com Tue Jul 24 12:21:15 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 24 Jul 2012 12:21:15 -0700 Subject: API REVIEW: WebView.scale property (for JavaFX 3.0 now) In-Reply-To: <500EF5B3.6000004@oracle.com> References: <4FAE5143.4080409@oracle.com> <50097808.4030205@oracle.com> <50097A8D.3030200@oracle.com> <500983DD.2040407@oracle.com> <500D1784.2060105@oracle.com> <004501cd68fc$0c29b680$247d2380$@com.au> <500D972D.6080009@oracle.com> <500EAD6E.80207@oracle.com> <3A7FE63C-0C31-4B49-B077-4E4CEFE6EB3B@oracle.com> <500EE670.3070902@oracle.com> <364F2CF0-1981-461A-A09A-FFBD5E4E4A45@oracle.com> <50F7B1E7-AF68-4C70-A54C-7B2E93043806@oracle.com> <500EF5B3.6000004@oracle.com> Message-ID: <26F22B00-4398-4C20-8728-D0AAD9C51FC5@oracle.com> Cool, thanks Phil! On Jul 24, 2012, at 12:21 PM, Phil Race wrote: > In general, that is true. However, WebView is a final class, so it makes no difference, > ie its not really a change at all, and definitely not an incompatible one. > > -phil. > > On 7/24/2012 12:01 PM, Richard Bair wrote: >> BTW, adding final to methods is an incompatible change so all such changes have to be weighed and approved. >> >> Richard >> >> On Jul 24, 2012, at 11:52 AM, Richard Bair wrote: >> >>> Every getter, setter, and property method should be final. >>> >>> Thanks >>> Richard >>> >>> On Jul 24, 2012, at 11:16 AM, Leonid Popov wrote: >>> >>>> The issue is at >>>> http://javafx-jira.kenai.com/browse/RT-21499 >>>> >>>> I noticed that other similar methods of WebView, like fontScaleProperty() or minWidthProperty(), are not final. Should I made them final as well? >>>> >>>> Thanks, >>>> Leonid >>>> >>>> On 7/24/2012 9:56 PM, Richard Bair wrote: >>>>> Make sure the "zoomProperty" method is also final. >>>>> >>>>> What is the issue number again? >>>>> >>>>> Thanks! >>>>> >>>>> On Jul 24, 2012, at 7:13 AM, Leonid Popov wrote: >>>>> >>>>>> So, here's a proposed API change for WebView with zoom instead of scale: >>>>>> >>>>>> class javafx.scene.web.WebView { >>>>>> /** >>>>>> * Zoom factor applied to the Web page. The zoom affects logical bounds >>>>>> * of the Web page, but not bounds of the {@code WebView} node. >>>>>> * >>>>>> * @defaultValue 1.0 >>>>>> */ >>>>>> public final void setZoom(double value); >>>>>> public final double getZoom(); >>>>>> public DoubleProperty zoomProperty(); >>>>>> } >>>>>> >>>>>> If no objections come, I'll prepare a changeset soon. >>>>>> >>>>>> Thanks, >>>>>> Leonid >>>>>> >>>>>> On 7/23/2012 10:25 PM, Kevin Rushforth wrote: >>>>>>> Kirill already answered the question of its being a node property: Node already has xScale and yScale properties...this is something subtly different. >>>>>>> >>>>>>> I think either zoom or zoomFactor would be fine (I would note that zoom is shorter, so might be better if it won't be confusing). >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> John C. Turnbull wrote: >>>>>>>> Just "zoomProperty" sounds right but, as I said, I think it should be at >>>>>>>> Node level so that other node types can use it too, especially ImageView and >>>>>>>> graphics nodes. It should zoom the contents only (not the scroll bars >>>>>>>> though the latter should update accordingly to reflect the changes in the >>>>>>>> dimensions of the content and the new relative position). >>>>>>>> >>>>>>>> -jct >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From:openjfx-dev-bounces at openjdk.java.net >>>>>>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Peter >>>>>>>> Zhelezniakov >>>>>>>> Sent: Monday, 23 July 2012 19:21 >>>>>>>> To: Leonid Popov >>>>>>>> Cc:openjfx-dev at openjdk.java.net; Sergey Malenkov >>>>>>>> Subject: Re: API REVIEW: WebView.scale property (for JavaFX 3.0 now) >>>>>>>> >>>>>>>> On 07/20/12 20:14, Leonid Popov wrote: >>>>>>>> >>>>>>>>> It sounds reasonable, assuming that scaleX/scaleY have slightly >>>>>>>>> different semantics (they apply to the whole view, including >>>>>>>>> scrollbars, while the proposed property should affect WebView contents >>>>>>>>> only). Any other opinions on scale vs. zoom? >>>>>>>>> >>>>>>>> I named it scaleProperty for consistency as we already had >>>>>>>> fontScaleProperty. OTOH I agree 'zoom' may sound more familiar and intuitive >>>>>>>> than 'scale'. I don't have strong preference now. >>>>>>>> >>>>>>>> Should we name it just zoomProperty, or maybe zoomFactorProperty? Native >>>>>>>> speakers please advise! >>>>>>>> >>>>>>>> Thanks! >>>>>>>> -- >>>>>>>> Peter >>>>>>>> >>>>>>>> > From pedro.duquevieira at gmail.com Tue Jul 24 15:55:43 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 24 Jul 2012 23:55:43 +0100 Subject: Transform point using localToSceneTransform Message-ID: Hi, > I've already commented on this in the matrix algebra thread, but I > wanted to throw into this discussion the following point: > I'm neutral on whether or not we need Vector - I'll leave that to the > people with extensive 3D experience to comment. But, if transformation > of vectors makes better sense to do a delta transform, and if we are > adding deltaTransform() methods for other types (which I think we should > do), then I think the "transform" method that does a "delta transform" > on a Vector should actually be named "deltaTransform" for consistency, > even if it is obvious that a vector should only be transformed that way... > I don't know what a delta transform is (never used it on my 3d work background), so I cannot comment on that part. All I can say is that I did use transform a vector by a given matrix transform and it makes sense. It's basically a multiplication of a 4x4 matrix transform with a 1x4 matrix, just like what happens when you transform a point3d. So I think: - void transform(Vector3d) Should be present on the transform3d class. Just my 2 cents, -- Pedro Duque Vieira From james.graham at oracle.com Tue Jul 24 16:06:23 2012 From: james.graham at oracle.com (Jim Graham) Date: Tue, 24 Jul 2012 16:06:23 -0700 Subject: Transform point using localToSceneTransform In-Reply-To: References: Message-ID: <500F2A6F.5050401@oracle.com> Hi Pedro, delta transform is transform without translation. It is primarily used to transform magnitudes that have no position so you only modify them with the scale, shear, and rotation aspects of the matrix (i.e. everything but the translate components). For some reason I got the impression that Vector was only used to represent magnitude because people were bringing up delta transforms in the context of talking about it. If it is a 1x4 vector then it is just Point3D+perspective-w-element, [x,y,z,w] no? Point3D can participate in 4x4 transforms, supplying an implicit w=1 component, though it can't store the resulting w component if the matrix doesn't have 0,0,0,1 for the last 4 elements (i.e. in perspective camera matrices)... ...jim On 7/24/2012 3:55 PM, Pedro Duque Vieira wrote: > Hi, > > >> I've already commented on this in the matrix algebra thread, but I >> wanted to throw into this discussion the following point: >> I'm neutral on whether or not we need Vector - I'll leave that to the >> people with extensive 3D experience to comment. But, if transformation >> of vectors makes better sense to do a delta transform, and if we are >> adding deltaTransform() methods for other types (which I think we should >> do), then I think the "transform" method that does a "delta transform" >> on a Vector should actually be named "deltaTransform" for consistency, >> even if it is obvious that a vector should only be transformed that way... >> > > > I don't know what a delta transform is (never used it on my 3d work > background), so I cannot comment on that part. > All I can say is that I did use transform a vector by a given matrix > transform and it makes sense. It's basically a multiplication of a 4x4 > matrix transform with a 1x4 matrix, just like what happens when you > transform a point3d. > So I think: > - void transform(Vector3d) > Should be present on the transform3d class. > > Just my 2 cents, > From pedro.duquevieira at gmail.com Tue Jul 24 16:34:25 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 25 Jul 2012 00:34:25 +0100 Subject: Transform point using localToSceneTransform In-Reply-To: <500F2A6F.5050401@oracle.com> References: <500F2A6F.5050401@oracle.com> Message-ID: Hi Jim, Maybe we're talking about two different ways of performing the same calculations, probably we come from different backgrounds. What I meant with Vector3d is a 4x1 matrix with the last element as 0 (homogeneous coordinates). We can then have methods on the Vector3d class to give us things we expect to retrieve from vectors: like angle, magnitude, doing the cross product of two vectors, calculating the angle between two vectors. As a reference one can look at the java3d implementation of Vector3d: http://docs.oracle.com/cd/E17802_01/j2se/javase/technologies/desktop/java3d/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/Transform3D.html Thanks, best regards, On Wed, Jul 25, 2012 at 12:06 AM, Jim Graham wrote: > Hi Pedro, > > delta transform is transform without translation. It is primarily used to > transform magnitudes that have no position so you only modify them with the > scale, shear, and rotation aspects of the matrix (i.e. everything but the > translate components). > > For some reason I got the impression that Vector was only used to > represent magnitude because people were bringing up delta transforms in the > context of talking about it. If it is a 1x4 vector then it is just > Point3D+perspective-w-element, [x,y,z,w] no? Point3D can participate in > 4x4 transforms, supplying an implicit w=1 component, though it can't store > the resulting w component if the matrix doesn't have 0,0,0,1 for the last 4 > elements (i.e. in perspective camera matrices)... > > ...jim > > > On 7/24/2012 3:55 PM, Pedro Duque Vieira wrote: > >> Hi, >> >> >> I've already commented on this in the matrix algebra thread, but I >>> wanted to throw into this discussion the following point: >>> I'm neutral on whether or not we need Vector - I'll leave that to the >>> people with extensive 3D experience to comment. But, if transformation >>> of vectors makes better sense to do a delta transform, and if we are >>> adding deltaTransform() methods for other types (which I think we should >>> do), then I think the "transform" method that does a "delta transform" >>> on a Vector should actually be named "deltaTransform" for consistency, >>> even if it is obvious that a vector should only be transformed that >>> way... >>> >>> >> >> I don't know what a delta transform is (never used it on my 3d work >> background), so I cannot comment on that part. >> All I can say is that I did use transform a vector by a given matrix >> transform and it makes sense. It's basically a multiplication of a 4x4 >> matrix transform with a 1x4 matrix, just like what happens when you >> transform a point3d. >> So I think: >> - void transform(Vector3d) >> Should be present on the transform3d class. >> >> Just my 2 cents, >> >> -- Pedro Duque Vieira From pavel.safrata at oracle.com Wed Jul 25 05:01:25 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 25 Jul 2012 14:01:25 +0200 Subject: Affine transforms - matrix algebra In-Reply-To: <500ED774.8020007@oracle.com> References: <4FFC437E.2070505@oracle.com> <4FFD946B.1070905@oracle.com> <4FFDD57F.5070109@oracle.com> <4FFDDF64.7020902@oracle.com> <4FFE0A2E.7030009@oracle.com> <4FFE7024.2090603@oracle.com> <4FFEEA21.2050907@oracle.com> <4FFF07F1.2050108@geomatys.fr> <4FFF0C68.6020707@oracle.com> <4FFF2E90.8080004@geomatys.fr> <4FFF3836.8080704@oracle.com> <4FFF3F4D.1010203@geomatys.fr> <5003F459.7030304@oracle.com> <5003FADE.8040408@oracle.com> <5003FCE6.2010701@oracle.com> <8B653950-2D1A-4E49-9A0C-E458E08B4AC3@oracle.com> <5004E53B.3060108@oracle.com> <50053059.8020702@geomatys.fr> <5005ACD4.7040500@oracle.com> <5005B3C5.3030307@oracle.com> <5005B986.9010008@oracle.com> <5005C506.7030102@geomatys.fr> <5006516E.4030108@oracle.com> <5008709D.8030602@oracle.com> <50087915.5060201@geomatys.fr> <5009F187.4030002@oracle.com> <5009FD42.6080200@geomatys.fr> <500D155C.3000906@oracle.com> <500DCA17.6050705@oracle.com> <500E7EE0.9030005@oracle.com> <500ED774.8020007@oracle.com> Message-ID: <500FE015.6000702@oracle.com> On 24.7.2012 19:12, Jim Graham wrote: > On 7/24/2012 3:54 AM, Pavel Safrata wrote: >> inverseTransform: >> currently you can do createInverse().transform(...) >> I think it may be better to leave it like that because inversion is an >> expensive operation and user now has to control how often is it called >> and when the inverted matrix can be gc'd. If we introduced some >> convenience method we would probably need some inverse matrix caching >> (with considerable space requirements). But this is already second >> request so it might be worth it. Any other opinions? > > For some transforms the inversion is trivial so creating the object is > fairly expensive. For example, if it is translation-only then the > inverseTransform is simply subtracting a bunch of values from the > points in question. Many other 2D transforms are not that expensive > to calculate "on the fly" for small numbers of points and you can save > an object creation. Fair enough. Let's add inverseTransform(...) for each transform(...). For the transforms with complicated inversion we can create and cache the inverted transform (probably soft-referenced). Thanks, Pavel > >> deltaTransform: >> this discussion goes on under "Transform point using >> localToSceneTransform" subject. Please join there. > > Ah, I see it came up there. I'm neutral on whether we need Vector or > not (not really a 3d-background person, but I see the point). But, > whether we have a Vector class and whether it makes sense to interpret > transform(Vector) as a delta transform, I think we need deltaTransform > to mirror the existing cases because sometimes you want the > non-translated transform for other cases as well. My gut feel is that > if we have Vector then rather than having a "transform(Vector)" method > that does a delta transform we should simply name its method > "deltaTransform(Vector)" and maybe decide not to have a > "transform(Vector)" method at all - that way we don't have conflicting > operations for the "transform" name... (will continue in the other thread) > > ...jim From sebastian.rheinnecker at yworks.com Wed Jul 25 05:23:39 2012 From: sebastian.rheinnecker at yworks.com (Sebastian Rheinnecker) Date: Wed, 25 Jul 2012 14:23:39 +0200 Subject: JavaFX nodes getting desynced Message-ID: <500FE54B.7000403@yworks.com> Hi, we experience a strange bug when using a custom animation in which the nodes of the SceneGraph are not really at the position they are meant to be (or there at all). I posted the detailled description in the OTN forums including a link to the application and screencasts to point out the bug: https://forums.oracle.com/forums/thread.jspa?threadID=2417478&tstart=15 We'd be very glad if someone from the dev team could point us to something helpful. kind regards, -- Sebastian Rheinnecker phone: +49 7071 9709050 fax: +49 7071 9709051 yWorks GmbH Vor dem Kreuzberg 28 72070 Tuebingen Germany http://www.yworks.com Managing Directors: Sebastian M?ller, Michael Pfahler Commercial Registry: Stuttgart, Germany, HRB 382340 From pavel.safrata at oracle.com Wed Jul 25 06:54:19 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 25 Jul 2012 15:54:19 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: References: <500F2A6F.5050401@oracle.com> Message-ID: <500FFA8B.30703@oracle.com> I think that if we define Vector*D as the class that represents magnitudes without position, and we use it for our magnitudes without position, we don't need any deltaTransforms, do we? Richard, what do you think about introducing Vector2D and Vector3D? I think the classes would be nice (to distinguish between specific points in space and magnitudes without position) but we would have to deprecate methods in Rotate that use Point3D as rotation axis and introduce different ones that use Vector3D, we would also need to deprecate the static axes defined in this class and define vector ones with different names.. Thanks, Pavel On 25.7.2012 1:34, Pedro Duque Vieira wrote: > Hi Jim, > > Maybe we're talking about two different ways of performing the same > calculations, probably we come from different backgrounds. > > What I meant with Vector3d is a 4x1 matrix with the last element as 0 > (homogeneous coordinates). We can then have methods on the Vector3d class > to give us things we expect to retrieve from vectors: like angle, > magnitude, doing the cross product of two vectors, calculating the angle > between two vectors. > As a reference one can look at the java3d implementation of Vector3d: > http://docs.oracle.com/cd/E17802_01/j2se/javase/technologies/desktop/java3d/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/Transform3D.html > > > Thanks, best regards, > > On Wed, Jul 25, 2012 at 12:06 AM, Jim Graham wrote: > >> Hi Pedro, >> >> delta transform is transform without translation. It is primarily used to >> transform magnitudes that have no position so you only modify them with the >> scale, shear, and rotation aspects of the matrix (i.e. everything but the >> translate components). >> >> For some reason I got the impression that Vector was only used to >> represent magnitude because people were bringing up delta transforms in the >> context of talking about it. If it is a 1x4 vector then it is just >> Point3D+perspective-w-element, [x,y,z,w] no? Point3D can participate in >> 4x4 transforms, supplying an implicit w=1 component, though it can't store >> the resulting w component if the matrix doesn't have 0,0,0,1 for the last 4 >> elements (i.e. in perspective camera matrices)... >> >> ...jim >> >> >> On 7/24/2012 3:55 PM, Pedro Duque Vieira wrote: >> >>> Hi, >>> >>> >>> I've already commented on this in the matrix algebra thread, but I >>>> wanted to throw into this discussion the following point: >>>> I'm neutral on whether or not we need Vector - I'll leave that to the >>>> people with extensive 3D experience to comment. But, if transformation >>>> of vectors makes better sense to do a delta transform, and if we are >>>> adding deltaTransform() methods for other types (which I think we should >>>> do), then I think the "transform" method that does a "delta transform" >>>> on a Vector should actually be named "deltaTransform" for consistency, >>>> even if it is obvious that a vector should only be transformed that >>>> way... >>>> >>>> >>> I don't know what a delta transform is (never used it on my 3d work >>> background), so I cannot comment on that part. >>> All I can say is that I did use transform a vector by a given matrix >>> transform and it makes sense. It's basically a multiplication of a 4x4 >>> matrix transform with a 1x4 matrix, just like what happens when you >>> transform a point3d. >>> So I think: >>> - void transform(Vector3d) >>> Should be present on the transform3d class. >>> >>> Just my 2 cents, >>> >>> > From pedro.duquevieira at gmail.com Wed Jul 25 07:08:00 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 25 Jul 2012 15:08:00 +0100 Subject: Mouse pressed on window when another window(popup) is active Message-ID: Hi, I was unsure whether to post this question/bug here or directly on Jira.. The thing is if a popup window is active, clicking the mouse button on the main window won't result in a: mouse pressed, mouse dragged, mouse released sequence of events being fired but only on a: mouse dragged, mouse released. Probably the mouse pressed is consumed when the main window becomes active and so it isn't passed on to the components inside that window. My question is: is this a bug or is this intended by design? In the future should I post this type of reports/questions directly to Jira or do I post them here? Best regards, thanks, -- Pedro Duque Vieira From pavel.safrata at oracle.com Wed Jul 25 07:38:02 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 25 Jul 2012 16:38:02 +0200 Subject: Mouse pressed on window when another window(popup) is active In-Reply-To: References: Message-ID: <501004CA.4040807@oracle.com> Hello Pedro, this is a bug, the events should always be properly paired. Please file a Jira issue. It's usually better to file a Jira issue right away, even if it's not a bug we have a publicly searchable record of it for future reference. Note that fixing the bug will probably lead to the main window getting no events from the gesture (the hiding popup will consume the whole gesture instead of just the pressed event). We've already chosen this approach when dealing with a similar issue: http://javafx-jira.kenai.com/browse/RT-16558 Thanks, Pavel On 25.7.2012 16:08, Pedro Duque Vieira wrote: > Hi, > > I was unsure whether to post this question/bug here or directly on Jira.. > The thing is if a popup window is active, clicking the mouse button on the > main window won't result in a: mouse pressed, mouse dragged, mouse released > sequence of events being fired but only on a: mouse dragged, mouse > released. Probably the mouse pressed is consumed when the main window > becomes active and so it isn't passed on to the components inside that > window. > > My question is: is this a bug or is this intended by design? > > In the future should I post this type of reports/questions directly to Jira > or do I post them here? > > Best regards, thanks, > From lubomir.nerad at oracle.com Wed Jul 25 07:50:33 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 25 Jul 2012 16:50:33 +0200 Subject: JavaFX nodes getting desynced In-Reply-To: <500FE54B.7000403@yworks.com> References: <500FE54B.7000403@yworks.com> Message-ID: <501007B9.9060902@oracle.com> Hi Sebastian, from my investigation it seems that your problem is another manifestation of the RT-23351 bug (http://javafx-jira.kenai.com/browse/RT-23351). I wasn't able to reproduce the problem on the runtime from the JavaFX 3.0 repository where the bug was fixed. To double-check you can try to use FixedGroup (or similarly patched layout containers) from Workaround.diff (attached to the RT-23351). Regards, Lubo On 7/25/2012 2:23 PM, Sebastian Rheinnecker wrote: > Hi, > > we experience a strange bug when using a custom animation in which the > nodes of the SceneGraph are not really at the position they are meant > to be (or there at all). > > I posted the detailled description in the OTN forums including a link > to the application and screencasts to point out the bug: > https://forums.oracle.com/forums/thread.jspa?threadID=2417478&tstart=15 > > We'd be very glad if someone from the dev team could point us to > something helpful. > > kind regards, > From richard.bair at oracle.com Wed Jul 25 08:54:30 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 25 Jul 2012 08:54:30 -0700 Subject: Transform point using localToSceneTransform In-Reply-To: <500FFA8B.30703@oracle.com> References: <500F2A6F.5050401@oracle.com> <500FFA8B.30703@oracle.com> Message-ID: <77DE75EA-EA4F-4F6C-9184-1A9737714066@oracle.com> Haha, you're going to make me read the thread :-) Generally speaking I'd prefer to just use Point3D vs. adding a Vector, primarily because we already made this decision several releases ago. Without having to read the whole thread, can you give a short summary of the impact using Point3D has vs. a class named Vector3D? Richard On Jul 25, 2012, at 6:54 AM, Pavel Safrata wrote: > I think that if we define Vector*D as the class that represents magnitudes without position, and we use it for our magnitudes without position, we don't need any deltaTransforms, do we? > > Richard, what do you think about introducing Vector2D and Vector3D? I think the classes would be nice (to distinguish between specific points in space and magnitudes without position) but we would have to deprecate methods in Rotate that use Point3D as rotation axis and introduce different ones that use Vector3D, we would also need to deprecate the static axes defined in this class and define vector ones with different names.. > > Thanks, > Pavel > > On 25.7.2012 1:34, Pedro Duque Vieira wrote: >> Hi Jim, >> >> Maybe we're talking about two different ways of performing the same >> calculations, probably we come from different backgrounds. >> >> What I meant with Vector3d is a 4x1 matrix with the last element as 0 >> (homogeneous coordinates). We can then have methods on the Vector3d class >> to give us things we expect to retrieve from vectors: like angle, >> magnitude, doing the cross product of two vectors, calculating the angle >> between two vectors. >> As a reference one can look at the java3d implementation of Vector3d: >> http://docs.oracle.com/cd/E17802_01/j2se/javase/technologies/desktop/java3d/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/Transform3D.html >> >> >> Thanks, best regards, >> >> On Wed, Jul 25, 2012 at 12:06 AM, Jim Graham wrote: >> >>> Hi Pedro, >>> >>> delta transform is transform without translation. It is primarily used to >>> transform magnitudes that have no position so you only modify them with the >>> scale, shear, and rotation aspects of the matrix (i.e. everything but the >>> translate components). >>> >>> For some reason I got the impression that Vector was only used to >>> represent magnitude because people were bringing up delta transforms in the >>> context of talking about it. If it is a 1x4 vector then it is just >>> Point3D+perspective-w-element, [x,y,z,w] no? Point3D can participate in >>> 4x4 transforms, supplying an implicit w=1 component, though it can't store >>> the resulting w component if the matrix doesn't have 0,0,0,1 for the last 4 >>> elements (i.e. in perspective camera matrices)... >>> >>> ...jim >>> >>> >>> On 7/24/2012 3:55 PM, Pedro Duque Vieira wrote: >>> >>>> Hi, >>>> >>>> >>>> I've already commented on this in the matrix algebra thread, but I >>>>> wanted to throw into this discussion the following point: >>>>> I'm neutral on whether or not we need Vector - I'll leave that to the >>>>> people with extensive 3D experience to comment. But, if transformation >>>>> of vectors makes better sense to do a delta transform, and if we are >>>>> adding deltaTransform() methods for other types (which I think we should >>>>> do), then I think the "transform" method that does a "delta transform" >>>>> on a Vector should actually be named "deltaTransform" for consistency, >>>>> even if it is obvious that a vector should only be transformed that >>>>> way... >>>>> >>>>> >>>> I don't know what a delta transform is (never used it on my 3d work >>>> background), so I cannot comment on that part. >>>> All I can say is that I did use transform a vector by a given matrix >>>> transform and it makes sense. It's basically a multiplication of a 4x4 >>>> matrix transform with a 1x4 matrix, just like what happens when you >>>> transform a point3d. >>>> So I think: >>>> - void transform(Vector3d) >>>> Should be present on the transform3d class. >>>> >>>> Just my 2 cents, >>>> >>>> >> > > From david.grieve at oracle.com Wed Jul 25 10:15:14 2012 From: david.grieve at oracle.com (David Grieve) Date: Wed, 25 Jul 2012 13:15:14 -0400 Subject: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager Message-ID: Background: This request is related to http://javafx-jira.kenai.com/browse/RT-23460. StyleManager's job it is to keep track of stylesheets, manage the cascade, and create StyleHelpers for nodes. StyleHelper is the code that applies css styles to nodes. Currently, there StyleManager is a singleton but it can manage stylesheets from many different scenes. To do this, it maintains a table that maps Scene to a StylesheetContainer which contains the list of declarations from all the stylesheets associated with the scene. RT-23460 seeks to eliminate the lookup of Scene to StylesheetContainer. One such way to do this is for Scene to own its StylesheetContainer, as is proposed in the bug report. Another way is to have Scene own its own StyleManager. This latter approach is preferred (well, by me at least) since it greatly reduces the complexity of StyleManager and makes other optimizations possible. Proposed changes: I propose adding a StyleManager member to Scene and moving StyleManager to the javafx.scene package as an abstract class with the minimum required public API. Scene would add: private final StyleManger styleManager; public final StyleManager getStyleManager() Because Scene would have public API that returns a StyleManager, StyleManager itself needs to be public API and would need to be moved from com.sun.javafx.css to javafx.scene I propose StyleManager's public API as: public abstract StyleHelper getStyleHelper(Node node) public final ObservableList getStylesheets() -- the list of stylesheet URL strings for the Scene. Scene's getStylesheets() method would simply return styleManager.getStylesheets() public void setDefaultUserAgentStylesheet(String url) public final void addDefaultUserAgentStylesheet(String url) -- support Controls that have their own UA stylesheet, plus adding UA stylesheets for embedded public final List getUserAgentStylesheets() - return immutable list of UA stylesheet URL strings Note that StyleManager returns a StyleHelper. Hence, StyleHelper would also need to be part of the public API. There are only two methods in StyleManager that need to be exposed public abstract void transitionToState() - this method is called from Node when css needs to be applied public abstract boolean isPseudoclassUsed(String pseudoclass) - this method is also called from node to determine whether or not the node's pseudo-class state would cause css to be applied Note that neither the proposed StyleManager API nor the StyleHelper API pull in any other API not already part of the public API. Having Scene own a StyleManager also has the benefit of being able to avoid looking up the parent chain to see if the scene's window is a popup or not. That logic can be moved to the constructor. With this change, StyleManager can be further streamlined by eliminating the StylesheetContainer (StylesheetContainer gets moved into the body of the StyleManagerImpl) and the defaultContainer. Further, since a Parent can also have stylesheets, I also propose adding StyleManager to Parent with the same API as in Scene. private final StyleManger styleManager; public final StyleManager getStyleManager() This will help eliminate the parent stylesheet lookup that currently happens in StylesheetContainer. David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From david.grieve at oracle.com Wed Jul 25 10:20:59 2012 From: david.grieve at oracle.com (David Grieve) Date: Wed, 25 Jul 2012 13:20:59 -0400 Subject: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager In-Reply-To: References: Message-ID: Formatting of this message is marginally better in the JIRA issue. On Jul 25, 2012, at 1:15 PM, David Grieve wrote: > Background: > This request is related to http://javafx-jira.kenai.com/browse/RT-23460. StyleManager's job it is to keep track of stylesheets, manage the cascade, and create StyleHelpers for nodes. StyleHelper is the code that applies css styles to nodes. > > Currently, there StyleManager is a singleton but it can manage stylesheets from many different scenes. To do this, it maintains a table that maps Scene to a StylesheetContainer which contains the list of declarations from all the stylesheets associated with the scene. RT-23460 seeks to eliminate the lookup of Scene to StylesheetContainer. One such way to do this is for Scene to own its StylesheetContainer, as is proposed in the bug report. Another way is to have Scene own its own StyleManager. This latter approach is preferred (well, by me at least) since it greatly reduces the complexity of StyleManager and makes other optimizations possible. > > Proposed changes: > > I propose adding a StyleManager member to Scene and moving StyleManager to the javafx.scene package as an abstract class with the minimum required public API. > > Scene would add: > private final StyleManger styleManager; > public final StyleManager getStyleManager() > > Because Scene would have public API that returns a StyleManager, StyleManager itself needs to be public API and would need to be moved from com.sun.javafx.css to javafx.scene > > I propose StyleManager's public API as: > public abstract StyleHelper getStyleHelper(Node node) > public final ObservableList getStylesheets() -- the list of stylesheet URL strings for the Scene. Scene's getStylesheets() method would simply return styleManager.getStylesheets() > public void setDefaultUserAgentStylesheet(String url) > public final void addDefaultUserAgentStylesheet(String url) -- support Controls that have their own UA stylesheet, plus adding UA stylesheets for embedded > public final List getUserAgentStylesheets() - return immutable list of UA stylesheet URL strings > Note that StyleManager returns a StyleHelper. Hence, StyleHelper would also need to be part of the public API. There are only two methods in StyleManager that need to be exposed > public abstract void transitionToState() - this method is called from Node when css needs to be applied > public abstract boolean isPseudoclassUsed(String pseudoclass) - this method is also called from node to determine whether or not the node's pseudo-class state would cause css to be applied > > Note that neither the proposed StyleManager API nor the StyleHelper API pull in any other API not already part of the public API. > > Having Scene own a StyleManager also has the benefit of being able to avoid looking up the parent chain to see if the scene's window is a popup or not. That logic can be moved to the constructor. With this change, StyleManager can be further streamlined by eliminating the StylesheetContainer (StylesheetContainer gets moved into the body of the StyleManagerImpl) and the defaultContainer. > > Further, since a Parent can also have stylesheets, I also propose adding StyleManager to Parent with the same API as in Scene. > private final StyleManger styleManager; > public final StyleManager getStyleManager() > > This will help eliminate the parent stylesheet lookup that currently happens in StylesheetContainer. > 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 jonathan.giles at oracle.com Wed Jul 25 13:05:36 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 26 Jul 2012 08:05:36 +1200 Subject: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager In-Reply-To: References: Message-ID: <50105190.80401@oracle.com> Personally I have no issue with doing this (StyleManager on Scene and Parent), but then I do not own these two classes. I do have a few questions though: 1) How does this impact any future APIs to support programmatic CSS access (i.e. Java API to get/set/observe CSS property values)? 2) In general we try not to have getters/setters when the object is not being exposed as a full property - but I guess it makes no sense to allow people to set or observe changes to the StyleManager field? 3) I know I could dive into the code, but what is the difference between setDefaultUserAgentStylesheet and addDefaultUserAgentStylesheet? Are both necessary? -- Jonathan On 26/07/2012 5:15 a.m., David Grieve wrote: > Background: > This request is related to http://javafx-jira.kenai.com/browse/RT-23460. StyleManager's job it is to keep track of stylesheets, manage the cascade, and create StyleHelpers for nodes. StyleHelper is the code that applies css styles to nodes. > > Currently, there StyleManager is a singleton but it can manage stylesheets from many different scenes. To do this, it maintains a table that maps Scene to a StylesheetContainer which contains the list of declarations from all the stylesheets associated with the scene. RT-23460 seeks to eliminate the lookup of Scene to StylesheetContainer. One such way to do this is for Scene to own its StylesheetContainer, as is proposed in the bug report. Another way is to have Scene own its own StyleManager. This latter approach is preferred (well, by me at least) since it greatly reduces the complexity of StyleManager and makes other optimizations possible. > > Proposed changes: > > I propose adding a StyleManager member to Scene and moving StyleManager to the javafx.scene package as an abstract class with the minimum required public API. > > Scene would add: > private final StyleManger styleManager; > public final StyleManager getStyleManager() > > Because Scene would have public API that returns a StyleManager, StyleManager itself needs to be public API and would need to be moved from com.sun.javafx.css to javafx.scene > > I propose StyleManager's public API as: > public abstract StyleHelper getStyleHelper(Node node) > public final ObservableList getStylesheets() -- the list of stylesheet URL strings for the Scene. Scene's getStylesheets() method would simply return styleManager.getStylesheets() > public void setDefaultUserAgentStylesheet(String url) > public final void addDefaultUserAgentStylesheet(String url) -- support Controls that have their own UA stylesheet, plus adding UA stylesheets for embedded > public final List getUserAgentStylesheets() - return immutable list of UA stylesheet URL strings > Note that StyleManager returns a StyleHelper. Hence, StyleHelper would also need to be part of the public API. There are only two methods in StyleManager that need to be exposed > public abstract void transitionToState() - this method is called from Node when css needs to be applied > public abstract boolean isPseudoclassUsed(String pseudoclass) - this method is also called from node to determine whether or not the node's pseudo-class state would cause css to be applied > > Note that neither the proposed StyleManager API nor the StyleHelper API pull in any other API not already part of the public API. > > Having Scene own a StyleManager also has the benefit of being able to avoid looking up the parent chain to see if the scene's window is a popup or not. That logic can be moved to the constructor. With this change, StyleManager can be further streamlined by eliminating the StylesheetContainer (StylesheetContainer gets moved into the body of the StyleManagerImpl) and the defaultContainer. > > Further, since a Parent can also have stylesheets, I also propose adding StyleManager to Parent with the same API as in Scene. > private final StyleManger styleManager; > public final StyleManager getStyleManager() > > This will help eliminate the parent stylesheet lookup that currently happens in StylesheetContainer. > > > 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 kimtopley at gmail.com Wed Jul 25 13:12:07 2012 From: kimtopley at gmail.com (kimtopley at gmail.com) Date: Wed, 25 Jul 2012 20:12:07 +0000 Subject: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager In-Reply-To: References: Message-ID: <2027412642-1343247129-cardhu_decombobulator_blackberry.rim.net-1212420819-@b12.c12.bise6.blackberry> It would be nice to have a way to set a global default UA stylesheet to completely replace the Caspian css file, without having to do so on all Scenes. This would allow the default stylesheet to be set by framework code, while allowing application code to create Scenes without having to know about the specific stylesheet in use. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: David Grieve Sender: openjfx-dev-bounces at openjdk.java.net Date: Wed, 25 Jul 2012 13:15:14 To: openjfx-dev at openjdk.java.net List Subject: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager Background: This request is related to http://javafx-jira.kenai.com/browse/RT-23460. StyleManager's job it is to keep track of stylesheets, manage the cascade, and create StyleHelpers for nodes. StyleHelper is the code that applies css styles to nodes. Currently, there StyleManager is a singleton but it can manage stylesheets from many different scenes. To do this, it maintains a table that maps Scene to a StylesheetContainer which contains the list of declarations from all the stylesheets associated with the scene. RT-23460 seeks to eliminate the lookup of Scene to StylesheetContainer. One such way to do this is for Scene to own its StylesheetContainer, as is proposed in the bug report. Another way is to have Scene own its own StyleManager. This latter approach is preferred (well, by me at least) since it greatly reduces the complexity of StyleManager and makes other optimizations possible. Proposed changes: I propose adding a StyleManager member to Scene and moving StyleManager to the javafx.scene package as an abstract class with the minimum required public API. Scene would add: private final StyleManger styleManager; public final StyleManager getStyleManager() Because Scene would have public API that returns a StyleManager, StyleManager itself needs to be public API and would need to be moved from com.sun.javafx.css to javafx.scene I propose StyleManager's public API as: public abstract StyleHelper getStyleHelper(Node node) public final ObservableList getStylesheets() -- the list of stylesheet URL strings for the Scene. Scene's getStylesheets() method would simply return styleManager.getStylesheets() public void setDefaultUserAgentStylesheet(String url) public final void addDefaultUserAgentStylesheet(String url) -- support Controls that have their own UA stylesheet, plus adding UA stylesheets for embedded public final List getUserAgentStylesheets() - return immutable list of UA stylesheet URL strings Note that StyleManager returns a StyleHelper. Hence, StyleHelper would also need to be part of the public API. There are only two methods in StyleManager that need to be exposed public abstract void transitionToState() - this method is called from Node when css needs to be applied public abstract boolean isPseudoclassUsed(String pseudoclass) - this method is also called from node to determine whether or not the node's pseudo-class state would cause css to be applied Note that neither the proposed StyleManager API nor the StyleHelper API pull in any other API not already part of the public API. Having Scene own a StyleManager also has the benefit of being able to avoid looking up the parent chain to see if the scene's window is a popup or not. That logic can be moved to the constructor. With this change, StyleManager can be further streamlined by eliminating the StylesheetContainer (StylesheetContainer gets moved into the body of the StyleManagerImpl) and the defaultContainer. Further, since a Parent can also have stylesheets, I also propose adding StyleManager to Parent with the same API as in Scene. private final StyleManger styleManager; public final StyleManager getStyleManager() This will help eliminate the parent stylesheet lookup that currently happens in StylesheetContainer. David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From david.grieve at oracle.com Wed Jul 25 13:39:11 2012 From: david.grieve at oracle.com (David Grieve) Date: Wed, 25 Jul 2012 16:39:11 -0400 Subject: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager In-Reply-To: <2027412642-1343247129-cardhu_decombobulator_blackberry.rim.net-1212420819-@b12.c12.bise6.blackberry> References: <2027412642-1343247129-cardhu_decombobulator_blackberry.rim.net-1212420819-@b12.c12.bise6.blackberry> Message-ID: <471E9934-0F03-41F8-BCA5-EA033C6995EE@oracle.com> http://javafx-jira.kenai.com/browse/RT-19713 On Jul 25, 2012, at 4:12 PM, kimtopley at gmail.com wrote: > It would be nice to have a way to set a global default UA stylesheet to completely replace the Caspian css file, without having to do so on all Scenes. This would allow the default stylesheet to be set by framework code, while allowing application code to create Scenes without having to know about the specific stylesheet in use. > > > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: David Grieve > Sender: openjfx-dev-bounces at openjdk.java.net > Date: Wed, 25 Jul 2012 13:15:14 > To: openjfx-dev at openjdk.java.net List > Subject: API REVIEW: move com.sun.javafx.css.StyleManager to > javafx.scene.StyleManager > > Background: > This request is related to http://javafx-jira.kenai.com/browse/RT-23460. StyleManager's job it is to keep track of stylesheets, manage the cascade, and create StyleHelpers for nodes. StyleHelper is the code that applies css styles to nodes. > > Currently, there StyleManager is a singleton but it can manage stylesheets from many different scenes. To do this, it maintains a table that maps Scene to a StylesheetContainer which contains the list of declarations from all the stylesheets associated with the scene. RT-23460 seeks to eliminate the lookup of Scene to StylesheetContainer. One such way to do this is for Scene to own its StylesheetContainer, as is proposed in the bug report. Another way is to have Scene own its own StyleManager. This latter approach is preferred (well, by me at least) since it greatly reduces the complexity of StyleManager and makes other optimizations possible. > > Proposed changes: > > I propose adding a StyleManager member to Scene and moving StyleManager to the javafx.scene package as an abstract class with the minimum required public API. > > Scene would add: > private final StyleManger styleManager; > public final StyleManager getStyleManager() > > Because Scene would have public API that returns a StyleManager, StyleManager itself needs to be public API and would need to be moved from com.sun.javafx.css to javafx.scene > > I propose StyleManager's public API as: > public abstract StyleHelper getStyleHelper(Node node) > public final ObservableList getStylesheets() -- the list of stylesheet URL strings for the Scene. Scene's getStylesheets() method would simply return styleManager.getStylesheets() > public void setDefaultUserAgentStylesheet(String url) > public final void addDefaultUserAgentStylesheet(String url) -- support Controls that have their own UA stylesheet, plus adding UA stylesheets for embedded > public final List getUserAgentStylesheets() - return immutable list of UA stylesheet URL strings > Note that StyleManager returns a StyleHelper. Hence, StyleHelper would also need to be part of the public API. There are only two methods in StyleManager that need to be exposed > public abstract void transitionToState() - this method is called from Node when css needs to be applied > public abstract boolean isPseudoclassUsed(String pseudoclass) - this method is also called from node to determine whether or not the node's pseudo-class state would cause css to be applied > > Note that neither the proposed StyleManager API nor the StyleHelper API pull in any other API not already part of the public API. > > Having Scene own a StyleManager also has the benefit of being able to avoid looking up the parent chain to see if the scene's window is a popup or not. That logic can be moved to the constructor. With this change, StyleManager can be further streamlined by eliminating the StylesheetContainer (StylesheetContainer gets moved into the body of the StyleManagerImpl) and the defaultContainer. > > Further, since a Parent can also have stylesheets, I also propose adding StyleManager to Parent with the same API as in Scene. > private final StyleManger styleManager; > public final StyleManager getStyleManager() > > This will help eliminate the parent stylesheet lookup that currently happens in StylesheetContainer. > > > David Grieve | Principal Member of Technical Staff > Mobile: +16033121013 > Oracle Java Client UI and Tools > Durham, NH 03824 > Oracle is committed to developing practices and products that help protect the environment > David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From kimtopley at gmail.com Wed Jul 25 13:44:17 2012 From: kimtopley at gmail.com (kimtopley at gmail.com) Date: Wed, 25 Jul 2012 20:44:17 +0000 Subject: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager In-Reply-To: <471E9934-0F03-41F8-BCA5-EA033C6995EE@oracle.com> References: <2027412642-1343247129-cardhu_decombobulator_blackberry.rim.net-1212420819-@b12.c12.bise6.blackberry> <471E9934-0F03-41F8-BCA5-EA033C6995EE@oracle.com> Message-ID: <1387564052-1343249060-cardhu_decombobulator_blackberry.rim.net-561095289-@b12.c12.bise6.blackberry> Thank you. That would be a very useful feature to have in 3.0. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: David Grieve Date: Wed, 25 Jul 2012 16:39:11 To: Cc: openjfx-dev at openjdk.java.net List Subject: Re: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager http://javafx-jira.kenai.com/browse/RT-19713 On Jul 25, 2012, at 4:12 PM, kimtopley at gmail.com wrote: > It would be nice to have a way to set a global default UA stylesheet to completely replace the Caspian css file, without having to do so on all Scenes. This would allow the default stylesheet to be set by framework code, while allowing application code to create Scenes without having to know about the specific stylesheet in use. > > > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: David Grieve > Sender: openjfx-dev-bounces at openjdk.java.net > Date: Wed, 25 Jul 2012 13:15:14 > To: openjfx-dev at openjdk.java.net List > Subject: API REVIEW: move com.sun.javafx.css.StyleManager to > javafx.scene.StyleManager > > Background: > This request is related to http://javafx-jira.kenai.com/browse/RT-23460. StyleManager's job it is to keep track of stylesheets, manage the cascade, and create StyleHelpers for nodes. StyleHelper is the code that applies css styles to nodes. > > Currently, there StyleManager is a singleton but it can manage stylesheets from many different scenes. To do this, it maintains a table that maps Scene to a StylesheetContainer which contains the list of declarations from all the stylesheets associated with the scene. RT-23460 seeks to eliminate the lookup of Scene to StylesheetContainer. One such way to do this is for Scene to own its StylesheetContainer, as is proposed in the bug report. Another way is to have Scene own its own StyleManager. This latter approach is preferred (well, by me at least) since it greatly reduces the complexity of StyleManager and makes other optimizations possible. > > Proposed changes: > > I propose adding a StyleManager member to Scene and moving StyleManager to the javafx.scene package as an abstract class with the minimum required public API. > > Scene would add: > private final StyleManger styleManager; > public final StyleManager getStyleManager() > > Because Scene would have public API that returns a StyleManager, StyleManager itself needs to be public API and would need to be moved from com.sun.javafx.css to javafx.scene > > I propose StyleManager's public API as: > public abstract StyleHelper getStyleHelper(Node node) > public final ObservableList getStylesheets() -- the list of stylesheet URL strings for the Scene. Scene's getStylesheets() method would simply return styleManager.getStylesheets() > public void setDefaultUserAgentStylesheet(String url) > public final void addDefaultUserAgentStylesheet(String url) -- support Controls that have their own UA stylesheet, plus adding UA stylesheets for embedded > public final List getUserAgentStylesheets() - return immutable list of UA stylesheet URL strings > Note that StyleManager returns a StyleHelper. Hence, StyleHelper would also need to be part of the public API. There are only two methods in StyleManager that need to be exposed > public abstract void transitionToState() - this method is called from Node when css needs to be applied > public abstract boolean isPseudoclassUsed(String pseudoclass) - this method is also called from node to determine whether or not the node's pseudo-class state would cause css to be applied > > Note that neither the proposed StyleManager API nor the StyleHelper API pull in any other API not already part of the public API. > > Having Scene own a StyleManager also has the benefit of being able to avoid looking up the parent chain to see if the scene's window is a popup or not. That logic can be moved to the constructor. With this change, StyleManager can be further streamlined by eliminating the StylesheetContainer (StylesheetContainer gets moved into the body of the StyleManagerImpl) and the defaultContainer. > > Further, since a Parent can also have stylesheets, I also propose adding StyleManager to Parent with the same API as in Scene. > private final StyleManger styleManager; > public final StyleManager getStyleManager() > > This will help eliminate the parent stylesheet lookup that currently happens in StylesheetContainer. > > > David Grieve | Principal Member of Technical Staff > Mobile: +16033121013 > Oracle Java Client UI and Tools > Durham, NH 03824 > Oracle is committed to developing practices and products that help protect the environment > David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From pavel.safrata at oracle.com Wed Jul 25 13:49:28 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 25 Jul 2012 22:49:28 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: <77DE75EA-EA4F-4F6C-9184-1A9737714066@oracle.com> References: <500F2A6F.5050401@oracle.com> <500FFA8B.30703@oracle.com> <77DE75EA-EA4F-4F6C-9184-1A9737714066@oracle.com> Message-ID: <50105BD8.5020503@oracle.com> I think the main point is that even though both vector and point consist of three doubles, they are different kinds of animals. Point contains coordinates, Vector contains magnitudes/distances. We will probably want to provide methods for computing angle between vectors or vector length. Having angle between points or point length doesn't make any natural sense. If we provide those methods on Point3D, they will look weird, and javadoc will have to explain that in this case we treat the point as "relative distance vector" (taken from J2D that has to do that). Also transforming a point in space results in another point in space whereas transforming a vector is a different operation that results in a vector. With both guys represented as a single class we need to provide two different transform methods, one of them for treating a "point" as point, the second one for treating a "point" as vector (named deltaTransform). J2D does that (has a single "point" and needs to explain in javadoc how it is treated, but it doesn't have the convenience "vector algerbra" methods so the problems are smaller), J3D doesn't (distinguishes point and vector as different things). Unfortunately I haven't been involved in the past discussions so I probably don't have enough insight. I don't really want to question already made decisions but when we've already got to this point it would be great if somebody could sum up the reasons for the decision to represent both things by Point. Thanks, Pavel On 25.7.2012 17:54, Richard Bair wrote: > Haha, you're going to make me read the thread :-) > > Generally speaking I'd prefer to just use Point3D vs. adding a Vector, primarily because we already made this decision several releases ago. Without having to read the whole thread, can you give a short summary of the impact using Point3D has vs. a class named Vector3D? > > Richard > > On Jul 25, 2012, at 6:54 AM, Pavel Safrata wrote: > >> I think that if we define Vector*D as the class that represents magnitudes without position, and we use it for our magnitudes without position, we don't need any deltaTransforms, do we? >> >> Richard, what do you think about introducing Vector2D and Vector3D? I think the classes would be nice (to distinguish between specific points in space and magnitudes without position) but we would have to deprecate methods in Rotate that use Point3D as rotation axis and introduce different ones that use Vector3D, we would also need to deprecate the static axes defined in this class and define vector ones with different names.. >> >> Thanks, >> Pavel >> >> On 25.7.2012 1:34, Pedro Duque Vieira wrote: >>> Hi Jim, >>> >>> Maybe we're talking about two different ways of performing the same >>> calculations, probably we come from different backgrounds. >>> >>> What I meant with Vector3d is a 4x1 matrix with the last element as 0 >>> (homogeneous coordinates). We can then have methods on the Vector3d class >>> to give us things we expect to retrieve from vectors: like angle, >>> magnitude, doing the cross product of two vectors, calculating the angle >>> between two vectors. >>> As a reference one can look at the java3d implementation of Vector3d: >>> http://docs.oracle.com/cd/E17802_01/j2se/javase/technologies/desktop/java3d/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/Transform3D.html >>> >>> >>> Thanks, best regards, >>> >>> On Wed, Jul 25, 2012 at 12:06 AM, Jim Graham wrote: >>> >>>> Hi Pedro, >>>> >>>> delta transform is transform without translation. It is primarily used to >>>> transform magnitudes that have no position so you only modify them with the >>>> scale, shear, and rotation aspects of the matrix (i.e. everything but the >>>> translate components). >>>> >>>> For some reason I got the impression that Vector was only used to >>>> represent magnitude because people were bringing up delta transforms in the >>>> context of talking about it. If it is a 1x4 vector then it is just >>>> Point3D+perspective-w-element, [x,y,z,w] no? Point3D can participate in >>>> 4x4 transforms, supplying an implicit w=1 component, though it can't store >>>> the resulting w component if the matrix doesn't have 0,0,0,1 for the last 4 >>>> elements (i.e. in perspective camera matrices)... >>>> >>>> ...jim >>>> >>>> >>>> On 7/24/2012 3:55 PM, Pedro Duque Vieira wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> I've already commented on this in the matrix algebra thread, but I >>>>>> wanted to throw into this discussion the following point: >>>>>> I'm neutral on whether or not we need Vector - I'll leave that to the >>>>>> people with extensive 3D experience to comment. But, if transformation >>>>>> of vectors makes better sense to do a delta transform, and if we are >>>>>> adding deltaTransform() methods for other types (which I think we should >>>>>> do), then I think the "transform" method that does a "delta transform" >>>>>> on a Vector should actually be named "deltaTransform" for consistency, >>>>>> even if it is obvious that a vector should only be transformed that >>>>>> way... >>>>>> >>>>>> >>>>> I don't know what a delta transform is (never used it on my 3d work >>>>> background), so I cannot comment on that part. >>>>> All I can say is that I did use transform a vector by a given matrix >>>>> transform and it makes sense. It's basically a multiplication of a 4x4 >>>>> matrix transform with a 1x4 matrix, just like what happens when you >>>>> transform a point3d. >>>>> So I think: >>>>> - void transform(Vector3d) >>>>> Should be present on the transform3d class. >>>>> >>>>> Just my 2 cents, >>>>> >>>>> >> From david.grieve at oracle.com Wed Jul 25 14:03:18 2012 From: david.grieve at oracle.com (David Grieve) Date: Wed, 25 Jul 2012 17:03:18 -0400 Subject: API REVIEW: move com.sun.javafx.css.StyleManager to javafx.scene.StyleManager In-Reply-To: <50105190.80401@oracle.com> References: <50105190.80401@oracle.com> Message-ID: 1. There is no impact on any future API to support programmatic CSS access (http://javafx-jira.kenai.com/browse/RT-17293). 2. StyleManager should be a final variable in Scene. Even if more of the css implementation were to be moved to javafx.scene (something Richard is arguing for), the getter would still need to be public since StyleManager is used outside of javafx.scene (in javafx.scene.controls and possibly by SceneBuilder) 3. I didn't notice the cut-n-paste error. The two methods should be setDefaultUserAgentStylesheet and addUserAgentStylesheet. Both are not strictly required. addUserAgentStylesheet could be enough. However, normal declarations from the default user agent stylesheet need be first in the cascade so they may be overwritten by declarations from other user agent stylesheets. Assuming the first UA stylesheet is meant to be the default is not a valid assumption. The list of UA stylesheet URL strings could be exposed, but then anyone could come along and insert their UA stylesheet and make it the default. Maybe that isn't a bad thing, but it is a change in how the system behaves. The two methods allow UA stylesheets to be added even before the default is set. It isn't fool proof. There would be nothing to prevent someone from calling setDefault UserAgentStylesheet before controls calls it to set caspian. Again, maybe this isn't a bad thing. On Jul 25, 2012, at 4:05 PM, Jonathan Giles wrote: > Personally I have no issue with doing this (StyleManager on Scene and Parent), but then I do not own these two classes. I do have a few questions though: > > 1) How does this impact any future APIs to support programmatic CSS access (i.e. Java API to get/set/observe CSS property values)? > > 2) In general we try not to have getters/setters when the object is not being exposed as a full property - but I guess it makes no sense to allow people to set or observe changes to the StyleManager field? > > 3) I know I could dive into the code, but what is the difference between setDefaultUserAgentStylesheet and addDefaultUserAgentStylesheet? Are both necessary? > > -- Jonathan > > On 26/07/2012 5:15 a.m., David Grieve wrote: >> Background: >> This request is related to http://javafx-jira.kenai.com/browse/RT-23460. StyleManager's job it is to keep track of stylesheets, manage the cascade, and create StyleHelpers for nodes. StyleHelper is the code that applies css styles to nodes. >> >> Currently, there StyleManager is a singleton but it can manage stylesheets from many different scenes. To do this, it maintains a table that maps Scene to a StylesheetContainer which contains the list of declarations from all the stylesheets associated with the scene. RT-23460 seeks to eliminate the lookup of Scene to StylesheetContainer. One such way to do this is for Scene to own its StylesheetContainer, as is proposed in the bug report. Another way is to have Scene own its own StyleManager. This latter approach is preferred (well, by me at least) since it greatly reduces the complexity of StyleManager and makes other optimizations possible. >> >> Proposed changes: >> >> I propose adding a StyleManager member to Scene and moving StyleManager to the javafx.scene package as an abstract class with the minimum required public API. >> >> Scene would add: >> private final StyleManger styleManager; >> public final StyleManager getStyleManager() >> >> Because Scene would have public API that returns a StyleManager, StyleManager itself needs to be public API and would need to be moved from com.sun.javafx.css to javafx.scene >> I propose StyleManager's public API as: >> public abstract StyleHelper getStyleHelper(Node node) >> public final ObservableList getStylesheets() -- the list of stylesheet URL strings for the Scene. Scene's getStylesheets() method would simply return styleManager.getStylesheets() >> public void setDefaultUserAgentStylesheet(String url) >> public final void addDefaultUserAgentStylesheet(String url) -- support Controls that have their own UA stylesheet, plus adding UA stylesheets for embedded >> public final List getUserAgentStylesheets() - return immutable list of UA stylesheet URL strings >> Note that StyleManager returns a StyleHelper. Hence, StyleHelper would also need to be part of the public API. There are only two methods in StyleManager that need to be exposed >> public abstract void transitionToState() - this method is called from Node when css needs to be applied >> public abstract boolean isPseudoclassUsed(String pseudoclass) - this method is also called from node to determine whether or not the node's pseudo-class state would cause css to be applied >> >> Note that neither the proposed StyleManager API nor the StyleHelper API pull in any other API not already part of the public API. >> >> Having Scene own a StyleManager also has the benefit of being able to avoid looking up the parent chain to see if the scene's window is a popup or not. That logic can be moved to the constructor. With this change, StyleManager can be further streamlined by eliminating the StylesheetContainer (StylesheetContainer gets moved into the body of the StyleManagerImpl) and the defaultContainer. >> >> Further, since a Parent can also have stylesheets, I also propose adding StyleManager to Parent with the same API as in Scene. >> private final StyleManger styleManager; >> public final StyleManager getStyleManager() >> >> This will help eliminate the parent stylesheet lookup that currently happens in StylesheetContainer. >> >> >> David Grieve | Principal Member of Technical Staff >> Mobile: +16033121013 >> Oracle Java Client UI and Tools >> Durham, NH 03824 >> Oracle is committed to developing practices and products that help protect the environment >> > David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From zonski at gmail.com Wed Jul 25 14:05:41 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 26 Jul 2012 07:05:41 +1000 Subject: Jigsaw delayed Message-ID: Unfortunately it looks like Jigsaw (Java modularisation) is being pushed from Java 8 to Java 9, which means it is at least three years away. http://mreinhold.org/blog/late-for-the-train This means co-bundling and AU will be stuck with large JRE downloads for a while yet unfortunately. I'm wondering of any other proposed JFX features are likely to be affected by this. In particular would the hypothetical, whispered mobile support be dependent on Jigsaw or could it theoretically move ahead anyway? Cheers, Dan From richard.bair at oracle.com Wed Jul 25 14:10:00 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 25 Jul 2012 14:10:00 -0700 Subject: Transform point using localToSceneTransform In-Reply-To: <50105BD8.5020503@oracle.com> References: <500F2A6F.5050401@oracle.com> <500FFA8B.30703@oracle.com> <77DE75EA-EA4F-4F6C-9184-1A9737714066@oracle.com> <50105BD8.5020503@oracle.com> Message-ID: <84934A08-A27D-427D-8CBB-2742A48A961D@oracle.com> Great summary thanks! > Unfortunately I haven't been involved in the past discussions so I probably don't have enough insight. I don't really want to question already made decisions but when we've already got to this point it would be great if somebody could sum up the reasons for the decision to represent both things by Point. I think the answer might be simpler than it seems -- a desire to not add too many classes. Unfortunately that can lead to deprecation when, later on, you find that you need to add some new type. Kevin? Richard From richard.bair at oracle.com Wed Jul 25 14:16:11 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 25 Jul 2012 14:16:11 -0700 Subject: Jigsaw delayed In-Reply-To: References: Message-ID: <79B24BC4-1703-46AC-B13A-901A1483FAE1@oracle.com> Actually we're going to continue to work on modularization, only we'll be doing it "the old fashioned way" rather than using JigSaw for JavaFX. So for example we can still strip / subset classes / jars. We just won't get the fancy JigSaw for doing the modularization. We've gotta have it for embedded and such in any case. Richard On Jul 25, 2012, at 2:05 PM, Daniel Zwolenski wrote: > Unfortunately it looks like Jigsaw (Java modularisation) is being pushed from Java 8 to Java 9, which means it is at least three years away. > > http://mreinhold.org/blog/late-for-the-train > > This means co-bundling and AU will be stuck with large JRE downloads for a while yet unfortunately. > > I'm wondering of any other proposed JFX features are likely to be affected by this. In particular would the hypothetical, whispered mobile support be dependent on Jigsaw or could it theoretically move ahead anyway? > > Cheers, > Dan > > > From zonski at gmail.com Wed Jul 25 14:31:51 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 26 Jul 2012 07:31:51 +1000 Subject: Jigsaw delayed In-Reply-To: <79B24BC4-1703-46AC-B13A-901A1483FAE1@oracle.com> References: <79B24BC4-1703-46AC-B13A-901A1483FAE1@oracle.com> Message-ID: <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> That's good to hear. I hope the legal side of this will be included in this work so that end developers can do this manual modularisation as well. I believe currently the legals prevent us from stripping out most of the bits of a jre even for cobundling (or so I've been told). Awesome scenario would be to have a stripped minimal jre available for download as a zip and then all the other jars/dlls available for manual inclusion. Ie opt in, rather than opt out. I'm guessing this is outside the jfx teams realm of influence but just thought I'd mention it in case it comes up at office pizza night or the like ;) On 26/07/2012, at 7:16 AM, Richard Bair wrote: > Actually we're going to continue to work on modularization, only we'll be doing it "the old fashioned way" rather than using JigSaw for JavaFX. So for example we can still strip / subset classes / jars. We just won't get the fancy JigSaw for doing the modularization. > > We've gotta have it for embedded and such in any case. > > Richard > > On Jul 25, 2012, at 2:05 PM, Daniel Zwolenski wrote: > >> Unfortunately it looks like Jigsaw (Java modularisation) is being pushed from Java 8 to Java 9, which means it is at least three years away. >> >> http://mreinhold.org/blog/late-for-the-train >> >> This means co-bundling and AU will be stuck with large JRE downloads for a while yet unfortunately. >> >> I'm wondering of any other proposed JFX features are likely to be affected by this. In particular would the hypothetical, whispered mobile support be dependent on Jigsaw or could it theoretically move ahead anyway? >> >> Cheers, >> Dan >> >> >> > > From richard.bair at oracle.com Wed Jul 25 14:39:36 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 25 Jul 2012 14:39:36 -0700 Subject: Jigsaw delayed In-Reply-To: <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> References: <79B24BC4-1703-46AC-B13A-901A1483FAE1@oracle.com> <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> Message-ID: <809F59A2-68B3-45D6-9081-34AA6E8B48E6@oracle.com> Definitely in our sphere of influencing, and influencing as best we can :-) On Jul 25, 2012, at 2:31 PM, Daniel Zwolenski wrote: > That's good to hear. I hope the legal side of this will be included in this work so that end developers can do this manual modularisation as well. I believe currently the legals prevent us from stripping out most of the bits of a jre even for cobundling (or so I've been told). > > Awesome scenario would be to have a stripped minimal jre available for download as a zip and then all the other jars/dlls available for manual inclusion. Ie opt in, rather than opt out. > > I'm guessing this is outside the jfx teams realm of influence but just thought I'd mention it in case it comes up at office pizza night or the like ;) > > > > On 26/07/2012, at 7:16 AM, Richard Bair wrote: > >> Actually we're going to continue to work on modularization, only we'll be doing it "the old fashioned way" rather than using JigSaw for JavaFX. So for example we can still strip / subset classes / jars. We just won't get the fancy JigSaw for doing the modularization. >> >> We've gotta have it for embedded and such in any case. >> >> Richard >> >> On Jul 25, 2012, at 2:05 PM, Daniel Zwolenski wrote: >> >>> Unfortunately it looks like Jigsaw (Java modularisation) is being pushed from Java 8 to Java 9, which means it is at least three years away. >>> >>> http://mreinhold.org/blog/late-for-the-train >>> >>> This means co-bundling and AU will be stuck with large JRE downloads for a while yet unfortunately. >>> >>> I'm wondering of any other proposed JFX features are likely to be affected by this. In particular would the hypothetical, whispered mobile support be dependent on Jigsaw or could it theoretically move ahead anyway? >>> >>> Cheers, >>> Dan >>> >>> >>> >> >> From igor.nekrestyanov at oracle.com Wed Jul 25 14:55:57 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 25 Jul 2012 14:55:57 -0700 Subject: Jigsaw delayed In-Reply-To: <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> References: <79B24BC4-1703-46AC-B13A-901A1483FAE1@oracle.com> <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> Message-ID: <50106B6D.3000503@oracle.com> On 7/25/12 2:31 PM, Daniel Zwolenski wrote: > That's good to hear. I hope the legal side of this will be included in this work so that end developers can do this manual modularisation as well. I believe currently the legals prevent us from stripping out most of the bits of a jre even for cobundling (or so I've been told). > > Awesome scenario would be to have a stripped minimal jre available for download as a zip and then all the other jars/dlls available for manual inclusion. Ie opt in, rather than opt out. IMHO, this is unlikely as stripped JRE will not pass TCK tests. This is where you need to wait for jigsaw. But stripping of JRE for the purpose of use by single application is somewhat different scenario. Legal side will need to be cleared before we can support this of course. -igor > I'm guessing this is outside the jfx teams realm of influence but just thought I'd mention it in case it comes up at office pizza night or the like ;) On 26/07/2012, at 7:16 AM, Richard Bair wrote: >> Actually we're going to continue to work on modularization, only we'll be doing it "the old fashioned way" rather than using JigSaw for JavaFX. So for example we can still strip / subset classes / jars. We just won't get the fancy JigSaw for doing the modularization. >> >> We've gotta have it for embedded and such in any case. >> >> Richard >> >> On Jul 25, 2012, at 2:05 PM, Daniel Zwolenski wrote: >> >>> Unfortunately it looks like Jigsaw (Java modularisation) is being pushed from Java 8 to Java 9, which means it is at least three years away. >>> >>> http://mreinhold.org/blog/late-for-the-train >>> >>> This means co-bundling and AU will be stuck with large JRE downloads for a while yet unfortunately. >>> >>> I'm wondering of any other proposed JFX features are likely to be affected by this. In particular would the hypothetical, whispered mobile support be dependent on Jigsaw or could it theoretically move ahead anyway? >>> >>> Cheers, >>> Dan >>> >>> >>> >> From philip.race at oracle.com Wed Jul 25 15:00:55 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 25 Jul 2012 15:00:55 -0700 Subject: Jigsaw delayed In-Reply-To: <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> References: <79B24BC4-1703-46AC-B13A-901A1483FAE1@oracle.com> <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> Message-ID: <50106C97.3050408@oracle.com> SFAIK if you use your own build from the GPL OpenJDK sources you can do what you like, as long as you don't claim its Java etc. -phil. On 7/25/2012 2:31 PM, Daniel Zwolenski wrote: > That's good to hear. I hope the legal side of this will be included in this work so that end developers can do this manual modularisation as well. I believe currently the legals prevent us from stripping out most of the bits of a jre even for cobundling (or so I've been told). > > Awesome scenario would be to have a stripped minimal jre available for download as a zip and then all the other jars/dlls available for manual inclusion. Ie opt in, rather than opt out. > > I'm guessing this is outside the jfx teams realm of influence but just thought I'd mention it in case it comes up at office pizza night or the like ;) > > > > On 26/07/2012, at 7:16 AM, Richard Bair wrote: > >> Actually we're going to continue to work on modularization, only we'll be doing it "the old fashioned way" rather than using JigSaw for JavaFX. So for example we can still strip / subset classes / jars. We just won't get the fancy JigSaw for doing the modularization. >> >> We've gotta have it for embedded and such in any case. >> >> Richard >> >> On Jul 25, 2012, at 2:05 PM, Daniel Zwolenski wrote: >> >>> Unfortunately it looks like Jigsaw (Java modularisation) is being pushed from Java 8 to Java 9, which means it is at least three years away. >>> >>> http://mreinhold.org/blog/late-for-the-train >>> >>> This means co-bundling and AU will be stuck with large JRE downloads for a while yet unfortunately. >>> >>> I'm wondering of any other proposed JFX features are likely to be affected by this. In particular would the hypothetical, whispered mobile support be dependent on Jigsaw or could it theoretically move ahead anyway? >>> >>> Cheers, >>> Dan >>> >>> >>> >> From richard.bair at oracle.com Wed Jul 25 15:03:15 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 25 Jul 2012 15:03:15 -0700 Subject: Jigsaw delayed In-Reply-To: <50106B6D.3000503@oracle.com> References: <79B24BC4-1703-46AC-B13A-901A1483FAE1@oracle.com> <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> <50106B6D.3000503@oracle.com> Message-ID: <98EF2CE7-45B7-47B5-9DA6-912FAFD1180E@oracle.com> >> That's good to hear. I hope the legal side of this will be included in this work so that end developers can do this manual modularisation as well. I believe currently the legals prevent us from stripping out most of the bits of a jre even for cobundling (or so I've been told). >> >> Awesome scenario would be to have a stripped minimal jre available for download as a zip and then all the other jars/dlls available for manual inclusion. Ie opt in, rather than opt out. > IMHO, this is unlikely as stripped JRE will not pass TCK tests. This is where you need to wait for jigsaw. And that is where we are pushing for a change. Richard From igor.nekrestyanov at oracle.com Wed Jul 25 15:08:43 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 25 Jul 2012 15:08:43 -0700 Subject: Jigsaw delayed In-Reply-To: <98EF2CE7-45B7-47B5-9DA6-912FAFD1180E@oracle.com> References: <79B24BC4-1703-46AC-B13A-901A1483FAE1@oracle.com> <5A08A31E-16FA-408D-A71B-4D8A08621978@gmail.com> <50106B6D.3000503@oracle.com> <98EF2CE7-45B7-47B5-9DA6-912FAFD1180E@oracle.com> Message-ID: <50106E6B.60405@oracle.com> On 7/25/12 3:03 PM, Richard Bair wrote: >>> That's good to hear. I hope the legal side of this will be included in this work so that end developers can do this manual modularisation as well. I believe currently the legals prevent us from stripping out most of the bits of a jre even for cobundling (or so I've been told). >>> >>> Awesome scenario would be to have a stripped minimal jre available for download as a zip and then all the other jars/dlls available for manual inclusion. Ie opt in, rather than opt out. >> IMHO, this is unlikely as stripped JRE will not pass TCK tests. This is where you need to wait for jigsaw. > And that is where we are pushing for a change. Ah, good to know :) -igor > > Richard From jmartine_1026 at yahoo.com Wed Jul 25 16:57:34 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 25 Jul 2012 16:57:34 -0700 (PDT) Subject: Auto-update of native application bundles In-Reply-To: References: Message-ID: <1343260654.32043.YahooMailNeo@web161506.mail.bf1.yahoo.com> Dan, After spending time thinking about jar signing (and more importantly finishing the book Ghost in The Wires) I think jar signing might be a good idea. ?I have two questions on how that would work. 1) ?Would it be the auto-updater framework that will do the sign-check on the downloaded jars before installing them? 2) ?Can the certificate's subject and issuer be predefined into the framework before it is released into the wild? ?This way only jars that I sign will be accepted. ? thanks jose ________________________________ From: Rick Walker To: openjfx-dev at openjdk.java.net Sent: Tuesday, July 24, 2012 12:31 PM Subject: Auto-update of native application bundles Auto-Updater Feedback / Wishlist: We are keenly interested in the auto-updater and we greatly appreciate the efforts of all, especially Igor and Daniel. We anticipate posting app updates on a tight cycle ? a week or two will be routine. So a clean, reliable auto-updater will make our users? lives vastly simpler. Our app will require the user to log in and authenticate before launching the auto-updater. We would prefer to zip up our latest app jars and post to a predetermined location on our server. If the JRE does not change with an update, the updater should ignore it and retrieve only our app jars and/or updated T&C (see below). Regarding jar signing, we expect to retrieve our app jars from our server. Even though we generally sign jars, we do not imagine performing a jar-signing check with each auto-update. We want to be able to tightly control auto-updates - we may ask users to pay for some updates. We are concerned that, by placing our jars at a url accessible to the auto-updater, we might also be inadvertently exposing them to anyone who might point a browser at the same url. Adding some level of indirection might help. Regarding updates to Terms and Conditions or EULA, it would be a great advantage to post an RTF (perhaps with a version number included in the file name) alongside our updated app jars so that the updater could determine whether the user ought to view and agree to the new T&C. I believe we include an RTF on the installer side (with NSIS or Inno) so it?s no extra work to also post it for the updater. We also routinely post updated T&C on our website, so I suppose a simple alternative might be for the auto-updater to simply point to that url. >From our perspective, it seems there are three components in play for the updater, each separately tracked for current version: the JRE, our app jars, and the T&C. Regarding user notification, we plan to use auto-updating to make sure that all users are using the same version of our app ? just as if we deployed as an applet. User notification can therefore be bare bones ? ?a required update is now available?.? A "what's changed" document isn't required in our case. The download display can be modal ? there is no need for the download to take place in the background.? An incremental progress indicator would be nicer than an indeterminate display. Graceful recovery in the event of a failure state (stalled download, file i/o probs etc) is of course essential. Cheers to all, Rick From james.graham at oracle.com Wed Jul 25 18:19:42 2012 From: james.graham at oracle.com (Jim Graham) Date: Wed, 25 Jul 2012 18:19:42 -0700 Subject: Transform point using localToSceneTransform In-Reply-To: <50105BD8.5020503@oracle.com> References: <500F2A6F.5050401@oracle.com> <500FFA8B.30703@oracle.com> <77DE75EA-EA4F-4F6C-9184-1A9737714066@oracle.com> <50105BD8.5020503@oracle.com> Message-ID: <50109B2E.3040705@oracle.com> Hi Pavel, You claim that we need to add new methods if we treat a point as if it were a vector, but we would have to do that anyway to add methods that take vector. So, we can either add: transform(Vector) - treats its arg as magnitudes (and thus does a delta transform) or we can add: deltaTransform(Point) - delta transforms the arg (which is what you want to do with magnitudes) It's a matter of whether the semantics are in the method name or the argument type. Furthermore, an array of doubles does not have an "am I a set of points or vectors" type attached to it so we do need to have 2 different method names for the methods that take arrays of doubles, whether or not we create a Vector class (whose sole purpose is to indicate that its values which are identical in nature to the Point class are to be considered as magnitudes). We can either encapsulate this information in a new class and add lots of methods for that new class, or we can encapsulate the information on the naming and documentation of new methods which use old types - both have equal expense in terms of method counts... ...jim On 7/25/2012 1:49 PM, Pavel Safrata wrote: > I think the main point is that even though both vector and point consist > of three doubles, they are different kinds of animals. Point contains > coordinates, Vector contains magnitudes/distances. We will probably want > to provide methods for computing angle between vectors or vector length. > Having angle between points or point length doesn't make any natural > sense. If we provide those methods on Point3D, they will look weird, and > javadoc will have to explain that in this case we treat the point as > "relative distance vector" (taken from J2D that has to do that). Also > transforming a point in space results in another point in space whereas > transforming a vector is a different operation that results in a vector. > With both guys represented as a single class we need to provide two > different transform methods, one of them for treating a "point" as > point, the second one for treating a "point" as vector (named > deltaTransform). J2D does that (has a single "point" and needs to > explain in javadoc how it is treated, but it doesn't have the > convenience "vector algerbra" methods so the problems are smaller), J3D > doesn't (distinguishes point and vector as different things). > > Unfortunately I haven't been involved in the past discussions so I > probably don't have enough insight. I don't really want to question > already made decisions but when we've already got to this point it would > be great if somebody could sum up the reasons for the decision to > represent both things by Point. > > Thanks, > Pavel > > On 25.7.2012 17:54, Richard Bair wrote: >> Haha, you're going to make me read the thread :-) >> >> Generally speaking I'd prefer to just use Point3D vs. adding a Vector, >> primarily because we already made this decision several releases ago. >> Without having to read the whole thread, can you give a short summary >> of the impact using Point3D has vs. a class named Vector3D? >> >> Richard >> >> On Jul 25, 2012, at 6:54 AM, Pavel Safrata wrote: >> >>> I think that if we define Vector*D as the class that represents >>> magnitudes without position, and we use it for our magnitudes without >>> position, we don't need any deltaTransforms, do we? >>> >>> Richard, what do you think about introducing Vector2D and Vector3D? I >>> think the classes would be nice (to distinguish between specific >>> points in space and magnitudes without position) but we would have to >>> deprecate methods in Rotate that use Point3D as rotation axis and >>> introduce different ones that use Vector3D, we would also need to >>> deprecate the static axes defined in this class and define vector >>> ones with different names.. >>> >>> Thanks, >>> Pavel >>> >>> On 25.7.2012 1:34, Pedro Duque Vieira wrote: >>>> Hi Jim, >>>> >>>> Maybe we're talking about two different ways of performing the same >>>> calculations, probably we come from different backgrounds. >>>> >>>> What I meant with Vector3d is a 4x1 matrix with the last element as 0 >>>> (homogeneous coordinates). We can then have methods on the Vector3d >>>> class >>>> to give us things we expect to retrieve from vectors: like angle, >>>> magnitude, doing the cross product of two vectors, calculating the >>>> angle >>>> between two vectors. >>>> As a reference one can look at the java3d implementation of Vector3d: >>>> http://docs.oracle.com/cd/E17802_01/j2se/javase/technologies/desktop/java3d/forDevelopers/J3D_1_3_API/j3dapi/javax/media/j3d/Transform3D.html >>>> >>>> >>>> >>>> Thanks, best regards, >>>> >>>> On Wed, Jul 25, 2012 at 12:06 AM, Jim Graham >>>> wrote: >>>> >>>>> Hi Pedro, >>>>> >>>>> delta transform is transform without translation. It is primarily >>>>> used to >>>>> transform magnitudes that have no position so you only modify them >>>>> with the >>>>> scale, shear, and rotation aspects of the matrix (i.e. everything >>>>> but the >>>>> translate components). >>>>> >>>>> For some reason I got the impression that Vector was only used to >>>>> represent magnitude because people were bringing up delta >>>>> transforms in the >>>>> context of talking about it. If it is a 1x4 vector then it is just >>>>> Point3D+perspective-w-element, [x,y,z,w] no? Point3D can >>>>> participate in >>>>> 4x4 transforms, supplying an implicit w=1 component, though it >>>>> can't store >>>>> the resulting w component if the matrix doesn't have 0,0,0,1 for >>>>> the last 4 >>>>> elements (i.e. in perspective camera matrices)... >>>>> >>>>> ...jim >>>>> >>>>> >>>>> On 7/24/2012 3:55 PM, Pedro Duque Vieira wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> I've already commented on this in the matrix algebra thread, but I >>>>>>> wanted to throw into this discussion the following point: >>>>>>> I'm neutral on whether or not we need Vector - I'll leave that to >>>>>>> the >>>>>>> people with extensive 3D experience to comment. But, if >>>>>>> transformation >>>>>>> of vectors makes better sense to do a delta transform, and if we are >>>>>>> adding deltaTransform() methods for other types (which I think we >>>>>>> should >>>>>>> do), then I think the "transform" method that does a "delta >>>>>>> transform" >>>>>>> on a Vector should actually be named "deltaTransform" for >>>>>>> consistency, >>>>>>> even if it is obvious that a vector should only be transformed that >>>>>>> way... >>>>>>> >>>>>>> >>>>>> I don't know what a delta transform is (never used it on my 3d work >>>>>> background), so I cannot comment on that part. >>>>>> All I can say is that I did use transform a vector by a given matrix >>>>>> transform and it makes sense. It's basically a multiplication of a >>>>>> 4x4 >>>>>> matrix transform with a 1x4 matrix, just like what happens when you >>>>>> transform a point3d. >>>>>> So I think: >>>>>> - void transform(Vector3d) >>>>>> Should be present on the transform3d class. >>>>>> >>>>>> Just my 2 cents, >>>>>> >>>>>> >>> > > From martin.desruisseaux at geomatys.fr Wed Jul 25 18:52:12 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 26 Jul 2012 03:52:12 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: <50109B2E.3040705@oracle.com> References: <500F2A6F.5050401@oracle.com> <500FFA8B.30703@oracle.com> <77DE75EA-EA4F-4F6C-9184-1A9737714066@oracle.com> <50105BD8.5020503@oracle.com> <50109B2E.3040705@oracle.com> Message-ID: <5010A2CC.40100@geomatys.fr> Hello Jim Le 26/07/12 03:19, Jim Graham a ?crit : > You claim that we need to add new methods if we treat a point as if it > were a vector, but we would have to do that anyway to add methods that > take vector. Maybe the intend was to said "new method names", given that lazy guys like me sometime like to remember only one name and let the compiler figure out the actual method from the parameter type? Just my 2 cents, since I'm neutral on the Vector class vs method name issue. > Furthermore, an array of doubles does not have an "am I a set of > points or vectors" type attached to it so we do need to have 2 > different method names for the methods that take arrays of doubles, > whether or not we create a Vector class (whose sole purpose is to > indicate that its values which are identical in nature to the Point > class are to be considered as magnitudes). Given that the methods expecting array of doubles were proposed for performance reasons when transforming thousands of points, and given that it seems to me that transforming thousands of vectors would be a less frequent operations, do we need the method expecting arrays for delta transforms? Martin From pedro.duquevieira at gmail.com Wed Jul 25 19:22:49 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 26 Jul 2012 03:22:49 +0100 Subject: Transform point using localToSceneTransform Message-ID: Hi Jim, > Hi Pavel, > You claim that we need to add new methods if we treat a point as if it > were a vector, but we would have to do that anyway to add methods that > take vector. > So, we can either add: > transform(Vector) - treats its arg as magnitudes > (and thus does a delta transform) > or we can add: > deltaTransform(Point) - delta transforms the arg > (which is what you want to do with magnitudes) > There is a miss conception here. The proposed Vector isn't merely a representation of a magnitude, it is a magnitude and an angle/direction(although this is not stored internally in the instance) as what exists in java3d and has a set of methods to compute/get vector related stuff: get vector angle, get vector magnitude, get angle between 2 vectors, compute cross product between vectors, etc. It isn't strictly necessary to do a deltaTransform to transform a Vector, one can transform a vector like a point is transformed. > It's a matter of whether the semantics are in the method name or the > argument type. > Furthermore, an array of doubles does not have an "am I a set of points > or vectors" type attached to it so we do need to have 2 different method > names for the methods that take arrays of doubles, whether or not we > create a Vector class (whose sole purpose is to indicate that its values > which are identical in nature to the Point class are to be considered as > magnitudes). If you use homogeneous coordinates notation, than an array of doubles representing the vector will tell you that in fact it is a vector cause the last value will be 0 (in contrast to a point which is 1). > > We can either encapsulate this information in a new class and add lots > of methods for that new class, or we can encapsulate the information on > the naming and documentation of new methods which use old types - both > have equal expense in terms of method counts... > ...jim Thanks, best regards, -- Pedro Duque Vieira From pavel.safrata at oracle.com Wed Jul 25 23:20:32 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 26 Jul 2012 08:20:32 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: References: Message-ID: <5010E1B0.2030509@oracle.com> Hi Jim, On 26.7.2012 4:22, Pedro Duque Vieira wrote: > Hi Jim, > > >> Hi Pavel, >> You claim that we need to add new methods if we treat a point as if it >> were a vector, but we would have to do that anyway to add methods that >> take vector. >> So, we can either add: >> transform(Vector) - treats its arg as magnitudes >> (and thus does a delta transform) >> or we can add: >> deltaTransform(Point) - delta transforms the arg >> (which is what you want to do with magnitudes) >> > There is a miss conception here. The proposed Vector isn't merely a > representation of a magnitude, it is a magnitude and an > angle/direction(although this is not stored internally in the instance) as > what exists in java3d and has a set of methods to compute/get vector > related stuff: get vector angle, get vector magnitude, get angle between 2 > vectors, compute cross product between vectors, etc. Exactly, I think the point is that 'point' is not 'vector' regardless of what workarounds we introduce in method naming and documentation. Those methods would look really weird on Point. > It isn't strictly necessary to do a deltaTransform to transform a Vector, > one can transform a vector like a point is transformed. > > >> It's a matter of whether the semantics are in the method name or the >> argument type. >> Furthermore, an array of doubles does not have an "am I a set of points >> or vectors" type attached to it so we do need to have 2 different method >> names for the methods that take arrays of doubles, whether or not we >> create a Vector class (whose sole purpose is to indicate that its values >> which are identical in nature to the Point class are to be considered as >> magnitudes). > > If you use homogeneous coordinates notation, than an array of doubles > representing the vector will tell you that in fact it is a vector cause the > last value will be 0 (in contrast to a point which is 1). The array of doubles is probably not going to contain the last number, that would unnecessarily enlarge the arrays (which are there for performance reasons). But as Martin suggested, we may not need to handle vectors as arrays of doubles. Also the difference in the not-stored last number brings one more reason for having the classes separate - imagine for instance a toArray() method that wouldn't know what to place there. > > >> We can either encapsulate this information in a new class and add lots >> of methods for that new class, We would add transform(Vector) that would otherwise exist as deltaTransform(Point). What other lots of methods would we need? >> or we can encapsulate the information on >> the naming and documentation of new methods which use old types - both >> have equal expense in terms of method counts... Yes, the same method counts. But for the Point-only solution we would need more method names, more complicated documentation, and most importantly, methods that seem to make no sense (as length on a point). Thanks, Pavel >> ...jim > > Thanks, best regards, > From sebastian.rheinnecker at yworks.com Thu Jul 26 01:06:50 2012 From: sebastian.rheinnecker at yworks.com (Sebastian Rheinnecker) Date: Thu, 26 Jul 2012 10:06:50 +0200 Subject: JavaFX nodes getting desynced In-Reply-To: <501007B9.9060902@oracle.com> References: <500FE54B.7000403@yworks.com> <501007B9.9060902@oracle.com> Message-ID: <5010FA9A.80907@yworks.com> Hello Lubo, thank you very much for pointing me to that bugfix. After some testing, I think this solved the bug. I was chasing it for quite a couple of days now. As for the release of the fix, I really hope this makes it into 2.2, since the use case is the common case for our library. kind regards, Sebastian Rheinnecker Am 25.07.2012 16:50, schrieb Lubomir Nerad: > Hi Sebastian, > > from my investigation it seems that your problem is another > manifestation of the RT-23351 bug > (http://javafx-jira.kenai.com/browse/RT-23351). I wasn't able to > reproduce the problem on the runtime from the JavaFX 3.0 repository > where the bug was fixed. To double-check you can try to use FixedGroup > (or similarly patched layout containers) from Workaround.diff > (attached to the RT-23351). > > Regards, > Lubo > > On 7/25/2012 2:23 PM, Sebastian Rheinnecker wrote: >> Hi, >> >> we experience a strange bug when using a custom animation in which >> the nodes of the SceneGraph are not really at the position they are >> meant to be (or there at all). >> >> I posted the detailled description in the OTN forums including a link >> to the application and screencasts to point out the bug: >> https://forums.oracle.com/forums/thread.jspa?threadID=2417478&tstart=15 >> >> We'd be very glad if someone from the dev team could point us to >> something helpful. >> >> kind regards, >> -- Sebastian Rheinnecker phone: +49 7071 9709050 fax: +49 7071 9709051 yWorks GmbH Vor dem Kreuzberg 28 72070 Tuebingen Germany http://www.yworks.com Managing Directors: Sebastian M?ller, Michael Pfahler Commercial Registry: Stuttgart, Germany, HRB 382340 From kirill.prazdnikov at oracle.com Thu Jul 26 01:10:51 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Thu, 26 Jul 2012 12:10:51 +0400 Subject: Transform point using localToSceneTransform In-Reply-To: <5010E1B0.2030509@oracle.com> References: <5010E1B0.2030509@oracle.com> Message-ID: <5010FB8B.6010609@oracle.com> On 26.07.2012 10:20, Pavel Safrata wrote: > Exactly, I think the point is that 'point' is not 'vector' regardless > of what workarounds we introduce in method naming and documentation. > Those methods would look really weird on Point. Both are from the same R3 space, right ? And we can add them together : Vector speed, position; position += time * speed; I vote for Jim`s approach. If a transform is { M3x3 + Translate }, them - transformPoint (normal transform) would be { P*M3x3 + Translate } - transformVector (delta transform) would be { P*M3x3 } -Kirill From pavel.safrata at oracle.com Thu Jul 26 02:06:28 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 26 Jul 2012 11:06:28 +0200 Subject: Transform point using localToSceneTransform In-Reply-To: <5010FB8B.6010609@oracle.com> References: <5010E1B0.2030509@oracle.com> <5010FB8B.6010609@oracle.com> Message-ID: <50110894.7050209@oracle.com> Hi Kirill, On 26.7.2012 10:10, Kirill.Prazdnikov wrote: > On 26.07.2012 10:20, Pavel Safrata wrote: >> Exactly, I think the point is that 'point' is not 'vector' regardless >> of what workarounds we introduce in method naming and documentation. >> Those methods would look really weird on Point. > > Both are from the same R3 space, right ? Right. > > And we can add them together : > Vector speed, position; > position += time * speed; > > I vote for Jim`s approach. Does it make sense to add two points? I think it doesn't. So if we have Po