From malcolm.lidierth at kcl.ac.uk Sun Sep 1 03:00:43 2013 From: malcolm.lidierth at kcl.ac.uk (Lidierth, Malcolm) Date: Sun, 1 Sep 2013 10:00:43 +0000 Subject: SwingNode not updating cursor shape Message-ID: <8fbe858d6ac74a67ac076e21dcd65972@AMSPR03MB244.eurprd03.prod.outlook.com> With a JPanel displayed in a SwingNode with MouseListeners that change the displayed mouse cursor shape in Swing, no cursor changes are seen when viewing the JPanel in a SwingNode. Should they be? Dr Malcolm Lidierth Senior Lecturer in Physiology Wolfson Centre for Age-Related Diseases Guy's Hospital Campus King's College London London SE1 1UL Ph: +44 (0) 20 7848 6175 From petr.pchelko at oracle.com Sun Sep 1 03:15:13 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Sun, 1 Sep 2013 14:15:13 +0400 Subject: SwingNode not updating cursor shape In-Reply-To: <8fbe858d6ac74a67ac076e21dcd65972@AMSPR03MB244.eurprd03.prod.outlook.com> References: <8fbe858d6ac74a67ac076e21dcd65972@AMSPR03MB244.eurprd03.prod.outlook.com> Message-ID: <16DC59C8-77BF-4F65-B310-261FE0AAFB78@oracle.com> Hello, Malcolm. This is a known issue, it's tracked under https://javafx-jira.kenai.com/browse/RT-31957 This functionality is not implemented yet, I am working on it currently. With best regards. Petr. On Sep 1, 2013, at 2:00 PM, "Lidierth, Malcolm" wrote: > > With a JPanel displayed in a SwingNode with MouseListeners that change the displayed mouse cursor shape in Swing, no cursor changes are seen when viewing the JPanel in a SwingNode. > Should they be? > > Dr Malcolm Lidierth > Senior Lecturer in Physiology > > Wolfson Centre for Age-Related Diseases > Guy's Hospital Campus > King's College London > London SE1 1UL > > Ph: +44 (0) 20 7848 6175 From hang.vo at oracle.com Sun Sep 1 03:32:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 01 Sep 2013 10:32:59 +0000 Subject: hg: openjfx/8/graphics/rt: [RT-32593] - fb: fb cannot load on the pi Message-ID: <20130901103347.7447B62475@hg.openjdk.java.net> Changeset: 89fe014f6435 Author: Assaf Yavani Date: 2013-09-01 13:11 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/89fe014f6435 [RT-32593] - fb: fb cannot load on the pi Problem - fx failed to load with java.lang.UnsatisfiedLinkError when trying to run FX on raspberry pi with fb Analysis - lens platofrm utils was not linked to the .so fix - update the gradle files to include the file in the link command Reviewed by : Daniel B. Patch - http://sthinfra10.se.oracle.com:8060/cru/CR-FX8GFX-309 Tested on device ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle From lehmann at media-interactive.de Sun Sep 1 05:25:35 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Sun, 1 Sep 2013 14:25:35 +0200 Subject: FocusModel too restricted? Message-ID: <5223323F.2020706@media-interactive.de> Hi, I am trying to use FocusModel in a custom property sheet component - it is probably a good idea to reuse as much API as possible and make components work similar to each other. However, the focus model makes this more difficult than it should be: 1. Why is it index-based? With methods like focusNext and focusPrevious it should not really require an ordered, index-based list. The TreeView focus model shows how this requires non-trivial extra effort if the data model is not similar to a plain list. 2. Why is setFocusedItem package private and final? With this I cannot even provide a new method "focus(item)" because I cannot call setFocusedItem internally. My users would have to translate their item into an index to be able to focus it. The TableViewFocusModel seems to have the same problem - but it is in the same package and can simply cheat on package private methods! To make this still work I'd have to provide index-based access to a tree-like data model. And to allow operations like focus(item) I'd have to translate the item to an index to call focus(index) instead - although I don't even need that index, and providing it is extra effort. Does it make sense to lift some of these restrictions? - no index-based requirement - less final/package-private methods Similar things can be said about the selection model... Werner From malcolm.lidierth at kcl.ac.uk Sun Sep 1 06:25:39 2013 From: malcolm.lidierth at kcl.ac.uk (Lidierth, Malcolm) Date: Sun, 1 Sep 2013 13:25:39 +0000 Subject: SwingNode not updating cursor shape In-Reply-To: <16DC59C8-77BF-4F65-B310-261FE0AAFB78@oracle.com> References: <8fbe858d6ac74a67ac076e21dcd65972@AMSPR03MB244.eurprd03.prod.outlook.com>, <16DC59C8-77BF-4F65-B310-261FE0AAFB78@oracle.com> Message-ID: <701b14c750554f69a31adc5d27d25f4b@AMSPR03MB244.eurprd03.prod.outlook.com> Petr - Great. Many thanks. ________________________________________ From:Petr Pchelko Sent: Sunday, September 01, 2013 11:15 AM To: Lidierth, Malcolm Cc: openjfx-dev at openjdk.java.net Subject: Re: SwingNode not updating cursor shape Hello, Malcolm. This is a known issue, it's tracked under https://javafx-jira.kenai.com/browse/RT-31957 This functionality is not implemented yet, I am working on it currently. With best regards. Petr. On Sep 1, 2013, at 2:00 PM, "Lidierth, Malcolm" wrote: > > With a JPanel displayed in a SwingNode with MouseListeners that change the displayed mouse cursor shape in Swing, no cursor changes are seen when viewing the JPanel in a SwingNode. > Should they be? > From jonathan.giles at oracle.com Sun Sep 1 13:44:44 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 02 Sep 2013 08:44:44 +1200 Subject: FocusModel too restricted? In-Reply-To: <5223323F.2020706@media-interactive.de> References: <5223323F.2020706@media-interactive.de> Message-ID: <5223A73C.2030506@oracle.com> Werner, It sounds to me like you're trying to use FocusModel where it may not ideally suit your needs, and rather than roll your own API that is more applicable to your needs, you're hoping to coerce FocusModel to fit to be consistent. Whilst I applaud your eagerness to have an API consistent with the 'official' UI controls, my gut feeling is that this will most probably not be the best approach. The FocusModel API was really designed for row-based UI controls like ListView, TableView, etc, and it may be hard to work into your property sheet component. For this reason I would suggest rolling your own API (and possibly questioning whether a switchable FocusModel is actually necessary for your control in the first place, or whether you can just bake the API directly into the property sheet). Note that in this case the term 'focus' is overloaded, as this refers to the internal 'fake' focus inside these controls - it has nothing to do with 'real' JavaFX focus traversal. In other words, a ListView always has the real focus, even if the ListView FocusModel says that row 1 is focused - this is just for keyboard navigation purposes. For this reason I'm curious if the FocusModel is what you actually want - I would assume that what you are really wanting to do is move the real focus between components in your control? Because of this you'll likely be rewriting all of the FocusModel implementation anyway. To somewhat answer your questions: 1) In general TreeView and TreeTableView have to jump through hoops, as to reuse as much internal implementation code they essentially are treated as if they are lists internally. In actual fact the focusNext / focusPrevious methods almost weren't even added to the original API - they were only added because I thought they were quite useful. For a very long time we were going to be index-only. 2) When designing the FocusModel we were conscious of not providing the same API with different names, so we settled on having a focus(int) method and making the focusedIndex property read-only. This meant that it was not possible for developers to accidentally bind the focus and break the control. As always API design is a game of trade-offs, many of which come back to bite you when you encounter new use cases in the future :-) At this stage it would be essentially impossible to redo the FocusModel to remove the index-based addressing, as it would be a breaking change. It is more possible that more methods could be made public / non-final / not read-only, but they will need to be handled on a case-by-case basis and the first step is to file Jira tweak requests. I hope that helps a little... -- Jonathan On 2/09/2013 12:25 a.m., Werner Lehmann wrote: > Hi, > > I am trying to use FocusModel in a custom property sheet component - > it is probably a good idea to reuse as much API as possible and make > components work similar to each other. However, the focus model makes > this more difficult than it should be: > > 1. Why is it index-based? With methods like focusNext and > focusPrevious it should not really require an ordered, index-based > list. The TreeView focus model shows how this requires non-trivial > extra effort if the data model is not similar to a plain list. > > 2. Why is setFocusedItem package private and final? With this I cannot > even provide a new method "focus(item)" because I cannot call > setFocusedItem internally. My users would have to translate their item > into an index to be able to focus it. The TableViewFocusModel seems to > have the same problem - but it is in the same package and can simply > cheat on package private methods! > > To make this still work I'd have to provide index-based access to a > tree-like data model. And to allow operations like focus(item) I'd > have to translate the item to an index to call focus(index) instead - > although I don't even need that index, and providing it is extra effort. > > Does it make sense to lift some of these restrictions? > - no index-based requirement > - less final/package-private methods > > Similar things can be said about the selection model... > > Werner From pedro.duquevieira at gmail.com Sun Sep 1 16:55:01 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 2 Sep 2013 00:55:01 +0100 Subject: Why is almost everything in the API final Message-ID: Hi, Why is almost everything in the API final? OK, I understand there is a security problem and not making things final could potential open security holes. What I'm puzzled about is that the rest of the JDK doesn't use this pattern and so I wonder if it is still effective this way? I'm asking this because the penalties are significant, since you can not easily extend the API because you can't subclass most framework classes. Thanks, best regards, -- Pedro Duque Vieira From pedro.duquevieira at gmail.com Sun Sep 1 17:01:54 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 2 Sep 2013 01:01:54 +0100 Subject: DateAxis.. Message-ID: Hi, I've created a DateAxis. Basically it extends from ValueAxis and you can pass it dates in the Long format (converting Date to Long and passing in that value). I wonder if this is valuable for the framework (I do see people asking for this) and if so would you like me to submit it for your evaluation and perhaps addition to the framework. Sorry, I'm kind of new to submitting patches... Thanks, best regards, -- Pedro Duque Vieira From pedro.duquevieira at gmail.com Sun Sep 1 17:09:35 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 2 Sep 2013 01:09:35 +0100 Subject: Creating custom chart - "XYBarChart" Message-ID: Hi, Sorry for sending in several emails to the mailing list at once. I'm having some issues while creating a custom chart - a XYBarChart, which is a BarChart that can have both axis as ValueAxis. The main issue I'm having is that there are a lot of fields and methods which are "package private" and I need to access them. I see there is already another person in this mailing list that is also having trouble extending some other part of the framework because of "package private" fields/methods. Maybe there should be more inclination towards making things protected rather than "package private". I can see the problem that this could potentially flood the javadocs with methods and fields but I think that not being able to extend some framework class is worse. Thanks, best regards, -- Pedro Duque Vieira From jonathan.giles at oracle.com Sun Sep 1 17:23:27 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 02 Sep 2013 12:23:27 +1200 Subject: Why is almost everything in the API final In-Reply-To: References: Message-ID: <5223DA7F.5020609@oracle.com> Richard will answer this far more effectively than me, but because he is midway through a long weekend I'll give a quick summary based on my recollection. The big issue is that with properties there are effectively two ways to set or get values: you can of course call the getter or setter, or you can do something like textProperty().get() / textProperty().set(..). Our property implementation is essentially that the getter and setter methods should do nothing more than defer to the property getters / setters. Putting any logic into the getter / setter methods is actually quite dangerous, as it can be easily avoided. For example, if setText(...) were to do a whole range of calculations, these would never be called if the end-user of the API were to call textProperty().set(...) (or if the textProperty was bound to another property). Therefore, in providing getter / setter methods, we are simply providing convenience API to end developers. If the end developer goes on to override these methods in subclasses, only trouble can really come from this: they will add in additional logic that may only be called in some circumstances (and definitely never when the properties are used with bindings). There may be other concerns, but this is the primary issue that I can recollect. If your intention is to subclass classes whose getters / setters are final, you will need to change your approach to instead listen to these properties from your subclass and react accordingly. -- Jonathan On 2/09/2013 11:55 a.m., Pedro Duque Vieira wrote: > Hi, > > Why is almost everything in the API final? OK, I understand there is a > security problem and not making things final could potential open security > holes. > What I'm puzzled about is that the rest of the JDK doesn't use this pattern > and so I wonder if it is still effective this way? > I'm asking this because the penalties are significant, since you can not > easily extend the API because you can't subclass most framework classes. > > Thanks, best regards, > From jonathan.giles at oracle.com Sun Sep 1 17:24:04 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 02 Sep 2013 12:24:04 +1200 Subject: DateAxis.. In-Reply-To: References: Message-ID: <5223DAA4.3040709@oracle.com> My experience has been that there have been many people wanting different kinds of axes (to be clear, the plural spelling of axis, JavaFX isn't going medieval), the most popular being date and logarithmic. If you've developed a DateAxis implementation, that is great! I would recommend searching the jira for such as issue (I can't see one in a quick search), and if one doesn't exist file a tweak / feature request for it. You can attach your patch in the issue by copy/pasting the code, or if it is long you can email the issue owner (which will be Paru Somashekar) or myself, and we can attach the patch to the issue on your behalf. Concurrently with this, there is a need for you to agree to the Oracle Contributor Agreement if you haven't already. You can find more information out here: http://openjdk.java.net/contribute/ The train has well and truly left for JavaFX 8.0, but this could be considered for a release following that. In the mean time, you might be interested in publishing the code yourself, either on your blog or into an open source project such as JFXtras. This is often a great way to evolve the API whilst it still can be. Thanks, -- Jonathan On 2/09/2013 12:01 p.m., Pedro Duque Vieira wrote: > Hi, > > I've created a DateAxis. Basically it extends from ValueAxis and you can > pass it dates in the Long format (converting Date to Long and passing in > that value). > > I wonder if this is valuable for the framework (I do see people asking for > this) and if so would you like me to submit it for your evaluation and > perhaps addition to the framework. > Sorry, I'm kind of new to submitting patches... > > Thanks, best regards, > From hang.vo at oracle.com Sun Sep 1 22:32:25 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Sep 2013 05:32:25 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20130902053429.3E55D62490@hg.openjdk.java.net> Changeset: 3acaf13c190c Author: jgiles Date: 2013-09-02 12:54 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3acaf13c190c RT-32253: Uncaught exception in static initializer for Control prevents creation of all controls ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java Changeset: 2e11c8f35ee5 Author: jgiles Date: 2013-09-02 13:16 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2e11c8f35ee5 RT-31104: TableView makes multiple selection drags difficult ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: bd2c6e6b661a Author: jgiles Date: 2013-09-02 13:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bd2c6e6b661a RT-32620: CheckBox cell factory in tree view unselects every cell ! modules/controls/src/main/java/javafx/scene/control/TreeItem.java Changeset: e60e9a5396e6 Author: jgiles Date: 2013-09-02 17:18 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e60e9a5396e6 RT-29885: Regression: issue with ComboBox focusedProperty ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/java/javafx/scene/control/ComboBox.java ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java From sven.reimers at gmail.com Sun Sep 1 23:06:24 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 2 Sep 2013 08:06:24 +0200 Subject: DateAxis.. In-Reply-To: <5223DAA4.3040709@oracle.com> References: <5223DAA4.3040709@oracle.com> Message-ID: Hi, Is there a place in ControlsFX for chart stuff as well? How about creating a ChartFX stuff if not? -Sven On Mon, Sep 2, 2013 at 2:24 AM, Jonathan Giles wrote: > My experience has been that there have been many people wanting > different kinds of axes (to be clear, the plural spelling of axis, > JavaFX isn't going medieval), the most popular being date and > logarithmic. If you've developed a DateAxis implementation, that is > great! I would recommend searching the jira for such as issue (I can't > see one in a quick search), and if one doesn't exist file a tweak / > feature request for it. You can attach your patch in the issue by > copy/pasting the code, or if it is long you can email the issue owner > (which will be Paru Somashekar) or myself, and we can attach the patch > to the issue on your behalf. > > Concurrently with this, there is a need for you to agree to the Oracle > Contributor Agreement if you haven't already. You can find more > information out here: http://openjdk.java.net/contribute/ > > The train has well and truly left for JavaFX 8.0, but this could be > considered for a release following that. In the mean time, you might be > interested in publishing the code yourself, either on your blog or into > an open source project such as JFXtras. This is often a great way to > evolve the API whilst it still can be. > > Thanks, > > -- Jonathan > > On 2/09/2013 12:01 p.m., Pedro Duque Vieira wrote: > > Hi, > > > > I've created a DateAxis. Basically it extends from ValueAxis and you can > > pass it dates in the Long format (converting Date to Long and passing in > > that value). > > > > I wonder if this is valuable for the framework (I do see people asking > for > > this) and if so would you like me to submit it for your evaluation and > > perhaps addition to the framework. > > Sorry, I'm kind of new to submitting patches... > > > > Thanks, best regards, > > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From christian.schudt at gmx.de Sun Sep 1 23:09:54 2013 From: christian.schudt at gmx.de (Christian Schudt) Date: Mon, 2 Sep 2013 08:09:54 +0200 Subject: DateAxis.. In-Reply-To: References: Message-ID: Hi Pedro, I've developed one, too (with the help of Diego Cirujano). Maybe you want to get ideas from it or contribute yours. It uses java.util.Date. https://bitbucket.org/sco0ter/extfx/src/2b20deb832c2212513034d35464b73c544361c74/src/main/java/extfx/scene/chart/DateAxis.java?at=default Kind regards, Christian Am 02.09.2013 um 02:01 schrieb Pedro Duque Vieira: > Hi, > > I've created a DateAxis. Basically it extends from ValueAxis and you can > pass it dates in the Long format (converting Date to Long and passing in > that value). > > I wonder if this is valuable for the framework (I do see people asking for > this) and if so would you like me to submit it for your evaluation and > perhaps addition to the framework. > Sorry, I'm kind of new to submitting patches... > > Thanks, best regards, > > -- > Pedro Duque Vieira From tom.schindl at bestsolution.at Sun Sep 1 23:57:18 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 2 Sep 2013 08:57:18 +0200 Subject: Creating custom chart - "XYBarChart" In-Reply-To: References: Message-ID: <889B4FDD-5C85-416D-83CB-8BA544D341DB@bestsolution.at> The problem is not the javadocs but that one makes internals of a class API and has to live with it forever. Tom Von meinem iPhone gesendet Am 02.09.2013 um 02:09 schrieb Pedro Duque Vieira : > Hi, > > Sorry for sending in several emails to the mailing list at once. > > I'm having some issues while creating a custom chart - a XYBarChart, which > is a BarChart that can have both axis as ValueAxis. > > The main issue I'm having is that there are a lot of fields and methods > which are "package private" and I need to access them. > I see there is already another person in this mailing list that is also > having trouble extending some other part of the framework because of > "package private" fields/methods. > > Maybe there should be more inclination towards making things protected > rather than "package private". I can see the problem that this could > potentially flood the javadocs with methods and fields but I think that not > being able to extend some framework class is worse. > > Thanks, best regards, > > > -- > Pedro Duque Vieira From diego.cirujano-cuesta at zeiss.com Mon Sep 2 01:21:16 2013 From: diego.cirujano-cuesta at zeiss.com (Diego Cirujano-Cuesta) Date: Mon, 2 Sep 2013 10:21:16 +0200 Subject: DateAxis.. In-Reply-To: References: Message-ID: Hi Pedro, Christian Schudt and me are working in a DateAxis that he create , we are using Christian repo (this url): https://bitbucket.org/sco0ter/extfx/src and then: src/main/java/extfx/scene/chart/DateAxis.java that extends from "Axis". We just have a few problems not important as a consecuence of the layoutChildren performance improvements that are not good for a DateAxis implementation :). Just now we are fixing this issue so you are wellcome to contribute into it and problably you could have new ideas. It might make sence to move it to ControlsFX or JFXtras and have a common solution. Cheers, Diego From: openjfx-dev-request at openjdk.java.net To: openjfx-dev at openjdk.java.net Date: 02.09.2013 08:18 Subject: openjfx-dev Digest, Vol 22, Issue 2 Sent by: openjfx-dev-bounces at openjdk.java.net Send openjfx-dev mailing list submissions to openjfx-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev or, via email, send a message with subject or body 'help' to openjfx-dev-request at openjdk.java.net You can reach the person managing the list at openjfx-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of openjfx-dev digest..." Today's Topics: 1. Re: FocusModel too restricted? (Jonathan Giles) 2. Why is almost everything in the API final (Pedro Duque Vieira) 3. DateAxis.. (Pedro Duque Vieira) 4. Creating custom chart - "XYBarChart" (Pedro Duque Vieira) 5. Re: Why is almost everything in the API final (Jonathan Giles) 6. Re: DateAxis.. (Jonathan Giles) 7. hg: openjfx/8/controls/rt: 4 new changesets (hang.vo at oracle.com) 8. Re: DateAxis.. (Sven Reimers) ---------------------------------------------------------------------- Message: 1 Date: Mon, 02 Sep 2013 08:44:44 +1200 From: Jonathan Giles Subject: Re: FocusModel too restricted? To: openjfx-dev at openjdk.java.net Message-ID: <5223A73C.2030506 at oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Werner, It sounds to me like you're trying to use FocusModel where it may not ideally suit your needs, and rather than roll your own API that is more applicable to your needs, you're hoping to coerce FocusModel to fit to be consistent. Whilst I applaud your eagerness to have an API consistent with the 'official' UI controls, my gut feeling is that this will most probably not be the best approach. The FocusModel API was really designed for row-based UI controls like ListView, TableView, etc, and it may be hard to work into your property sheet component. For this reason I would suggest rolling your own API (and possibly questioning whether a switchable FocusModel is actually necessary for your control in the first place, or whether you can just bake the API directly into the property sheet). Note that in this case the term 'focus' is overloaded, as this refers to the internal 'fake' focus inside these controls - it has nothing to do with 'real' JavaFX focus traversal. In other words, a ListView always has the real focus, even if the ListView FocusModel says that row 1 is focused - this is just for keyboard navigation purposes. For this reason I'm curious if the FocusModel is what you actually want - I would assume that what you are really wanting to do is move the real focus between components in your control? Because of this you'll likely be rewriting all of the FocusModel implementation anyway. To somewhat answer your questions: 1) In general TreeView and TreeTableView have to jump through hoops, as to reuse as much internal implementation code they essentially are treated as if they are lists internally. In actual fact the focusNext / focusPrevious methods almost weren't even added to the original API - they were only added because I thought they were quite useful. For a very long time we were going to be index-only. 2) When designing the FocusModel we were conscious of not providing the same API with different names, so we settled on having a focus(int) method and making the focusedIndex property read-only. This meant that it was not possible for developers to accidentally bind the focus and break the control. As always API design is a game of trade-offs, many of which come back to bite you when you encounter new use cases in the future :-) At this stage it would be essentially impossible to redo the FocusModel to remove the index-based addressing, as it would be a breaking change. It is more possible that more methods could be made public / non-final / not read-only, but they will need to be handled on a case-by-case basis and the first step is to file Jira tweak requests. I hope that helps a little... -- Jonathan On 2/09/2013 12:25 a.m., Werner Lehmann wrote: > Hi, > > I am trying to use FocusModel in a custom property sheet component - > it is probably a good idea to reuse as much API as possible and make > components work similar to each other. However, the focus model makes > this more difficult than it should be: > > 1. Why is it index-based? With methods like focusNext and > focusPrevious it should not really require an ordered, index-based > list. The TreeView focus model shows how this requires non-trivial > extra effort if the data model is not similar to a plain list. > > 2. Why is setFocusedItem package private and final? With this I cannot > even provide a new method "focus(item)" because I cannot call > setFocusedItem internally. My users would have to translate their item > into an index to be able to focus it. The TableViewFocusModel seems to > have the same problem - but it is in the same package and can simply > cheat on package private methods! > > To make this still work I'd have to provide index-based access to a > tree-like data model. And to allow operations like focus(item) I'd > have to translate the item to an index to call focus(index) instead - > although I don't even need that index, and providing it is extra effort. > > Does it make sense to lift some of these restrictions? > - no index-based requirement > - less final/package-private methods > > Similar things can be said about the selection model... > > Werner ------------------------------ Message: 2 Date: Mon, 2 Sep 2013 00:55:01 +0100 From: Pedro Duque Vieira Subject: Why is almost everything in the API final To: OpenJFX Mailing List Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi, Why is almost everything in the API final? OK, I understand there is a security problem and not making things final could potential open security holes. What I'm puzzled about is that the rest of the JDK doesn't use this pattern and so I wonder if it is still effective this way? I'm asking this because the penalties are significant, since you can not easily extend the API because you can't subclass most framework classes. Thanks, best regards, -- Pedro Duque Vieira ------------------------------ Message: 3 Date: Mon, 2 Sep 2013 01:01:54 +0100 From: Pedro Duque Vieira Subject: DateAxis.. To: OpenJFX Mailing List Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi, I've created a DateAxis. Basically it extends from ValueAxis and you can pass it dates in the Long format (converting Date to Long and passing in that value). I wonder if this is valuable for the framework (I do see people asking for this) and if so would you like me to submit it for your evaluation and perhaps addition to the framework. Sorry, I'm kind of new to submitting patches... Thanks, best regards, -- Pedro Duque Vieira ------------------------------ Message: 4 Date: Mon, 2 Sep 2013 01:09:35 +0100 From: Pedro Duque Vieira Subject: Creating custom chart - "XYBarChart" To: OpenJFX Mailing List Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi, Sorry for sending in several emails to the mailing list at once. I'm having some issues while creating a custom chart - a XYBarChart, which is a BarChart that can have both axis as ValueAxis. The main issue I'm having is that there are a lot of fields and methods which are "package private" and I need to access them. I see there is already another person in this mailing list that is also having trouble extending some other part of the framework because of "package private" fields/methods. Maybe there should be more inclination towards making things protected rather than "package private". I can see the problem that this could potentially flood the javadocs with methods and fields but I think that not being able to extend some framework class is worse. Thanks, best regards, -- Pedro Duque Vieira ------------------------------ Message: 5 Date: Mon, 02 Sep 2013 12:23:27 +1200 From: Jonathan Giles Subject: Re: Why is almost everything in the API final To: openjfx-dev at openjdk.java.net Message-ID: <5223DA7F.5020609 at oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Richard will answer this far more effectively than me, but because he is midway through a long weekend I'll give a quick summary based on my recollection. The big issue is that with properties there are effectively two ways to set or get values: you can of course call the getter or setter, or you can do something like textProperty().get() / textProperty().set(..). Our property implementation is essentially that the getter and setter methods should do nothing more than defer to the property getters / setters. Putting any logic into the getter / setter methods is actually quite dangerous, as it can be easily avoided. For example, if setText(...) were to do a whole range of calculations, these would never be called if the end-user of the API were to call textProperty().set(...) (or if the textProperty was bound to another property). Therefore, in providing getter / setter methods, we are simply providing convenience API to end developers. If the end developer goes on to override these methods in subclasses, only trouble can really come from this: they will add in additional logic that may only be called in some circumstances (and definitely never when the properties are used with bindings). There may be other concerns, but this is the primary issue that I can recollect. If your intention is to subclass classes whose getters / setters are final, you will need to change your approach to instead listen to these properties from your subclass and react accordingly. -- Jonathan On 2/09/2013 11:55 a.m., Pedro Duque Vieira wrote: > Hi, > > Why is almost everything in the API final? OK, I understand there is a > security problem and not making things final could potential open security > holes. > What I'm puzzled about is that the rest of the JDK doesn't use this pattern > and so I wonder if it is still effective this way? > I'm asking this because the penalties are significant, since you can not > easily extend the API because you can't subclass most framework classes. > > Thanks, best regards, > ------------------------------ Message: 6 Date: Mon, 02 Sep 2013 12:24:04 +1200 From: Jonathan Giles Subject: Re: DateAxis.. To: openjfx-dev at openjdk.java.net Message-ID: <5223DAA4.3040709 at oracle.com> Content-Type: text/plain; charset=ISO-8859-1 My experience has been that there have been many people wanting different kinds of axes (to be clear, the plural spelling of axis, JavaFX isn't going medieval), the most popular being date and logarithmic. If you've developed a DateAxis implementation, that is great! I would recommend searching the jira for such as issue (I can't see one in a quick search), and if one doesn't exist file a tweak / feature request for it. You can attach your patch in the issue by copy/pasting the code, or if it is long you can email the issue owner (which will be Paru Somashekar) or myself, and we can attach the patch to the issue on your behalf. Concurrently with this, there is a need for you to agree to the Oracle Contributor Agreement if you haven't already. You can find more information out here: http://openjdk.java.net/contribute/ The train has well and truly left for JavaFX 8.0, but this could be considered for a release following that. In the mean time, you might be interested in publishing the code yourself, either on your blog or into an open source project such as JFXtras. This is often a great way to evolve the API whilst it still can be. Thanks, -- Jonathan On 2/09/2013 12:01 p.m., Pedro Duque Vieira wrote: > Hi, > > I've created a DateAxis. Basically it extends from ValueAxis and you can > pass it dates in the Long format (converting Date to Long and passing in > that value). > > I wonder if this is valuable for the framework (I do see people asking for > this) and if so would you like me to submit it for your evaluation and > perhaps addition to the framework. > Sorry, I'm kind of new to submitting patches... > > Thanks, best regards, > ------------------------------ Message: 7 Date: Mon, 02 Sep 2013 05:32:25 +0000 From: hang.vo at oracle.com Subject: hg: openjfx/8/controls/rt: 4 new changesets To: openjfx-dev at openjdk.java.net Message-ID: <20130902053429.3E55D62490 at hg.openjdk.java.net> Changeset: 3acaf13c190c Author: jgiles Date: 2013-09-02 12:54 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3acaf13c190c RT-32253: Uncaught exception in static initializer for Control prevents creation of all controls ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java Changeset: 2e11c8f35ee5 Author: jgiles Date: 2013-09-02 13:16 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2e11c8f35ee5 RT-31104: TableView makes multiple selection drags difficult ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: bd2c6e6b661a Author: jgiles Date: 2013-09-02 13:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bd2c6e6b661a RT-32620: CheckBox cell factory in tree view unselects every cell ! modules/controls/src/main/java/javafx/scene/control/TreeItem.java Changeset: e60e9a5396e6 Author: jgiles Date: 2013-09-02 17:18 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e60e9a5396e6 RT-29885: Regression: issue with ComboBox focusedProperty ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/java/javafx/scene/control/ComboBox.java ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java ------------------------------ Message: 8 Date: Mon, 2 Sep 2013 08:06:24 +0200 From: Sven Reimers Subject: Re: DateAxis.. To: "jonathan.giles at oracle.com" Cc: openjfx mailing list Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi, Is there a place in ControlsFX for chart stuff as well? How about creating a ChartFX stuff if not? -Sven On Mon, Sep 2, 2013 at 2:24 AM, Jonathan Giles wrote: > My experience has been that there have been many people wanting > different kinds of axes (to be clear, the plural spelling of axis, > JavaFX isn't going medieval), the most popular being date and > logarithmic. If you've developed a DateAxis implementation, that is > great! I would recommend searching the jira for such as issue (I can't > see one in a quick search), and if one doesn't exist file a tweak / > feature request for it. You can attach your patch in the issue by > copy/pasting the code, or if it is long you can email the issue owner > (which will be Paru Somashekar) or myself, and we can attach the patch > to the issue on your behalf. > > Concurrently with this, there is a need for you to agree to the Oracle > Contributor Agreement if you haven't already. You can find more > information out here: http://openjdk.java.net/contribute/ > > The train has well and truly left for JavaFX 8.0, but this could be > considered for a release following that. In the mean time, you might be > interested in publishing the code yourself, either on your blog or into > an open source project such as JFXtras. This is often a great way to > evolve the API whilst it still can be. > > Thanks, > > -- Jonathan > > On 2/09/2013 12:01 p.m., Pedro Duque Vieira wrote: > > Hi, > > > > I've created a DateAxis. Basically it extends from ValueAxis and you can > > pass it dates in the Long format (converting Date to Long and passing in > > that value). > > > > I wonder if this is valuable for the framework (I do see people asking > for > > this) and if so would you like me to submit it for your evaluation and > > perhaps addition to the framework. > > Sorry, I'm kind of new to submitting patches... > > > > Thanks, best regards, > > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 End of openjfx-dev Digest, Vol 22, Issue 2 ****************************************** ---------------------------------------- This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. From artem.ananiev at oracle.com Mon Sep 2 01:36:55 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Sep 2013 12:36:55 +0400 Subject: Why is almost everything in the API final In-Reply-To: References: Message-ID: <52244E27.2010103@oracle.com> As Jonathan said, Richard is the best person to answer this question, but let me provide my own thoughts below as well. On 9/2/2013 3:55 AM, Pedro Duque Vieira wrote: > Hi, > > Why is almost everything in the API final? OK, I understand there is a > security problem and not making things final could potential open security > holes. It's not only about security. When API is final, it is easy to maintain and it is essential for backwards compatibility. Library developers know exactly, how classes and methods are used and how they can be evolved in the future. As a AWT/Swing maintainer I've seen many cases, when non-final classes were extended in a crazy way and used for absolutely different purposes than they were initially designed for. Note that changing class/method/field from final to non-final is a backwards compatible change, but the reverse is not. > What I'm puzzled about is that the rest of the JDK doesn't use this pattern > and so I wonder if it is still effective this way? I'm sure if JDK developers didn't have to preserve backwards compatibility, they would be glad to make everything final :) > I'm asking this because the penalties are significant, since you can not > easily extend the API because you can't subclass most framework classes. Could you provide any examples, please? > Thanks, best regards, Thanks, Artem From artem.ananiev at oracle.com Mon Sep 2 01:55:10 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Sep 2013 12:55:10 +0400 Subject: Result: New OpenJFX Committer: Felipe Heidrich In-Reply-To: <520D118E.10900@oracle.com> References: <520D118E.10900@oracle.com> Message-ID: <5224526E.4040706@oracle.com> Voting for Felipe Heidrich to OpenJFX Committer [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-August/009726.html [2] http://openjdk.java.net/projects/#project-committer Thanks, Artem From artem.ananiev at oracle.com Mon Sep 2 01:56:06 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Sep 2013 12:56:06 +0400 Subject: Result: New OpenJFX Committer: Mick Fleming In-Reply-To: <520D19C0.30205@oracle.com> References: <520D19C0.30205@oracle.com> Message-ID: <522452A6.7060804@oracle.com> Voting for Mick Fleming to OpenJFX Committer [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-August/009732.html [2] http://openjdk.java.net/projects/#project-committer Thanks, Artem From artem.ananiev at oracle.com Mon Sep 2 01:58:08 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Sep 2013 12:58:08 +0400 Subject: Result: New OpenJFX Committer: Chien Yang In-Reply-To: <520CF8AF.9040905@oracle.com> References: <520CF8AF.9040905@oracle.com> Message-ID: <52245320.5000809@oracle.com> Voting for Chien Yang to OpenJFX Committer [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-August/009720.html [2] http://openjdk.java.net/projects/#project-committer Thanks, Artem From artem.ananiev at oracle.com Mon Sep 2 02:00:31 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Sep 2013 13:00:31 +0400 Subject: Result: New OpenJFX Committer: Alexander Zvegintsev In-Reply-To: <520CCC4E.7070104@oracle.com> References: <520CCC4E.7070104@oracle.com> Message-ID: <522453AF.4090902@oracle.com> Voting for Alexander Zvegintsev to OpenJFX Committer [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-August/009710.html [2] http://openjdk.java.net/projects/#project-committer Thanks, Artem From tomas.mikula at gmail.com Mon Sep 2 05:22:46 2013 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 2 Sep 2013 14:22:46 +0200 Subject: replace a section of ObservableList in one operation? Message-ID: Hi, I cannot find a way to replace a section of ObservableList in one operation. I'm looking for something like ObservableList#setAll(int from, int to, Collection col) or list.subList(from, to).setAll(col). In the latter case, ObservableList#subList() would have to return an instance of ObservableList, not just List. I know I can use a pair of remove() and addAll(), but my objective is to generate just 1 change event. Is there a way to achieve this? Thank you, Tomas From tom.schindl at bestsolution.at Mon Sep 2 05:33:21 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 02 Sep 2013 14:33:21 +0200 Subject: replace a section of ObservableList in one operation? In-Reply-To: References: Message-ID: <52248591.20304@bestsolution.at> I don't think there's API for this so the only idea is to copy the list to an ArrayList, do the replace there and afterwards call ObservableList#setAll(). Tom On 02.09.13 14:22, Tomas Mikula wrote: > Hi, > > I cannot find a way to replace a section of ObservableList in one > operation. I'm looking for something like > > ObservableList#setAll(int from, int to, Collection col) > > or > > list.subList(from, to).setAll(col). > > In the latter case, ObservableList#subList() would have to return an > instance of ObservableList, not just List. > > I know I can use a pair of remove() and addAll(), but my objective is > to generate just 1 change event. > Is there a way to achieve this? > > Thank you, > Tomas > From hang.vo at oracle.com Mon Sep 2 05:32:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Sep 2013 12:32:17 +0000 Subject: hg: openjfx/8/graphics/rt: Android: Fix failing build. Use lens_wm_notifyMultiTouchEvent instead of lens_wm_notifyTouchEvent Message-ID: <20130902123303.52E276249B@hg.openjdk.java.net> Changeset: f0620fe44d8a Author: tb115823 Date: 2013-09-02 14:22 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f0620fe44d8a Android: Fix failing build. Use lens_wm_notifyMultiTouchEvent instead of lens_wm_notifyTouchEvent ! buildSrc/android.gradle ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c From martin.sladecek at oracle.com Mon Sep 2 05:40:34 2013 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 02 Sep 2013 14:40:34 +0200 Subject: replace a section of ObservableList in one operation? In-Reply-To: References: Message-ID: <52248742.6020706@oracle.com> Hi Tomas, unfortunately, this is not possible. I have filed a JIRA issue https://javafx-jira.kenai.com/browse/RT-32655 for the setAll method with range. The subList doesn't return an ObservableList, as the sublists become invalid once there's some structural change on the list. That would mean to watch and (silently) invalidate the listeners too, which might be confusing. -Martin On 09/02/2013 02:22 PM, Tomas Mikula wrote: > Hi, > > I cannot find a way to replace a section of ObservableList in one > operation. I'm looking for something like > > ObservableList#setAll(int from, int to, Collection col) > > or > > list.subList(from, to).setAll(col). > > In the latter case, ObservableList#subList() would have to return an > instance of ObservableList, not just List. > > I know I can use a pair of remove() and addAll(), but my objective is > to generate just 1 change event. > Is there a way to achieve this? > > Thank you, > Tomas From hang.vo at oracle.com Mon Sep 2 05:47:21 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Sep 2013 12:47:21 +0000 Subject: hg: openjfx/8/controls/rt: RT-31901 - Regression: scrollbar issue with TitledPane Message-ID: <20130902124752.6EB0C6249D@hg.openjdk.java.net> Changeset: 3f656fbd508f Author: mickf Date: 2013-09-02 13:44 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3f656fbd508f RT-31901 - Regression: scrollbar issue with TitledPane ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From hang.vo at oracle.com Mon Sep 2 05:17:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Sep 2013 12:17:16 +0000 Subject: hg: openjfx/8/controls/rt: RT-32654 : ScrollPane - remove DOS line endings, no code changed Message-ID: <20130902121905.71BFB62499@hg.openjdk.java.net> Changeset: 18a02cf34ddf Author: mickf Date: 2013-09-02 13:14 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/18a02cf34ddf RT-32654 : ScrollPane - remove DOS line endings, no code changed ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From hang.vo at oracle.com Mon Sep 2 06:47:30 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Sep 2013 13:47:30 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32565 Gtk: mouse grab issue with dialogs activated from mouse handler Message-ID: <20130902134811.04BB8624A2@hg.openjdk.java.net> Changeset: ad37f3adc5df Author: Alexander Zvegintsev Date: 2013-09-02 17:37 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ad37f3adc5df RT-32565 Gtk: mouse grab issue with dialogs activated from mouse handler ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp From tomas.mikula at gmail.com Mon Sep 2 07:39:53 2013 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 2 Sep 2013 16:39:53 +0200 Subject: replace a section of ObservableList in one operation? In-Reply-To: References: Message-ID: Hi Tom, > I don't think there's API for this so the only idea is to copy the list > to an ArrayList, do the replace there and afterwards call > ObservableList#setAll(). yes, that solves the problem of generating just a single change, but the change is unnecessarily big. Martin, thanks for opening the issue. > I have filed a JIRA issue https://javafx-jira.kenai.com/browse/RT-32655 > for the setAll method with range. Best, Tomas From hang.vo at oracle.com Mon Sep 2 07:17:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Sep 2013 14:17:10 +0000 Subject: hg: openjfx/8/graphics/rt: iOS: Ensemble8 - fixing check for iOS; removing ScrollEvent synthesis for iOS - not needed; we have native scroll events + momentum/inertia Message-ID: <20130902141729.EE50B624A3@hg.openjdk.java.net> Changeset: b3d0c8df51b6 Author: Oldrich Maticka Date: 2013-09-02 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b3d0c8df51b6 iOS: Ensemble8 - fixing check for iOS; removing ScrollEvent synthesis for iOS - not needed; we have native scroll events + momentum/inertia ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java From hang.vo at oracle.com Mon Sep 2 08:32:30 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Sep 2013 15:32:30 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130902153318.60E32624A5@hg.openjdk.java.net> Changeset: 42e1b2938f98 Author: Rafi Tayar Date: 2013-09-02 18:19 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/42e1b2938f98 RT-32468 Lens: Touch keyboard is not reliable on Raspberry Pi ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c Changeset: 3c9ebc34f4b7 Author: Rafi Tayar Date: 2013-09-02 18:19 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3c9ebc34f4b7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt From christian.schudt at gmx.de Mon Sep 2 09:10:17 2013 From: christian.schudt at gmx.de (Christian Schudt) Date: Mon, 2 Sep 2013 18:10:17 +0200 Subject: Why is almost everything in the API final In-Reply-To: <52244E27.2010103@oracle.com> References: <52244E27.2010103@oracle.com> Message-ID: <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> I agree with that and I also recommend to have a look at "Item 17: Design and document for inheritance or else prohibit it" from Effective Java. http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.3000th.Release.pdf It explains the burden and dangers of non-final design quite well. Christian Am 02.09.2013 um 10:36 schrieb Artem Ananiev: > > As Jonathan said, Richard is the best person to answer this question, but let me provide my own thoughts below as well. > > On 9/2/2013 3:55 AM, Pedro Duque Vieira wrote: >> Hi, >> >> Why is almost everything in the API final? OK, I understand there is a >> security problem and not making things final could potential open security >> holes. > > It's not only about security. When API is final, it is easy to maintain and it is essential for backwards compatibility. Library developers know exactly, how classes and methods are used and how they can be evolved in the future. As a AWT/Swing maintainer I've seen many cases, when non-final classes were extended in a crazy way and used for absolutely different purposes than they were initially designed for. > > Note that changing class/method/field from final to non-final is a backwards compatible change, but the reverse is not. > >> What I'm puzzled about is that the rest of the JDK doesn't use this pattern >> and so I wonder if it is still effective this way? > > I'm sure if JDK developers didn't have to preserve backwards compatibility, they would be glad to make everything final :) > >> I'm asking this because the penalties are significant, since you can not >> easily extend the API because you can't subclass most framework classes. > > Could you provide any examples, please? > >> Thanks, best regards, > > Thanks, > > Artem From sven.reimers at gmail.com Mon Sep 2 09:13:17 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 2 Sep 2013 18:13:17 +0200 Subject: Small API Tweak to Task (Worker) Message-ID: Hi, I am trying to build a UI representation of a Task (using a ProgressBar and other things). Since Tasks are cancellabe I thought about adding a button to cancel the underlying Task. So far so good. Is there any reason why a Task can not express, if it is intended for the task to act cooperative to a call to cancel? Something along the following lines public boolean isCancellable() { return true; } // default This would enable users of the API to distinguish between Tasks which really can be cancelled from those which just fulfill the API contract. Comments? -Sven -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From Fabrizio.Giudici at tidalwave.it Mon Sep 2 09:37:52 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 02 Sep 2013 18:37:52 +0200 Subject: Why is almost everything in the API final In-Reply-To: <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> Message-ID: On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt wrote: > I agree with that and I also recommend to have a look at "Item 17: > Design and document for inheritance or else prohibit it" from Effective > Java. > > http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.3000th.Release.pdf > > It explains the burden and dangers of non-final design quite well. +1 -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From lehmann at media-interactive.de Mon Sep 2 10:55:09 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 2 Sep 2013 19:55:09 +0200 Subject: FocusModel too restricted? In-Reply-To: <5223A73C.2030506@oracle.com> References: <5223323F.2020706@media-interactive.de> <5223A73C.2030506@oracle.com> Message-ID: <5224D0FD.20203@media-interactive.de> Jonathan, appreciate your elaborate answer. I arrived at the same conlusion, not to use the "official" FocusModel. There wasn't any hope to get changes for 2.2 anyway. It just felt as if it could have been a good match because a subset of it would fit perfectly, namely the focused item property and methods to focus the next/prev item. I wouldn't have supported a pluggable focusmodel anyway, there's not much to gain from that. In the end I guess my point is that TreeView and TreeTableView would have benefitted from the above mentioned subset with item-based focusing as well. In a treeview you don't really care about the focused index. I think. Especially if it changes everytime something is expanded or collapsed. And ListView etc. would extend that simple focusmodel to add index-based focus operations. As to the "fake" focus inside a listview vs this property sheet component: currently I am supporting something like a focused row with property name and editor. This row is highlighted and can be (fake-)focused even if the property editor is disabled. So it is similar to a Listview. Basically, having a fake focus does not mean I cannot have a "real" focus on a property editor, too ;-) Werner From snfuchs at gmx.de Mon Sep 2 11:00:40 2013 From: snfuchs at gmx.de (Stefan Fuchs) Date: Mon, 02 Sep 2013 20:00:40 +0200 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> Message-ID: <5224D248.6000003@gmx.de> Fabrizio Giudici wrote: > On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt > wrote: > >> I agree with that and I also recommend to have a look at "Item 17: >> Design and document for inheritance or else prohibit it" from >> Effective Java. >> >> http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.3000th.Release.pdf >> >> >> It explains the burden and dangers of non-final design quite well. > > +1 > > -1 This applies only to the perfect (final) framework. In other words for a framework without bugs and a framework, where all possible usecases are considered by its author. I agree that there are dangers, when overwriting methods. But in my experience they rarely matter. Once created methods rarely change in a way that affects subclasses. And for major releases of the framework you have to test your application anyway. If you develop a framework, where methods have complex interdependencies you should step back and write smaller, more manageable methods. There are always legitimate reasons to overwrite methods. e.G.: To work around a bug in the framework. To trigger events, when a certain method has been called, to write debug info in a logfile,.... And no I don't want to roll out my own fork of jdk to my customers to do this.... From richard.bair at oracle.com Mon Sep 2 12:01:52 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 2 Sep 2013 12:01:52 -0700 Subject: Why is almost everything in the API final In-Reply-To: <5224D248.6000003@gmx.de> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> Message-ID: <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> > This applies only to the perfect (final) framework. > In other words for a framework without bugs and a framework, where all possible usecases are considered by its author. > > I agree that there are dangers, when overwriting methods. But in my experience they rarely matter. Once created methods rarely change in a way that affects subclasses. Subclassing breaks encapsulation. That's the fundamental reason why you must design with care to allow for subclassing, or prohibit it. Making all the fields of a class public would give developers increased power -- but of course this breaks encapsulation, so we avoid it. We broke people all the time in Swing. It was very difficult to make even modest bug fixes in Swing without breaking somebody. Changing the order of calls in a method, broke people. When your framework or API is being used by millions of programs and the program authors have no way of knowing which version of your framework they might be running on (the curse of a shared install of the JRE!), then you find an awful lot of wisdom in making everything final you possibly can. It isn't just to protect your own freedom, it actually creates a better product for everybody. You think you want to subclass and override, but this comes with a significant downside. The framework author isn't going to be able to make things better for you in the future. There's more to it though. When you design an API, you have to think about the combinations of all things allowed by a developer. When you allow subclassing, you open up a tremendous number of additional possible failure modes, so you need to do so with care. Allowing a subclass but limiting what a superclass allows for redefinition reduces failure modes. One of my ideals in API design is to create an API with as much power as possible while reducing the number of failure modes. It is challenging to do so while also providing enough flexibility for developers to do what they need to do, and if I have to choose, I will always err on the side of giving less API in a release, because you can always add more API later, but once you've released an API you're stuck with it, or you will break people. And in this case, API doesn't just mean the method signature, it means the behavior when certain methods are invoked (as Josh points out in Effective Java). The getter / setter method problem Jonathan described is a perfect example. If we make those methods non-final, then indeed it allows a subclass to override and log calls. But that's about all it is good for. If the subclass were to never call super, then we will be broken (and their app as well!). They think they're disallowing a certain input value, but they're not. Or the getter returns a value other than what the property object holds. Or listener notification doesn't happen right or at the right time. Or the wrong instance of the property object is returned. Two things I really like: final, and immutability. GUI's however tend to favor big class hierarchies and mutable state :-). But we use final and immutability as much as we can. Richard From pedro.duquevieira at gmail.com Mon Sep 2 13:10:19 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 2 Sep 2013 21:10:19 +0100 Subject: No subject Message-ID: > > > On Mon, 02 Sep 2013 18:10:17 +0200, Christian Schudt > > wrote: > > > >> I agree with that and I also recommend to have a look at "Item 17: > >> Design and document for inheritance or else prohibit it" from > >> Effective Java. > >> > >> > http://uet.vnu.edu.vn/~chauttm/e-books/java/Effective.Java.2nd.Edition.May.2008.3000th.Release.pdf > >> > >> > >> It explains the burden and dangers of non-final design quite well. > > > > +1 > > > > > -1 > This applies only to the perfect (final) framework. > In other words for a framework without bugs and a framework, where all > possible usecases are considered by its author. > I agree that there are dangers, when overwriting methods. But in my > experience they rarely matter. Once created methods rarely change in a > way that affects subclasses. And for major releases of the framework you > have to test your application anyway. > If you develop a framework, where methods have complex interdependencies > you should step back and write smaller, more manageable methods. > There are always legitimate reasons to overwrite methods. e.G.: To work > around a bug in the framework. To trigger events, when a certain method > has been called, to write debug info in a logfile,.... And no I don't > want to roll out my own fork of jdk to my customers to do this.... -- -1 as well. One of the major points of Java is that it is an object oriented language. By making things final you kill one of the major O.O. benefits, that is subclassing. You can do composition but it's not the same thing as you can not pass in the object to methods that accept the composed class. Though, I also agree that it should be difficult to create a framework where all use cases of subclassing a class are accounted for, especially when you have to preserve backwards compatibility. Best regards, Pedro Duque Vieira From tom.schindl at bestsolution.at Mon Sep 2 13:38:17 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 02 Sep 2013 22:38:17 +0200 Subject: ScrollBar & visibleAmount & value Message-ID: <5224F739.8060908@bestsolution.at> Hi, Before fileing a bug I wanted to post here because maybe I get this completely wrong. Say we have have a scrollbar with min = 0 & max = 100 & visualAmount = 50. I would have expected like in Swing & SWT that the maximum value of the scrollbar is 50 (=max - visualAmount) but the value is still 100. Is this desired or an oversight? I can work around this problem by calculating the value back using ((max-visualAmount)/max)*value but like I said this is unexpected when coming from the other toolkits. Tom From richard.bair at oracle.com Mon Sep 2 16:40:56 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 2 Sep 2013 16:40:56 -0700 Subject: ScrollBar & visibleAmount & value In-Reply-To: <5224F739.8060908@bestsolution.at> References: <5224F739.8060908@bestsolution.at> Message-ID: <6CA11539-B9B0-4973-A161-E513B0AAE04F@oracle.com> Oh interesting, I always considered visibleAmount as being an independent state that affected the size of the scroll bar thumb, but not really anything more. The reason why was for virtualized uses like with ListView where the height of the thumb might change as you scroll. On Sep 2, 2013, at 1:38 PM, Tom Schindl wrote: > Hi, > > Before fileing a bug I wanted to post here because maybe I get this > completely wrong. > > Say we have have a scrollbar with min = 0 & max = 100 & visualAmount = > 50. I would have expected like in Swing & SWT that the maximum value of > the scrollbar is 50 (=max - visualAmount) but the value is still 100. > > Is this desired or an oversight? I can work around this problem by > calculating the value back using ((max-visualAmount)/max)*value but like > I said this is unexpected when coming from the other toolkits. > > Tom From tbee at tbee.org Mon Sep 2 22:16:06 2013 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 03 Sep 2013 07:16:06 +0200 Subject: Why is almost everything in the API final In-Reply-To: <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> Message-ID: <52257096.5070503@tbee.org> On 2013-09-02 21:01, Richard Bair wrote: > you have to think about the combinations of all things allowed by a developer. Since it is impossible to think of and design upfront for all possible usages, and impossible to write error free code, I'm not sure I agree with the approach chosen. Immutability yes, final... Not so much. Because Swing was not final, it allowed for its users to fix and improve a lot of things (SwingX), while still using the improved class like it were the original component, and thus still be able to use other people's code. I've already experienced the amount of additional work that needs to do be done by reuse instead of inheritance in JavaFX. My impression is that if you're using a lot of final, than more interfaces are required in order to allow the 'impersonation' of classes (for a lack of a better word). AFAIK there was never a framework that used final a lot, so time will tell if the choice was right. Swing and the JDK made it this far. But I'm suspecting the choice may have been made motivated more from the perspective of the developers of the framework (a few people) and not as much from the users (many people). We'll see if, when serious issues are found, if they can be patched outside of the main code. Or if people are able to modify behavior enough to match their need, or need to write stuff from scratch. And if this out weighs the breaking compatibility issue. The truth probably is somewhere in the middle. From hang.vo at oracle.com Mon Sep 2 22:17:23 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 05:17:23 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130903051813.726FA624B8@hg.openjdk.java.net> Changeset: 74c06be0319b Author: jgiles Date: 2013-09-03 16:46 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/74c06be0319b RT-31093: Drag doesn't start from Date Picker text field The same problem existed for ComboBox, so it is now resolved in both places. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java Changeset: cb91a18c5738 Author: jgiles Date: 2013-09-03 17:08 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cb91a18c5738 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Mon Sep 2 23:02:40 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 06:02:40 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32600 Lens: Pulse starvation because of overwhelming amount of MOUSE_MOVED events Message-ID: <20130903060346.1163D624BA@hg.openjdk.java.net> Changeset: b2c061caf644 Author: Daniel Blaukopf Date: 2013-09-03 08:55 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b2c061caf644 RT-32600 Lens: Pulse starvation because of overwhelming amount of MOUSE_MOVED events ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java From Fabrizio.Giudici at tidalwave.it Mon Sep 2 23:34:06 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Tue, 03 Sep 2013 08:34:06 +0200 Subject: Why is almost everything in the API final In-Reply-To: <52257096.5070503@tbee.org> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> Message-ID: On Tue, 03 Sep 2013 07:16:06 +0200, Tom Eugelink wrote: > AFAIK there was never a framework that used final a lot, so time will > tell if the choice was right. Swing and the JDK made it this far. But The NetBeans Platform API does use final a lot for the same rationale we're discussing now. > I'm suspecting the choice may have been made motivated more from the > perspective of the developers of the framework (a few people) and not as > much from the users (many people). That's true, but you're misusing the perspective. Many users would only see some minor impact of extending a class, while the few developers would see the accumulation of a huge number of problems because those minor things are multiplied by the large number of users. It's precisely by putting oneself in the perspective of the developers that 'final' makes sense. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From hang.vo at oracle.com Tue Sep 3 01:02:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 08:02:43 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130903080316.0F1F4624BE@hg.openjdk.java.net> Changeset: 514d70fdc70c Author: tb115823 Date: 2013-09-03 09:47 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/514d70fdc70c Android: Fixed renamed prism property glDepthSize. Default value 24 doesn't work on GT10.1 must be 16. Although such eglconfig is available glCreateContext fails with BAD_EGL_CONFIG 3005 error. Don't know why, need to investigate. ! buildSrc/android.gradle Changeset: 655f1ead4bc8 Author: tb115823 Date: 2013-09-03 09:47 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/655f1ead4bc8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt From hang.vo at oracle.com Tue Sep 3 03:47:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 10:47:42 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20130903104910.4DC7E624BF@hg.openjdk.java.net> Changeset: d04fe4c584d4 Author: Lubomir Nerad Date: 2013-09-03 14:41 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d04fe4c584d4 Include debug info in native for debug build ! buildSrc/ios.gradle Changeset: f56e0d2cbfc7 Author: Martin Sladecek Date: 2013-09-03 12:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f56e0d2cbfc7 RT-32657 Teleportation of animated object during TranslateTransition ! modules/graphics/src/main/java/javafx/animation/Animation.java ! modules/graphics/src/test/java/javafx/animation/AnimationTest.java Changeset: 357f66506342 Author: Martin Sladecek Date: 2013-09-03 12:44 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/357f66506342 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt From hang.vo at oracle.com Tue Sep 3 04:17:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 11:17:06 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29095: Dragging from Swing to JavaFX (JFXPanel) that was working in JavaFX 2.2 fails in JavaFX 8.0 Message-ID: <20130903111722.C37E2624C0@hg.openjdk.java.net> Changeset: 391542e56deb Author: Artem Ananiev Date: 2013-09-03 15:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/391542e56deb RT-29095: Dragging from Swing to JavaFX (JFXPanel) that was working in JavaFX 2.2 fails in JavaFX 8.0 Reviewed-by: Kevin Rushforth, Pavel ??afrata ! modules/graphics/src/main/java/com/sun/javafx/tk/TKDragGestureListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKDropTargetListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSceneDnDEventHandler.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/scene/input/DataFormat.java ! modules/graphics/src/main/java/javafx/scene/input/Dragboard.java From hang.vo at oracle.com Tue Sep 3 05:17:24 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 12:17:24 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32661: Regression Mac OS : some keycode accelerators are badly rendered Message-ID: <20130903121745.8B0FE624C1@hg.openjdk.java.net> Changeset: 5946bd72bbc0 Author: pchelko Date: 2013-09-03 16:13 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5946bd72bbc0 RT-32661: Regression Mac OS : some keycode accelerators are badly rendered Reviewed-by: art, Alexander Zvegintsev ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java ! modules/graphics/src/main/native-glass/mac/GlassKey.m From tom.schindl at bestsolution.at Tue Sep 3 05:20:30 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 03 Sep 2013 14:20:30 +0200 Subject: ScrollBar & visibleAmount & value In-Reply-To: <6CA11539-B9B0-4973-A161-E513B0AAE04F@oracle.com> References: <5224F739.8060908@bestsolution.at> <6CA11539-B9B0-4973-A161-E513B0AAE04F@oracle.com> Message-ID: <5225D40E.6000304@bestsolution.at> Well like I said Swing & SWT do interpret this different! To me the value always meant to the upper ending of the thumb. If you think about edge cases of 99 (value still goes from 0..100) and 100 (value can 0 only). Anyways from your answer I guess the current behavior is correct and no ticket needs to be filed and I have to do the calculation from below to match API contract of the library. Tom On 03.09.13 01:40, Richard Bair wrote: > Oh interesting, I always considered visibleAmount as being an independent state that affected the size of the scroll bar thumb, but not really anything more. The reason why was for virtualized uses like with ListView where the height of the thumb might change as you scroll. > > > On Sep 2, 2013, at 1:38 PM, Tom Schindl wrote: > >> Hi, >> >> Before fileing a bug I wanted to post here because maybe I get this >> completely wrong. >> >> Say we have have a scrollbar with min = 0 & max = 100 & visualAmount = >> 50. I would have expected like in Swing & SWT that the maximum value of >> the scrollbar is 50 (=max - visualAmount) but the value is still 100. >> >> Is this desired or an oversight? I can work around this problem by >> calculating the value back using ((max-visualAmount)/max)*value but like >> I said this is unexpected when coming from the other toolkits. >> >> Tom > From hang.vo at oracle.com Tue Sep 3 05:32:19 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 12:32:19 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31873: [SwingNode] : Something throws NullPointerException Message-ID: <20130903123236.2795F624C2@hg.openjdk.java.net> Changeset: 94e96dbe02db Author: Petr Pchelko Date: 2013-09-03 16:21 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/94e96dbe02db RT-31873: [SwingNode] : Something throws NullPointerException Reviewed-by: ant, art ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java From hang.vo at oracle.com Tue Sep 3 06:02:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 13:02:49 +0000 Subject: hg: openjfx/8/controls/rt: RT-32676 - ProgressIndicator : possible null timeline if clipped, and then set invisible. Message-ID: <20130903130341.4C2E0624C3@hg.openjdk.java.net> Changeset: e7d52acb03ee Author: mickf Date: 2013-09-03 13:45 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e7d52acb03ee RT-32676 - ProgressIndicator : possible null timeline if clipped, and then set invisible. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java From martin.sladecek at oracle.com Tue Sep 3 06:11:23 2013 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Tue, 03 Sep 2013 15:11:23 +0200 Subject: [API Review] : Baseline offset depends on layout bounds which are calculated during layout Message-ID: <5225DFFB.5000601@oracle.com> Hi, related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31006 I propose to add constant "public static final double USE_COMPUTED_BASELINE_OFFSET" to Node class. This would be returned by the default Node implementation of getBaselineOffset. Currently, the layout bounds are returned, but they are not computed at the time getBaselineOffset is called, which leads to incorrect layout and other problems (see more in description of the issue). Thanks, -Martin From hang.vo at oracle.com Tue Sep 3 06:32:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 13:32:22 +0000 Subject: hg: openjfx/8/controls/rt: RT-32551: don't consider origin of already found font sub-properties when getting the other font sub-properties Message-ID: <20130903133241.39EC4624C7@hg.openjdk.java.net> Changeset: a0ec3cc8567c Author: David Grieve Date: 2013-09-03 09:15 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a0ec3cc8567c RT-32551: don't consider origin of already found font sub-properties when getting the other font sub-properties ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/test/java/com/sun/javafx/css/FontTypeTest.java ! modules/graphics/src/test/resources/com/sun/javafx/css/HonorDeveloperSettingsTest_AUTHOR.css From neugens at redhat.com Tue Sep 3 07:38:02 2013 From: neugens at redhat.com (Mario Torre) Date: Tue, 03 Sep 2013 16:38:02 +0200 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> Message-ID: <1378219082.28083.28.camel@galactica.localdomain> On Tue, 2013-09-03 at 08:34 +0200, Fabrizio Giudici wrote: > On Tue, 03 Sep 2013 07:16:06 +0200, Tom Eugelink wrote: > > > AFAIK there was never a framework that used final a lot, so time will > > tell if the choice was right. Swing and the JDK made it this far. But > > The NetBeans Platform API does use final a lot for the same rationale > we're discussing now. > > > I'm suspecting the choice may have been made motivated more from the > > perspective of the developers of the framework (a few people) and not as > > much from the users (many people). > > That's true, but you're misusing the perspective. Many users would only > see some minor impact of extending a class, while the few developers would > see the accumulation of a huge number of problems because those minor > things are multiplied by the large number of users. It's precisely by > putting oneself in the perspective of the developers that 'final' makes > sense. I've designed quite a few APIs and have extended Swing in a number of very creative ways over the years. While the extensibility comes handy after the 10+ years old API doesn't do anymore the things you would like, you quickly realise it's really part of the problems in the first place, so I agree completely with Fabrizio here. Cheers, Mario From pedro.duquevieira at gmail.com Tue Sep 3 07:47:20 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 3 Sep 2013 15:47:20 +0100 Subject: DateAxis.. In-Reply-To: References: Message-ID: Hi Diego and Christian, Perhaps the opposite would be better since I'm doing a different approach (subclassing ValueAxis) and my DateAxis is already working. Thanks, best regards, On Mon, Sep 2, 2013 at 9:21 AM, Diego Cirujano-Cuesta < diego.cirujano-cuesta at zeiss.com> wrote: > Hi Pedro, > > Christian Schudt and me are working in a DateAxis that he create , we are > using Christian repo (this url): https://bitbucket.org/sco0ter/extfx/srcand > then: src/main/java/extfx/scene/chart/DateAxis.java that extends from > "Axis". We just have a few problems not important as a consecuence of > the layoutChildren performance improvements that are not good for a > DateAxis implementation :). > > Just now we are fixing this issue so you are wellcome to contribute into > it and problably you could have new ideas. It might make sence to move it > to ControlsFX or JFXtras and have a common solution. > > Cheers, > > Diego > > > > From: openjfx-dev-request at openjdk.java.net > To: openjfx-dev at openjdk.java.net > Date: 02.09.2013 08:18 > Subject: openjfx-dev Digest, Vol 22, Issue 2 > Sent by: openjfx-dev-bounces at openjdk.java.net > ------------------------------ > > > > Send openjfx-dev mailing list submissions to > openjfx-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev > or, via email, send a message with subject or body 'help' to > openjfx-dev-request at openjdk.java.net > > You can reach the person managing the list at > openjfx-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openjfx-dev digest..." > > > Today's Topics: > > 1. Re: FocusModel too restricted? (Jonathan Giles) > 2. Why is almost everything in the API final (Pedro Duque Vieira) > 3. DateAxis.. (Pedro Duque Vieira) > 4. Creating custom chart - "XYBarChart" (Pedro Duque Vieira) > 5. Re: Why is almost everything in the API final (Jonathan Giles) > 6. Re: DateAxis.. (Jonathan Giles) > 7. hg: openjfx/8/controls/rt: 4 new changesets (hang.vo at oracle.com) > 8. Re: DateAxis.. (Sven Reimers) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 02 Sep 2013 08:44:44 +1200 > From: Jonathan Giles > Subject: Re: FocusModel too restricted? > To: openjfx-dev at openjdk.java.net > Message-ID: <5223A73C.2030506 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Werner, > > It sounds to me like you're trying to use FocusModel where it may not > ideally suit your needs, and rather than roll your own API that is more > applicable to your needs, you're hoping to coerce FocusModel to fit to > be consistent. Whilst I applaud your eagerness to have an API consistent > with the 'official' UI controls, my gut feeling is that this will most > probably not be the best approach. The FocusModel API was really > designed for row-based UI controls like ListView, TableView, etc, and it > may be hard to work into your property sheet component. For this reason > I would suggest rolling your own API (and possibly questioning whether a > switchable FocusModel is actually necessary for your control in the > first place, or whether you can just bake the API directly into the > property sheet). > > Note that in this case the term 'focus' is overloaded, as this refers to > the internal 'fake' focus inside these controls - it has nothing to do > with 'real' JavaFX focus traversal. In other words, a ListView always > has the real focus, even if the ListView FocusModel says that row 1 is > focused - this is just for keyboard navigation purposes. For this reason > I'm curious if the FocusModel is what you actually want - I would assume > that what you are really wanting to do is move the real focus between > components in your control? Because of this you'll likely be rewriting > all of the FocusModel implementation anyway. > > To somewhat answer your questions: > 1) In general TreeView and TreeTableView have to jump through hoops, as > to reuse as much internal implementation code they essentially are > treated as if they are lists internally. In actual fact the focusNext / > focusPrevious methods almost weren't even added to the original API - > they were only added because I thought they were quite useful. For a > very long time we were going to be index-only. > > 2) When designing the FocusModel we were conscious of not providing the > same API with different names, so we settled on having a focus(int) > method and making the focusedIndex property read-only. This meant that > it was not possible for developers to accidentally bind the focus and > break the control. As always API design is a game of trade-offs, many of > which come back to bite you when you encounter new use cases in the > future :-) > > At this stage it would be essentially impossible to redo the FocusModel > to remove the index-based addressing, as it would be a breaking change. > It is more possible that more methods could be made public / non-final / > not read-only, but they will need to be handled on a case-by-case basis > and the first step is to file Jira tweak requests. > > I hope that helps a little... > > -- Jonathan > > On 2/09/2013 12:25 a.m., Werner Lehmann wrote: > > Hi, > > > > I am trying to use FocusModel in a custom property sheet component - > > it is probably a good idea to reuse as much API as possible and make > > components work similar to each other. However, the focus model makes > > this more difficult than it should be: > > > > 1. Why is it index-based? With methods like focusNext and > > focusPrevious it should not really require an ordered, index-based > > list. The TreeView focus model shows how this requires non-trivial > > extra effort if the data model is not similar to a plain list. > > > > 2. Why is setFocusedItem package private and final? With this I cannot > > even provide a new method "focus(item)" because I cannot call > > setFocusedItem internally. My users would have to translate their item > > into an index to be able to focus it. The TableViewFocusModel seems to > > have the same problem - but it is in the same package and can simply > > cheat on package private methods! > > > > To make this still work I'd have to provide index-based access to a > > tree-like data model. And to allow operations like focus(item) I'd > > have to translate the item to an index to call focus(index) instead - > > although I don't even need that index, and providing it is extra effort. > > > > Does it make sense to lift some of these restrictions? > > - no index-based requirement > > - less final/package-private methods > > > > Similar things can be said about the selection model... > > > > Werner > > > > ------------------------------ > > Message: 2 > Date: Mon, 2 Sep 2013 00:55:01 +0100 > > From: Pedro Duque Vieira > Subject: Why is almost everything in the API final > > To: OpenJFX Mailing List > Message-ID: > 6gw+ELas9Mw-0hQ at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > Why is almost everything in the API final? OK, I understand there is a > security problem and not making things final could potential open security > holes. > What I'm puzzled about is that the rest of the JDK doesn't use this pattern > and so I wonder if it is still effective this way? > I'm asking this because the penalties are significant, since you can not > easily extend the API because you can't subclass most framework classes. > > > Thanks, best regards, > > -- > Pedro Duque Vieira > > > ------------------------------ > > Message: 3 > Date: Mon, 2 Sep 2013 01:01:54 +0100 > > From: Pedro Duque Vieira > Subject: DateAxis.. > To: OpenJFX Mailing List > Message-ID: > < > CAAEud6Y5Cvk0PSCER46czsf9kDXjHoik4BGXLk0MQHBfmBNa0Q at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > Hi, > > I've created a DateAxis. Basically it extends from ValueAxis and you can > pass it dates in the Long format (converting Date to Long and passing in > that value). > > I wonder if this is valuable for the framework (I do see people asking for > this) and if so would you like me to submit it for your evaluation and > perhaps addition to the framework. > Sorry, I'm kind of new to submitting patches... > > Thanks, best regards, > > -- > Pedro Duque Vieira > > > ------------------------------ > > Message: 4 > Date: Mon, 2 Sep 2013 01:09:35 +0100 > > From: Pedro Duque Vieira > Subject: Creating custom chart - "XYBarChart" > > To: OpenJFX Mailing List > Message-ID: > NHq61+AaEjDGVjC-b_OruYdH0U6+ZumLKO5h4k5Sqw at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > Sorry for sending in several emails to the mailing list at once. > > I'm having some issues while creating a custom chart - a XYBarChart, which > is a BarChart that can have both axis as ValueAxis. > > The main issue I'm having is that there are a lot of fields and methods > which are "package private" and I need to access them. > I see there is already another person in this mailing list that is also > having trouble extending some other part of the framework because of > "package private" fields/methods. > > Maybe there should be more inclination towards making things protected > rather than "package private". I can see the problem that this could > potentially flood the javadocs with methods and fields but I think that not > being able to extend some framework class is worse. > > > Thanks, best regards, > > > -- > Pedro Duque Vieira > > > ------------------------------ > > Message: 5 > Date: Mon, 02 Sep 2013 12:23:27 +1200 > From: Jonathan Giles > Subject: Re: Why is almost everything in the API final > To: openjfx-dev at openjdk.java.net > Message-ID: <5223DA7F.5020609 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Richard will answer this far more effectively than me, but because he is > midway through a long weekend I'll give a quick summary based on my > recollection. > > The big issue is that with properties there are effectively two ways to > set or get values: you can of course call the getter or setter, or you > can do something like textProperty().get() / textProperty().set(..). Our > property implementation is essentially that the getter and setter > methods should do nothing more than defer to the property getters / > setters. Putting any logic into the getter / setter methods is actually > quite dangerous, as it can be easily avoided. For example, if > setText(...) were to do a whole range of calculations, these would never > be called if the end-user of the API were to call > textProperty().set(...) (or if the textProperty was bound to another > property). > > Therefore, in providing getter / setter methods, we are simply providing > convenience API to end developers. If the end developer goes on to > override these methods in subclasses, only trouble can really come from > this: they will add in additional logic that may only be called in some > circumstances (and definitely never when the properties are used with > bindings). > > There may be other concerns, but this is the primary issue that I can > recollect. If your intention is to subclass classes whose getters / > setters are final, you will need to change your approach to instead > listen to these properties from your subclass and react accordingly. > > -- Jonathan > > On 2/09/2013 11:55 a.m., Pedro Duque Vieira wrote: > > Hi, > > > > Why is almost everything in the API final? OK, I understand there is a > > security problem and not making things final could potential open > security > > holes. > > What I'm puzzled about is that the rest of the JDK doesn't use this > pattern > > and so I wonder if it is still effective this way? > > I'm asking this because the penalties are significant, since you can not > > easily extend the API because you can't subclass most framework classes. > > > > Thanks, best regards, > > > > > > ------------------------------ > > Message: 6 > Date: Mon, 02 Sep 2013 12:24:04 +1200 > From: Jonathan Giles > Subject: Re: DateAxis.. > To: openjfx-dev at openjdk.java.net > Message-ID: <5223DAA4.3040709 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1 > > My experience has been that there have been many people wanting > different kinds of axes (to be clear, the plural spelling of axis, > JavaFX isn't going medieval), the most popular being date and > logarithmic. If you've developed a DateAxis implementation, that is > great! I would recommend searching the jira for such as issue (I can't > see one in a quick search), and if one doesn't exist file a tweak / > feature request for it. You can attach your patch in the issue by > copy/pasting the code, or if it is long you can email the issue owner > (which will be Paru Somashekar) or myself, and we can attach the patch > to the issue on your behalf. > > Concurrently with this, there is a need for you to agree to the Oracle > Contributor Agreement if you haven't already. You can find more > information out here: http://openjdk.java.net/contribute/ > > The train has well and truly left for JavaFX 8.0, but this could be > considered for a release following that. In the mean time, you might be > interested in publishing the code yourself, either on your blog or into > an open source project such as JFXtras. This is often a great way to > evolve the API whilst it still can be. > > Thanks, > > -- Jonathan > > > On 2/09/2013 12:01 p.m., Pedro Duque Vieira wrote: > > Hi, > > > > I've created a DateAxis. Basically it extends from ValueAxis and you can > > pass it dates in the Long format (converting Date to Long and passing in > > that value). > > > > I wonder if this is valuable for the framework (I do see people asking > for > > this) and if so would you like me to submit it for your evaluation and > > perhaps addition to the framework. > > Sorry, I'm kind of new to submitting patches... > > > > Thanks, best regards, > > > > > > ------------------------------ > > Message: 7 > Date: Mon, 02 Sep 2013 05:32:25 +0000 > From: hang.vo at oracle.com > Subject: hg: openjfx/8/controls/rt: 4 new changesets > To: openjfx-dev at openjdk.java.net > Message-ID: <20130902053429.3E55D62490 at hg.openjdk.java.net> > > Changeset: 3acaf13c190c > Author: jgiles > Date: 2013-09-02 12:54 +1200 > URL: > http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3acaf13c190c > > RT-32253: Uncaught exception in static initializer for Control prevents > creation of all controls > > ! > modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java > > Changeset: 2e11c8f35ee5 > Author: jgiles > Date: 2013-09-02 13:16 +1200 > URL: > http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2e11c8f35ee5 > > RT-31104: TableView makes multiple selection drags difficult > > ! > modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java > ! > modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java > ! > modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java > > Changeset: bd2c6e6b661a > Author: jgiles > Date: 2013-09-02 13:33 +1200 > URL: > http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bd2c6e6b661a > > RT-32620: CheckBox cell factory in tree view unselects every cell > > ! modules/controls/src/main/java/javafx/scene/control/TreeItem.java > > Changeset: e60e9a5396e6 > Author: jgiles > Date: 2013-09-02 17:18 +1200 > URL: > http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e60e9a5396e6 > > RT-29885: Regression: issue with ComboBox focusedProperty > > ! > modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java > ! > modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java > ! modules/controls/src/main/java/javafx/scene/control/ComboBox.java > ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java > > > > ------------------------------ > > Message: 8 > Date: Mon, 2 Sep 2013 08:06:24 +0200 > From: Sven Reimers > Subject: Re: DateAxis.. > To: "jonathan.giles at oracle.com" > Cc: openjfx mailing list > Message-ID: > < > CAP+Jvx60QSnFQXe79MgZLOVtmWsCdYvUSbQAKkjN7qoQWNgnFA at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > Is there a place in ControlsFX for chart stuff as well? > How about creating a ChartFX stuff if not? > > -Sven > > > On Mon, Sep 2, 2013 at 2:24 AM, Jonathan Giles >wrote: > > > My experience has been that there have been many people wanting > > different kinds of axes (to be clear, the plural spelling of axis, > > JavaFX isn't going medieval), the most popular being date and > > logarithmic. If you've developed a DateAxis implementation, that is > > great! I would recommend searching the jira for such as issue (I can't > > see one in a quick search), and if one doesn't exist file a tweak / > > feature request for it. You can attach your patch in the issue by > > copy/pasting the code, or if it is long you can email the issue owner > > (which will be Paru Somashekar) or myself, and we can attach the patch > > to the issue on your behalf. > > > > Concurrently with this, there is a need for you to agree to the Oracle > > Contributor Agreement if you haven't already. You can find more > > information out here: http://openjdk.java.net/contribute/ > > > > The train has well and truly left for JavaFX 8.0, but this could be > > considered for a release following that. In the mean time, you might be > > interested in publishing the code yourself, either on your blog or into > > an open source project such as JFXtras. This is often a great way to > > evolve the API whilst it still can be. > > > > Thanks, > > > > -- Jonathan > > > > > On 2/09/2013 12:01 p.m., Pedro Duque Vieira wrote: > > > Hi, > > > > > > I've created a DateAxis. Basically it extends from ValueAxis and you > can > > > pass it dates in the Long format (converting Date to Long and passing > in > > > that value). > > > > > > I wonder if this is valuable for the framework (I do see people asking > > for > > > this) and if so would you like me to submit it for your evaluation and > > > perhaps addition to the framework. > > > Sorry, I'm kind of new to submitting patches... > > > > > > Thanks, best regards, > > > > > > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > > > End of openjfx-dev Digest, Vol 22, Issue 2 > ****************************************** > > > > ---------------------------------------- > This message is intended for a particular addressee only and may contain > business or company secrets. If you have received this email in error, > please contact the sender and delete the message immediately. Any use of > this email, including saving, publishing, copying, replication or > forwarding of the message or the contents is not permitted. > > -- Pedro Duque Vieira From hang.vo at oracle.com Tue Sep 3 08:02:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 15:02:35 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130903150332.0D79F624CC@hg.openjdk.java.net> Changeset: f2ea75d88413 Author: hudson Date: 2013-08-29 08:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f2ea75d88413 Added tag 8.0-b105 for changeset 903908477a58 ! .hgtags Changeset: 93f3f06641e8 Author: mv157916 Date: 2013-08-29 14:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/93f3f06641e8 RT-32599: Update the JDK build number to b105 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 20c49dd998fd Author: David Grieve Date: 2013-09-03 10:54 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/20c49dd998fd Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Tue Sep 3 08:02:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 15:02:35 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32656: [SwingNode]: correct the code sample with respect to thread safety Message-ID: <20130903150315.DDA6A624CB@hg.openjdk.java.net> Changeset: b84125298242 Author: ant Date: 2013-09-03 18:55 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b84125298242 RT-32656: [SwingNode]: correct the code sample with respect to thread safety Reviewed-by: art, pchelko ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java From hang.vo at oracle.com Tue Sep 3 08:17:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 15:17:11 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26949: Mac: 8.0-b67: SW pipeline is broken on MacOS Message-ID: <20130903151727.81C77624CD@hg.openjdk.java.net> Changeset: ec2f564fb7a1 Author: Petr Pchelko Date: 2013-09-03 19:05 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ec2f564fb7a1 RT-26949: Mac: 8.0-b67: SW pipeline is broken on MacOS Reviewed-by: art, snorthov, ddhill ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewScene.java ! modules/graphics/src/main/java/com/sun/prism/GraphicsPipeline.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPipeline.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWPipeline.java ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m From cognitionmission at gmail.com Tue Sep 3 08:19:12 2013 From: cognitionmission at gmail.com (David Ray) Date: Tue, 3 Sep 2013 10:19:12 -0500 Subject: Why is almost everything in the API final In-Reply-To: <1378219082.28083.28.camel@galactica.localdomain> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> Message-ID: <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> Final methods more so take the control out of the hands of the many developers, and places it in the hands of the API designers. If there is an issue, and demands are high - would we rather A. Report the issue and wait for the original API designer's development process to acknowledge, repair, and release a fix? -or- B. Report the issue to begin the above process, and improvise a workable workaround that let's a developer continue on with their work? I too observed the advantages of being able to do this in SWING countless times? Just a thought? David On Sep 3, 2013, at 9:38 AM, Mario Torre wrote: > On Tue, 2013-09-03 at 08:34 +0200, Fabrizio Giudici wrote: >> On Tue, 03 Sep 2013 07:16:06 +0200, Tom Eugelink wrote: >> >>> AFAIK there was never a framework that used final a lot, so time will >>> tell if the choice was right. Swing and the JDK made it this far. But >> >> The NetBeans Platform API does use final a lot for the same rationale >> we're discussing now. >> >>> I'm suspecting the choice may have been made motivated more from the >>> perspective of the developers of the framework (a few people) and not as >>> much from the users (many people). >> >> That's true, but you're misusing the perspective. Many users would only >> see some minor impact of extending a class, while the few developers would >> see the accumulation of a huge number of problems because those minor >> things are multiplied by the large number of users. It's precisely by >> putting oneself in the perspective of the developers that 'final' makes >> sense. > > I've designed quite a few APIs and have extended Swing in a number of > very creative ways over the years. While the extensibility comes handy > after the 10+ years old API doesn't do anymore the things you would > like, you quickly realise it's really part of the problems in the first > place, so I agree completely with Fabrizio here. > > Cheers, > Mario > > From neugens at redhat.com Tue Sep 3 08:26:52 2013 From: neugens at redhat.com (Mario Torre) Date: Tue, 03 Sep 2013 17:26:52 +0200 Subject: Why is almost everything in the API final In-Reply-To: <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> Message-ID: <1378222012.28083.35.camel@galactica.localdomain> On Tue, 2013-09-03 at 10:19 -0500, David Ray wrote: > Final methods more so take the control out of the hands of the many developers, and places it in the hands of the API designers. > If there is an issue, and demands are high - would we rather > > A. Report the issue and wait for the original API designer's development process to acknowledge, repair, and release a fix? > > -or- > > B. Report the issue to begin the above process, and improvise a workable workaround that let's a developer continue on with their work? > > I too observed the advantages of being able to do this in SWING countless times? > > Just a thought? > In this case, since JavaFX is Free Software! you can actually suggest the fix, prototype and propose the patch yourself, limiting the round trip time substantially. This also increases the chances to get a better fix in the end, since more eyes are focusing on it. Cheers, Mario From richard.bair at oracle.com Tue Sep 3 08:49:10 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 08:49:10 -0700 Subject: Why is almost everything in the API final In-Reply-To: <1378222012.28083.35.camel@galactica.localdomain> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> Message-ID: <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> >> Final methods more so take the control out of the hands of the many developers, and places it in the hands of the API designers. >> If there is an issue, and demands are high - would we rather >> >> A. Report the issue and wait for the original API designer's development process to acknowledge, repair, and release a fix? >> >> -or- >> >> B. Report the issue to begin the above process, and improvise a workable workaround that let's a developer continue on with their work? >> >> I too observed the advantages of being able to do this in SWING countless times? >> >> Just a thought? >> > > In this case, since JavaFX is Free Software! you can actually suggest > the fix, prototype and propose the patch yourself, limiting the round > trip time substantially. > > This also increases the chances to get a better fix in the end, since > more eyes are focusing on it. Or, when co-bundling the JRE with your app, you can provide whatever workaround you need to your copy of the JRE (just remove final from a few places or whatnot). Of course the cost comes when you need to upgrade to a newer version of FX, but if you gotta resort to one evil or another for the sake of shipping, this one at least leaves you in control. Richard From richard.bair at oracle.com Tue Sep 3 08:56:12 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 08:56:12 -0700 Subject: [API Review] : Baseline offset depends on layout bounds which are calculated during layout In-Reply-To: <5225DFFB.5000601@oracle.com> References: <5225DFFB.5000601@oracle.com> Message-ID: <1A52967E-6C24-4CD6-BB1C-AC2382838402@oracle.com> So how does the layout container ask for the computed baseline offset? It used to be, by calling this method. Richard On Sep 3, 2013, at 6:11 AM, Martin Sladecek wrote: > Hi, > related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31006 > > I propose to add constant "public static final double USE_COMPUTED_BASELINE_OFFSET" to Node class. > > This would be returned by the default Node implementation of getBaselineOffset. Currently, the layout bounds are returned, but they are not computed at the time getBaselineOffset is called, which leads to incorrect layout and other problems (see more in description of the issue). > > Thanks, > -Martin From hang.vo at oracle.com Tue Sep 3 09:47:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 16:47:34 +0000 Subject: hg: openjfx/8/controls/rt: fix NPE in CssStyleHelper found while running Shapes3DSceneLightTester Message-ID: <20130903164821.50687624D0@hg.openjdk.java.net> Changeset: ec82a5c0079b Author: David Grieve Date: 2013-09-03 12:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ec82a5c0079b fix NPE in CssStyleHelper found while running Shapes3DSceneLightTester ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java From Fabrizio.Giudici at tidalwave.it Tue Sep 3 10:34:26 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Tue, 03 Sep 2013 19:34:26 +0200 Subject: Why is almost everything in the API final In-Reply-To: <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> Message-ID: On Tue, 03 Sep 2013 17:49:10 +0200, Richard Bair wrote: > Or, when co-bundling the JRE with your app, you can provide whatever > workaround you need to your copy of the JRE (just remove final from a > few places or whatnot). Of course the cost comes when you need to > upgrade to a newer version of FX, but if you gotta resort to one evil or > another for the sake of shipping, this one at least leaves you in > control. I add that since it has been said that, unlike Spring, JavaFX 2 is more designed for composition in place of inheritance, let's rather focus on verifying that there's a good design in this sense and eventually ask for a better one when needed. I mean, rather than subclassing, perhaps that quick fix can be done by composition? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From hang.vo at oracle.com Tue Sep 3 10:17:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 17:17:44 +0000 Subject: hg: openjfx/8/graphics/rt: 33 new changesets Message-ID: <20130903172616.AD26E624D2@hg.openjdk.java.net> Changeset: f2ea75d88413 Author: hudson Date: 2013-08-29 08:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f2ea75d88413 Added tag 8.0-b105 for changeset 903908477a58 ! .hgtags Changeset: 93f3f06641e8 Author: mv157916 Date: 2013-08-29 14:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/93f3f06641e8 RT-32599: Update the JDK build number to b105 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 2285e786059a Author: leifs Date: 2013-08-27 10:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2285e786059a RT-32492 + RT-32493 DatePicker: Add shortcuts for switching months/years directly when the calendar is open ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerContent.java Changeset: 7f98f57fecd2 Author: David Grieve Date: 2013-08-28 07:36 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7f98f57fecd2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 3db94ad212b6 Author: jgiles Date: 2013-08-28 16:35 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3db94ad212b6 RT-29885: Regression: issue with ComboBox focusedProperty I've fixed this for both ComboBox and DatePicker, which is built on top of the same ComboBox base code and so had the same problem. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/java/javafx/scene/control/ComboBoxBase.java Changeset: bf88b13087fd Author: jgiles Date: 2013-08-29 09:34 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bf88b13087fd Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 2fd809b11dfd Author: psomashe Date: 2013-08-28 14:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2fd809b11dfd RT-30317 ChoiceBox failed to update the displayed text after calling setItems from Platfrom.runLater ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java + modules/controls/src/test/java/com/sun/javafx/scene/control/skin/ChoiceBoxSkinNodesRetriever.java ! modules/controls/src/test/java/javafx/scene/control/ChoiceBoxTest.java Changeset: 1d4565315819 Author: jgiles Date: 2013-08-29 15:43 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1d4565315819 RT-21444: SelectionModel.getSelectedItem() API does not work correctly in case when multiple selection is enabled and Shift key is down. Issue resolved in ListView, TreeView, TableView, and TreeTableView. Unit tests have been developed to prevent future regressions. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! modules/controls/src/test/java/javafx/scene/control/ListViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java Changeset: 9b8894841264 Author: jgiles Date: 2013-08-29 15:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9b8894841264 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: c52ac94b9d02 Author: leifs Date: 2013-08-29 12:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c52ac94b9d02 RT-24920: [CheckBox, RadioButton] Layout regression (was: Text Overrun incorrect work in CheckBox and RadioButton) ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: c661253e25cf Author: jgiles Date: 2013-08-30 13:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c661253e25cf RT-32559: TableView: replaced columns disappear ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: b2d31f6fb68d Author: jgiles Date: 2013-08-30 16:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b2d31f6fb68d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 0339d4004e85 Author: mickf Date: 2013-08-30 15:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0339d4004e85 RT-32327 : Threading issues with ProgressBar / ProgressIndicator after fix for RT-27791 ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 79af5cf2bf70 Author: mickf Date: 2013-08-30 15:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/79af5cf2bf70 RT-32584 : Indeterminate ProgressIndicator's spin property ignored for first play ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 16d1fc60bd6a Author: leifs Date: 2013-08-30 10:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/16d1fc60bd6a RT-2529: Locale specific runtime errors (Turkish) ! build.gradle ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/WebColorFieldSkin.java ! modules/fxml/src/main/java/com/sun/javafx/fxml/builder/TriangleMeshBuilder.java ! modules/graphics/src/main/java/com/sun/glass/ui/Platform.java ! modules/graphics/src/main/java/com/sun/glass/ui/PlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleLogger.java ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensLogger.java ! modules/graphics/src/main/java/com/sun/javafx/css/converters/EnumConverter.java ! modules/graphics/src/main/java/com/sun/javafx/css/converters/FontConverter.java ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/main/java/javafx/scene/Cursor.java ! modules/graphics/src/main/java/javafx/scene/input/KeyCombination.java ! modules/graphics/src/main/java/javafx/scene/paint/Color.java ! modules/graphics/src/test/java/com/sun/javafx/css/StylesheetTest.java ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubFontLoader.java Changeset: 98073a78b861 Author: leifs Date: 2013-08-30 11:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98073a78b861 RT-31857: DatePicker: "<" and ">" buttons for previous/next year are missing. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerContent.java Changeset: 089d0e8cb4d6 Author: leifs Date: 2013-08-30 14:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/089d0e8cb4d6 RT-31349: TextField, bidi text drifts when caret moves to bidi boundary. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 91a0d78259d2 Author: jgiles Date: 2013-08-31 08:07 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/91a0d78259d2 RT-32582: [ComboBox] unnecessary scroll bar in dropdown ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 9245ffbe8c4f Author: jgiles Date: 2013-08-31 12:18 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9245ffbe8c4f RT-32618: change listener on ListView is called one extra time. The same problem was also being exhibited on the other virtualised controls, so this changeset resolves it in all cases, and adds a parameterised test for both single and multiple selection models, to prevent this appearing again. ! modules/controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/MultipleSelectionModelImplTest.java ! modules/controls/src/test/java/javafx/scene/control/SelectionModelImplTest.java Changeset: a11427375c9b Author: jgiles Date: 2013-08-31 12:20 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a11427375c9b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 3acaf13c190c Author: jgiles Date: 2013-09-02 12:54 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3acaf13c190c RT-32253: Uncaught exception in static initializer for Control prevents creation of all controls ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java Changeset: 2e11c8f35ee5 Author: jgiles Date: 2013-09-02 13:16 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2e11c8f35ee5 RT-31104: TableView makes multiple selection drags difficult ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: bd2c6e6b661a Author: jgiles Date: 2013-09-02 13:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bd2c6e6b661a RT-32620: CheckBox cell factory in tree view unselects every cell ! modules/controls/src/main/java/javafx/scene/control/TreeItem.java Changeset: e60e9a5396e6 Author: jgiles Date: 2013-09-02 17:18 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e60e9a5396e6 RT-29885: Regression: issue with ComboBox focusedProperty ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/java/javafx/scene/control/ComboBox.java ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java Changeset: 18a02cf34ddf Author: mickf Date: 2013-09-02 13:14 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/18a02cf34ddf RT-32654 : ScrollPane - remove DOS line endings, no code changed ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 3f656fbd508f Author: mickf Date: 2013-09-02 13:44 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3f656fbd508f RT-31901 - Regression: scrollbar issue with TitledPane ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 74c06be0319b Author: jgiles Date: 2013-09-03 16:46 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/74c06be0319b RT-31093: Drag doesn't start from Date Picker text field The same problem existed for ComboBox, so it is now resolved in both places. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java Changeset: cb91a18c5738 Author: jgiles Date: 2013-09-03 17:08 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cb91a18c5738 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: e7d52acb03ee Author: mickf Date: 2013-09-03 13:45 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e7d52acb03ee RT-32676 - ProgressIndicator : possible null timeline if clipped, and then set invisible. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: a0ec3cc8567c Author: David Grieve Date: 2013-09-03 09:15 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a0ec3cc8567c RT-32551: don't consider origin of already found font sub-properties when getting the other font sub-properties ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/test/java/com/sun/javafx/css/FontTypeTest.java ! modules/graphics/src/test/resources/com/sun/javafx/css/HonorDeveloperSettingsTest_AUTHOR.css Changeset: 20c49dd998fd Author: David Grieve Date: 2013-09-03 10:54 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/20c49dd998fd Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: ec82a5c0079b Author: David Grieve Date: 2013-09-03 12:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ec82a5c0079b fix NPE in CssStyleHelper found while running Shapes3DSceneLightTester ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java Changeset: e0f3abebc024 Author: jgodinez Date: 2013-09-03 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e0f3abebc024 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! build.gradle - modules/graphics/src/main/java/com/sun/javafx/WeakReferenceMap.java - modules/graphics/src/test/java/com/sun/javafx/WeakReferenceMapTest.java From tbee at tbee.org Tue Sep 3 09:43:13 2013 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 03 Sep 2013 18:43:13 +0200 Subject: ServiceLoader In-Reply-To: <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> Message-ID: <522611A1.5070804@tbee.org> On 2013-09-03 17:49, Richard Bair wrote: >> In this case, since JavaFX is Free Software! you can actually suggest >> the fix, prototype and propose the patch yourself, limiting the round >> trip time substantially. >> That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java It does require a slightly extended Builder interface though. https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java A little blabla about this on this blog entry: http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ Tom From snfuchs at gmx.de Tue Sep 3 11:06:50 2013 From: snfuchs at gmx.de (Stefan Fuchs) Date: Tue, 03 Sep 2013 20:06:50 +0200 Subject: Why is almost everything in the API final In-Reply-To: <1378222012.28083.35.camel@galactica.localdomain> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> Message-ID: <5226253A.4030701@gmx.de> Mario Torre wrote: > In this case, since JavaFX is Free Software! you can actually suggest > the fix, prototype and propose the patch yourself, limiting the round > trip time substantially. > > This also increases the chances to get a better fix in the end, since > more eyes are focusing on it. > > Cheers, > Mario > > > ...and then wait a year or longer until the fix is delivered with the next major java release. Sorry, this is not really a viable option. Besides we still use webstart, so forking the jdk is not an option either. Wouldn't it be better to allow developers to override methods at their own risk. So, instead of making methods final, add a special annotation like @DoNotOverride to methods, which are not intended to be overridden by the designer of the framework. The compiler can emit warnings, if the developer decides to override the method anyway. This would clearly indicate to the developer, that his change is dangerous and he can not count on support from oracle, if his application breaks. Yet, those that are willing to take the risks, can do something to keep their business alive. Stefan From richard.bair at oracle.com Tue Sep 3 11:23:36 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 11:23:36 -0700 Subject: Why is almost everything in the API final In-Reply-To: <5226253A.4030701@gmx.de> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> Message-ID: > Wouldn't it be better to allow developers to override methods at their own risk. There's no such thing. When some big customer overrides methods, we have no choice but to support their app for the foreseeable future. Which is why deprecated stuff never could be removed from the JDK as well. And a host of bugs won't be fixed. When the CEO of a customer with a major hardware contract comes knocking -- well, at that time you really wish you had designed the API differently. > Yet, those that are willing to take the risks, can do something to keep their business alive. I would strongly recommend leaving the shared JRE install world behind. Richard From richard.bair at oracle.com Tue Sep 3 11:26:59 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 11:26:59 -0700 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> Message-ID: <882826A9-896C-4B40-A219-71206E505443@oracle.com> On Sep 3, 2013, at 11:23 AM, Richard Bair wrote: >> Wouldn't it be better to allow developers to override methods at their own risk. > > There's no such thing. When some big customer overrides methods, we have no choice but to support their app for the foreseeable future. Which is why deprecated stuff never could be removed from the JDK as well. And a host of bugs won't be fixed. When the CEO of a customer with a major hardware contract comes knocking -- well, at that time you really wish you had designed the API differently. (This is a danger we run with the impl_ methods as well, which is why this must be fixed in Lombard or we're going to get into trouble. This is also why we hide all com.sun APIs in JavaFX from the javac compiler in 8 and are closing up the gaps. It really all comes down the shared install, if there was no such thing, then we wouldn't have to be quite so uptight) From richard.bair at oracle.com Tue Sep 3 11:28:08 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 11:28:08 -0700 Subject: ServiceLoader In-Reply-To: <522611A1.5070804@tbee.org> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> <522611A1.5070804@tbee.org> Message-ID: <631A3551-BDBA-4D22-BD84-EC8D808AE708@oracle.com> The only knee-jerk reaction to the service loader is that it can be bad at startup, because for the service loader to work, it has to scan all jar files, which means downloading all jar files. Maybe with Jigsaw we'll have a better mechanism for this such that we can just read the first few bytes of a module and determine whether it supports a certain service or not. Richard On Sep 3, 2013, at 9:43 AM, Tom Eugelink wrote: > > On 2013-09-03 17:49, Richard Bair wrote: >>> In this case, since JavaFX is Free Software! you can actually suggest >>> the fix, prototype and propose the patch yourself, limiting the round >>> trip time substantially. >>> > > That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? > https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java > > It does require a slightly extended Builder interface though. > https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java > > A little blabla about this on this blog entry: > http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ > > Tom > From cognitionmission at gmail.com Tue Sep 3 11:28:33 2013 From: cognitionmission at gmail.com (David Ray) Date: Tue, 3 Sep 2013 13:28:33 -0500 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> Message-ID: <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> > I would strongly recommend leaving the shared JRE install world behind. As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems? David On Sep 3, 2013, at 1:23 PM, Richard Bair wrote: >> Wouldn't it be better to allow developers to override methods at their own risk. > > There's no such thing. When some big customer overrides methods, we have no choice but to support their app for the foreseeable future. Which is why deprecated stuff never could be removed from the JDK as well. And a host of bugs won't be fixed. When the CEO of a customer with a major hardware contract comes knocking -- well, at that time you really wish you had designed the API differently. > >> Yet, those that are willing to take the risks, can do something to keep their business alive. > > I would strongly recommend leaving the shared JRE install world behind. > > Richard From cognitionmission at gmail.com Tue Sep 3 11:31:53 2013 From: cognitionmission at gmail.com (David Ray) Date: Tue, 3 Sep 2013 13:31:53 -0500 Subject: Why is almost everything in the API final In-Reply-To: <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> Message-ID: <5C3DD04A-02D9-47B9-8390-A703E6191B6C@gmail.com> By "we" I meant the place where I work? (not JWrapper Inc.)! :) David On Sep 3, 2013, at 1:28 PM, David Ray wrote: >> I would strongly recommend leaving the shared JRE install world behind. > > As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems? > > David > > On Sep 3, 2013, at 1:23 PM, Richard Bair wrote: > >>> Wouldn't it be better to allow developers to override methods at their own risk. >> >> There's no such thing. When some big customer overrides methods, we have no choice but to support their app for the foreseeable future. Which is why deprecated stuff never could be removed from the JDK as well. And a host of bugs won't be fixed. When the CEO of a customer with a major hardware contract comes knocking -- well, at that time you really wish you had designed the API differently. >> >>> Yet, those that are willing to take the risks, can do something to keep their business alive. >> >> I would strongly recommend leaving the shared JRE install world behind. >> >> Richard > From richard.bair at oracle.com Tue Sep 3 11:34:32 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 11:34:32 -0700 Subject: Why is almost everything in the API final In-Reply-To: <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> Message-ID: >> I would strongly recommend leaving the shared JRE install world behind. > > As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems? If my business were betting on it, I'd not use a shared install for a couple reasons: - I want to control the *exact* version of the JRE such that my app testing was done against a specific version of the JRE - I have the freedom to modify the JRE as needed for my app - I can deploy as a normal desktop app using normal mechanisms - Related, I don't have to field support requests around what version of Java is installed or not, or Java install problems I can still have auto-update with an app cobundle, so I don't miss out there either. None of these points are suggesting the problem is with WebStart's implementation, they all hold even if WebStart were completely bug free. They're just the natural side-effect of a shared install system. Richard From tbee at tbee.org Tue Sep 3 11:44:23 2013 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 03 Sep 2013 20:44:23 +0200 Subject: ServiceLoader In-Reply-To: <631A3551-BDBA-4D22-BD84-EC8D808AE708@oracle.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> <522611A1.5070804@tbee.org> <631A3551-BDBA-4D22-BD84-EC8D808AE708@oracle.com> Message-ID: <52262E07.2090509@tbee.org> True, so we'll leave it JFXtras then. On 2013-09-03 20:28, Richard Bair wrote: > The only knee-jerk reaction to the service loader is that it can be bad at startup, because for the service loader to work, it has to scan all jar files, which means downloading all jar files. Maybe with Jigsaw we'll have a better mechanism for this such that we can just read the first few bytes of a module and determine whether it supports a certain service or not. > > Richard > > On Sep 3, 2013, at 9:43 AM, Tom Eugelink wrote: > >> On 2013-09-03 17:49, Richard Bair wrote: >>>> In this case, since JavaFX is Free Software! you can actually suggest >>>> the fix, prototype and propose the patch yourself, limiting the round >>>> trip time substantially. >>>> >> That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? >> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java >> >> It does require a slightly extended Builder interface though. >> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java >> >> A little blabla about this on this blog entry: >> http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ >> >> Tom >> From richard.bair at oracle.com Tue Sep 3 11:46:37 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 11:46:37 -0700 Subject: ServiceLoader In-Reply-To: <52262E07.2090509@tbee.org> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> <522611A1.5070804@tbee.org> <631A3551-BDBA-4D22-BD84-EC8D808AE708@oracle.com> <52262E07.2090509@tbee.org> Message-ID: <830FBB88-3016-40E8-A9C8-DDB86E800548@oracle.com> It is a real problem though (how to support 3rd party controls well). Is there a JIRA for this case? Richard On Sep 3, 2013, at 11:44 AM, Tom Eugelink wrote: > > True, so we'll leave it JFXtras then. > > > On 2013-09-03 20:28, Richard Bair wrote: >> The only knee-jerk reaction to the service loader is that it can be bad at startup, because for the service loader to work, it has to scan all jar files, which means downloading all jar files. Maybe with Jigsaw we'll have a better mechanism for this such that we can just read the first few bytes of a module and determine whether it supports a certain service or not. >> >> Richard >> >> On Sep 3, 2013, at 9:43 AM, Tom Eugelink wrote: >> >>> On 2013-09-03 17:49, Richard Bair wrote: >>>>> In this case, since JavaFX is Free Software! you can actually suggest >>>>> the fix, prototype and propose the patch yourself, limiting the round >>>>> trip time substantially. >>>>> >>> That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? >>> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java >>> >>> It does require a slightly extended Builder interface though. >>> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java >>> >>> A little blabla about this on this blog entry: >>> http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ >>> >>> Tom >>> > > From neugens.limasoftware at gmail.com Tue Sep 3 11:48:09 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 3 Sep 2013 20:48:09 +0200 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> Message-ID: But this puts the task to update the jre in the hands of the developer, no? This would be very insecure in my opinion then. Cheers, Mario Il giorno 03/set/2013 20:36, "Richard Bair" ha scritto: > >> I would strongly recommend leaving the shared JRE install world behind. > > > > As a suggestion, try JWrapper - we have flawless installs now, even > using an OSGI deployment procedure! Bundled JVMs are really the only > dependable way to go now it seems? > > If my business were betting on it, I'd not use a shared install for a > couple reasons: > - I want to control the *exact* version of the JRE such that my app > testing was done against a specific version of the JRE > - I have the freedom to modify the JRE as needed for my app > - I can deploy as a normal desktop app using normal mechanisms > - Related, I don't have to field support requests around what > version of Java is installed or not, or Java install problems > > I can still have auto-update with an app cobundle, so I don't miss out > there either. > > None of these points are suggesting the problem is with WebStart's > implementation, they all hold even if WebStart were completely bug free. > They're just the natural side-effect of a shared install system. > > Richard From tom.schindl at bestsolution.at Tue Sep 3 11:48:10 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 3 Sep 2013 20:48:10 +0200 Subject: Why is almost everything in the API final In-Reply-To: <882826A9-896C-4B40-A219-71206E505443@oracle.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <882826A9-896C-4B40-A219-71206E505443@oracle.com> Message-ID: Really is there not even a flag to make compiler do this? I don't get hit by this because i'm building with ejc but i'm accessing com.sun javafx classes quite frequently. Tom Von meinem iPhone gesendet Am 03.09.2013 um 20:26 schrieb Richard Bair : > > On Sep 3, 2013, at 11:23 AM, Richard Bair wrote: > >>> Wouldn't it be better to allow developers to override methods at their own risk. >> >> There's no such thing. When some big customer overrides methods, we have no choice but to support their app for the foreseeable future. Which is why deprecated stuff never could be removed from the JDK as well. And a host of bugs won't be fixed. When the CEO of a customer with a major hardware contract comes knocking -- well, at that time you really wish you had designed the API differently. > > (This is a danger we run with the impl_ methods as well, which is why this must be fixed in Lombard or we're going to get into trouble. This is also why we hide all com.sun APIs in JavaFX from the javac compiler in 8 and are closing up the gaps. It really all comes down the shared install, if there was no such thing, then we wouldn't have to be quite so uptight) > From richard.bair at oracle.com Tue Sep 3 11:49:47 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 11:49:47 -0700 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <882826A9-896C-4B40-A219-71206E505443@oracle.com> Message-ID: <3C2C5875-C9C6-4783-861A-82AFC8804B27@oracle.com> Yes you can use the -XDignore.symbol.file flag. On Sep 3, 2013, at 11:48 AM, Tom Schindl wrote: > Really is there not even a flag to make compiler do this? I don't get hit by this because i'm building with ejc but i'm accessing com.sun javafx classes quite frequently. > > Tom > > Von meinem iPhone gesendet > > Am 03.09.2013 um 20:26 schrieb Richard Bair : > >> >> On Sep 3, 2013, at 11:23 AM, Richard Bair wrote: >> >>>> Wouldn't it be better to allow developers to override methods at their own risk. >>> >>> There's no such thing. When some big customer overrides methods, we have no choice but to support their app for the foreseeable future. Which is why deprecated stuff never could be removed from the JDK as well. And a host of bugs won't be fixed. When the CEO of a customer with a major hardware contract comes knocking -- well, at that time you really wish you had designed the API differently. >> >> (This is a danger we run with the impl_ methods as well, which is why this must be fixed in Lombard or we're going to get into trouble. This is also why we hide all com.sun APIs in JavaFX from the javac compiler in 8 and are closing up the gaps. It really all comes down the shared install, if there was no such thing, then we wouldn't have to be quite so uptight) >> From richard.bair at oracle.com Tue Sep 3 11:53:53 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 11:53:53 -0700 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> Message-ID: <7E22B1F8-8A53-4B80-8F89-BAB73B23B8A8@oracle.com> The user has downloaded an app -- they have established and explicit trust relationship similar to any other native app by choosing to execute it. For apps distributed through the apple store (for desktop, the same as mobile) the update will happen via the store instead of directly over the air. For one-shot apps (the kind you find while browsing), this model doesn't work well (since I would be hesitant to run any random app I've downloaded off the internet -- but I don't have a problem running apps I download over the internet from a source I trust). Richard On Sep 3, 2013, at 11:48 AM, Mario Torre wrote: > But this puts the task to update the jre in the hands of the developer, no? This would be very insecure in my opinion then. > > Cheers, > Mario > > Il giorno 03/set/2013 20:36, "Richard Bair" ha scritto: > >> I would strongly recommend leaving the shared JRE install world behind. > > > > As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems? > > If my business were betting on it, I'd not use a shared install for a couple reasons: > - I want to control the *exact* version of the JRE such that my app testing was done against a specific version of the JRE > - I have the freedom to modify the JRE as needed for my app > - I can deploy as a normal desktop app using normal mechanisms > - Related, I don't have to field support requests around what version of Java is installed or not, or Java install problems > > I can still have auto-update with an app cobundle, so I don't miss out there either. > > None of these points are suggesting the problem is with WebStart's implementation, they all hold even if WebStart were completely bug free. They're just the natural side-effect of a shared install system. > > Richard From hang.vo at oracle.com Tue Sep 3 11:37:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 18:37:26 +0000 Subject: hg: openjfx/2u/dev/rt: RT-3252: Indeterminate progress bar causes memory leak Message-ID: <20130903183730.A50AD624D6@hg.openjdk.java.net> Changeset: 1d7c9e2e7ba5 Author: anashaty Date: 2013-09-03 20:38 +0400 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/1d7c9e2e7ba5 RT-3252: Indeterminate progress bar causes memory leak Reviewed-by: mickf,vkarnauk ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java From hang.vo at oracle.com Tue Sep 3 13:32:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 20:32:53 +0000 Subject: hg: openjfx/8/controls/rt: 57 new changesets Message-ID: <20130903204750.8D1F4624DE@hg.openjdk.java.net> Changeset: 6c72b0975d08 Author: rbair Date: 2013-08-27 14:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6c72b0975d08 Make getters final ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java Changeset: 259a333fe8c3 Author: Oleg Mazurov Date: 2013-08-27 17:20 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/259a333fe8c3 [TOOLS] port gltrace to Mac OS X ! tools/gltrace/Makefile ! tools/gltrace/egl.c ! tools/gltrace/enums.c ! tools/gltrace/gles.c ! tools/gltrace/iolib.c ! tools/gltrace/os.h ! tools/gltrace/retrace.c ! tools/gltrace/trace.h Changeset: 926292821d67 Author: Oleg Mazurov Date: 2013-08-27 17:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/926292821d67 [TOOLS] gltrace: new files + tools/gltrace/Makefile.linux + tools/gltrace/Makefile.macosx + tools/gltrace/egl.h + tools/gltrace/gles.h + tools/gltrace/os-macosx.c + tools/gltrace/trace-macosx.c Changeset: 767b6cf4c7a7 Author: rbair Date: 2013-08-27 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/767b6cf4c7a7 Updated some printlns for the benchmarks ! apps/performance/GraphicsPerformance/src/main/java/nodecount/BenchBase.java ! apps/performance/GraphicsPerformance/src/main/java/nodecount/BenchTest.java ! apps/performance/GraphicsPerformance/src/main/java/scrolling/ScrollingBenchBase.java Changeset: 1e32e7f401fe Author: rbair Date: 2013-08-27 17:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1e32e7f401fe Added PULSE_LOGGER output for number of times we go down the slow paths for rendering an NGRegion's background or shape ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 7218b4a0e399 Author: rbair Date: 2013-08-27 17:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7218b4a0e399 RT-32568: Redundant calls to GL Viewport ! modules/graphics/src/main/java/com/sun/prism/es2/GLContext.java Changeset: 11a3223d951e Author: rbair Date: 2013-08-27 17:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/11a3223d951e Typo fix in Ensemble ! apps/samples/Ensemble8/src/app/java/ensemble/HomePage.java ! apps/samples/Ensemble8/src/app/java/ensemble/PageBrowser.java Changeset: 1e133a8c7a60 Author: peterz Date: 2013-08-28 11:43 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1e133a8c7a60 Removed stray references to libxml2 from build.gradle ! build.gradle Changeset: fbab6330a073 Author: Vasiliy Baranov Date: 2013-08-28 12:27 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fbab6330a073 RT-21460: Unit test javafx.scene.web.IrresponsiveScriptTest hangs ! build.gradle + modules/web/src/main/java/com/sun/webkit/WatchdogTimer.java ! modules/web/src/main/native/Source/JavaScriptCore/TargetJava.pri ! modules/web/src/main/native/Source/JavaScriptCore/runtime/Watchdog.cpp ! modules/web/src/main/native/Source/JavaScriptCore/runtime/Watchdog.h + modules/web/src/main/native/Source/JavaScriptCore/runtime/WatchdogJava.cpp ! modules/web/src/main/native/Source/WebCore/mapfile-macosx ! modules/web/src/main/native/Source/WebCore/mapfile-vers ! modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp ! modules/web/src/test/java/javafx/scene/web/IrresponsiveScriptTest.java Changeset: fa2f68455df7 Author: snorthov Date: 2013-08-28 12:32 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fa2f68455df7 Add a prism properties to set glyph cache width and height Reviewed by Richard B ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java Changeset: 470b1208edc5 Author: snorthov Date: 2013-08-28 13:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/470b1208edc5 oops, remove bogus println() ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java Changeset: 5044e490ca48 Author: snorthov Date: 2013-08-28 13:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5044e490ca48 RT-27006: unread transferData field in FXCanvas [fix was to comment out the variable] ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java Changeset: 2e57da87f2fc Author: Chien Yang Date: 2013-08-28 10:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2e57da87f2fc Added a simple texCoord test program + apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMeshTexCoordTest.java Changeset: 0795d1f82705 Author: snorthov Date: 2013-08-28 13:42 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0795d1f82705 ECLIPSE: work around Eclipse jdk8 compiler problem ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java Changeset: bc3aed6f8860 Author: Chien Yang Date: 2013-08-28 13:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bc3aed6f8860 Minor adjustment to mesh size to improve code readability. ! apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMeshTexCoordTest.java Changeset: 90987ded4e33 Author: Felipe Heidrich Date: 2013-08-28 15:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/90987ded4e33 RT-32183: [TextFlow] Strange symbol and objects position with '\n'. ! modules/graphics/src/main/java/com/sun/javafx/text/GlyphLayout.java Changeset: e1d138d550e9 Author: Petr Pchelko Date: 2013-08-29 11:06 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e1d138d550e9 RT-27065 Win: [GlassRobot] GlassRobot can't press some keyboard buttons in one time Reviewed-by: anthony, art ! modules/graphics/src/main/native-glass/win/KeyTable.cpp ! modules/graphics/src/main/native-glass/win/KeyTable.h ! modules/graphics/src/main/native-glass/win/Robot.cpp Changeset: 02dab18d5824 Author: Alexander Zvegintsev Date: 2013-08-29 17:09 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/02dab18d5824 RT-31730 Gtk: Incorrect screen coordinates reporting ! modules/graphics/src/main/native-glass/gtk/GlassView.cpp ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp Changeset: f219f9bc5347 Author: Pavel Safrata Date: 2013-08-29 14:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f219f9bc5347 Graphics NetBeans project: fixed debugging tests. ! netbeans/graphics/build.xml Changeset: b4067344e883 Author: Pavel Safrata Date: 2013-08-29 14:40 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b4067344e883 RT-32455: removed obsolete WeakReferenceMap. - modules/graphics/src/main/java/com/sun/javafx/WeakReferenceMap.java - modules/graphics/src/test/java/com/sun/javafx/WeakReferenceMapTest.java Changeset: 40312b689a50 Author: snorthov Date: 2013-08-29 14:48 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/40312b689a50 RT-31367 [SWT] Custom data types cannot be transfered with DnD reviewed by anton ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java Changeset: 4cf6e02ce489 Author: rbair Date: 2013-08-29 14:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4cf6e02ce489 RT-32589: Add better diagnostic and debug tools for dirty regions, culling, and overdraw Reviewed-By: Steve Northover, Martin Sladecek Added a new dirty bit for debug information that needs to be sent down. Also completely changed the way we draw in ViewPainter, specifically when dirty regions are used and even more specifically when show dirty and show overdraw are turned on. Added some new prism settings for showing overdraw, and printing the render graph to the pulse logger. Also replaced the drawCullBits to instead draw overdraw boxes. You can get a better sense of cull bits by looking at the output of the render graph being printed to the pulse logger. ! modules/graphics/src/main/java/com/sun/javafx/scene/DirtyBits.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NodePath.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java ! modules/graphics/src/main/java/com/sun/prism/Graphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/OcclusionCullingTest.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/RenderRootTest.java Changeset: d7de1fc065a0 Author: rbair Date: 2013-08-29 14:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d7de1fc065a0 Added Hello app for showing overdraw. + apps/toys/Hello/src/main/java/hello/HelloOverdraw.java Changeset: 056f995f83e4 Author: rbair Date: 2013-08-29 16:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/056f995f83e4 Fixed bug I introduced where "reset" always set the pointer to -1, whereas the assumption before was that reset would put the pointer on the first item. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NodePath.java Changeset: 74bd12468ff2 Author: Pavel Safrata Date: 2013-08-30 08:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/74bd12468ff2 RT-31256: Added ZERO constants to Point2D and Point3D. ! modules/graphics/src/main/java/javafx/geometry/Point2D.java ! modules/graphics/src/main/java/javafx/geometry/Point3D.java Changeset: eb5c0efd242d Author: Artem Ananiev Date: 2013-08-30 13:56 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/eb5c0efd242d RT-32138: Win: Java crashes on Windows 2008 R2 with JavaFX Reviewed-by: Anthony Petrov, Petr Pchelko ! modules/graphics/src/main/native-glass/win/ViewContainer.cpp Changeset: 8b9ed2be92ac Author: Lisa Selle Date: 2013-08-30 12:22 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8b9ed2be92ac Fix for rt-32583 - major rendering artifacts on BouncingBalls on eglfb path. ! modules/graphics/src/main/java/com/sun/prism/es2/GLContext.java Changeset: bf594c19a7a6 Author: rbair Date: 2013-08-30 09:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bf594c19a7a6 Change BenchBase to use the iPad resolution, and also exit on completion. ! apps/performance/GraphicsPerformance/src/main/java/nodecount/BenchBase.java Changeset: aec474945f1c Author: rbair Date: 2013-08-30 10:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/aec474945f1c Removed println and added extra check for 0 width / height when drawing dirty regions (since the code in paintOverdraw is unhappy about such things, and you can't draw a rect with 0 width or height anyway). ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: 3e92a5d12221 Author: rbair Date: 2013-08-30 10:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3e92a5d12221 Fixed typo ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java Changeset: 85a00128048f Author: rbair Date: 2013-08-30 10:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/85a00128048f Clean up HelloRectangle ! apps/toys/Hello/src/main/java/hello/HelloRectangle.java Changeset: c6f13b9fd75d Author: rbair Date: 2013-08-30 10:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c6f13b9fd75d ViewPainter shouldn't be painting anything if the width or height is <= 0 ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: a2677d23fe0e Author: rbair Date: 2013-08-30 11:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a2677d23fe0e RT-32603: Bad analysis in NGGroup#computeRenderRoot results in Nodes being rendered that need not be ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGTestBase.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/OcclusionCullingTest.java Changeset: 0c83c172d42c Author: Yao Wang Date: 2013-08-30 12:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0c83c172d42c RT-31521 8.0-graphics-scrum-h1423: Memory leak in PhongMaterial ! modules/graphics/src/main/java/com/sun/javafx/geom/transform/Affine3D.java ! modules/graphics/src/main/java/javafx/scene/paint/PhongMaterial.java ! modules/graphics/src/main/java/javafx/scene/shape/MeshView.java ! modules/graphics/src/main/java/javafx/scene/shape/Shape3D.java Changeset: 49f80deda70a Author: rbair Date: 2013-08-30 14:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/49f80deda70a RT-32639: NGRegion can avoid invalidating the backgroundInsets if the Background in question does not have any percentage-based CornerRadii on any BackgroundFills ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/javafx/scene/layout/Background.java ! modules/graphics/src/test/java/javafx/scene/layout/BackgroundTest.java Changeset: 348b5b2c38ea Author: Chien Yang Date: 2013-08-30 16:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/348b5b2c38ea Fix to RT-30723: EGL: Disable clipping when clearing framebuffer Reviewed by Dave, Lisa and Kevin ! modules/graphics/src/main/java/com/sun/prism/es2/EGLFBGLDrawable.java Changeset: a8e13d82e298 Author: rbair Date: 2013-08-30 22:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a8e13d82e298 Minor comment fixes to NGRegion, also minor change to RegionImageCache to have the constructor take a ResourceFactory instead of a Graphics object (since the Graphics object was only used to get at its resource factory, and it is better style to pass what is really needed instead of a carrier). ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/RegionImageCache.java Changeset: e200bd15abc2 Author: rbair Date: 2013-08-30 22:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e200bd15abc2 RT-32646: Regions go down a very slow rendering path when width / height are not pixel aligned and image cache is used ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 6789dad991cb Author: rbair Date: 2013-08-30 22:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6789dad991cb Updated TODO in NGRegion -- we definitely don't support background loaded images as image fills for a Region. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 89fe014f6435 Author: Assaf Yavani Date: 2013-09-01 13:11 +0300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/89fe014f6435 [RT-32593] - fb: fb cannot load on the pi Problem - fx failed to load with java.lang.UnsatisfiedLinkError when trying to run FX on raspberry pi with fb Analysis - lens platofrm utils was not linked to the .so fix - update the gradle files to include the file in the link command Reviewed by : Daniel B. Patch - http://sthinfra10.se.oracle.com:8060/cru/CR-FX8GFX-309 Tested on device ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle Changeset: f0620fe44d8a Author: tb115823 Date: 2013-09-02 14:22 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f0620fe44d8a Android: Fix failing build. Use lens_wm_notifyMultiTouchEvent instead of lens_wm_notifyTouchEvent ! buildSrc/android.gradle ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c Changeset: ad37f3adc5df Author: Alexander Zvegintsev Date: 2013-09-02 17:37 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ad37f3adc5df RT-32565 Gtk: mouse grab issue with dialogs activated from mouse handler ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp Changeset: b3d0c8df51b6 Author: Oldrich Maticka Date: 2013-09-02 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b3d0c8df51b6 iOS: Ensemble8 - fixing check for iOS; removing ScrollEvent synthesis for iOS - not needed; we have native scroll events + momentum/inertia ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java Changeset: 42e1b2938f98 Author: Rafi Tayar Date: 2013-09-02 18:19 +0300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/42e1b2938f98 RT-32468 Lens: Touch keyboard is not reliable on Raspberry Pi ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c Changeset: 3c9ebc34f4b7 Author: Rafi Tayar Date: 2013-09-02 18:19 +0300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3c9ebc34f4b7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: b2c061caf644 Author: Daniel Blaukopf Date: 2013-09-03 08:55 +0300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b2c061caf644 RT-32600 Lens: Pulse starvation because of overwhelming amount of MOUSE_MOVED events ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java Changeset: 514d70fdc70c Author: tb115823 Date: 2013-09-03 09:47 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/514d70fdc70c Android: Fixed renamed prism property glDepthSize. Default value 24 doesn't work on GT10.1 must be 16. Although such eglconfig is available glCreateContext fails with BAD_EGL_CONFIG 3005 error. Don't know why, need to investigate. ! buildSrc/android.gradle Changeset: 655f1ead4bc8 Author: tb115823 Date: 2013-09-03 09:47 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/655f1ead4bc8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: d04fe4c584d4 Author: Lubomir Nerad Date: 2013-09-03 14:41 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d04fe4c584d4 Include debug info in native for debug build ! buildSrc/ios.gradle Changeset: f56e0d2cbfc7 Author: Martin Sladecek Date: 2013-09-03 12:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f56e0d2cbfc7 RT-32657 Teleportation of animated object during TranslateTransition ! modules/graphics/src/main/java/javafx/animation/Animation.java ! modules/graphics/src/test/java/javafx/animation/AnimationTest.java Changeset: 357f66506342 Author: Martin Sladecek Date: 2013-09-03 12:44 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/357f66506342 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt Changeset: 391542e56deb Author: Artem Ananiev Date: 2013-09-03 15:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/391542e56deb RT-29095: Dragging from Swing to JavaFX (JFXPanel) that was working in JavaFX 2.2 fails in JavaFX 8.0 Reviewed-by: Kevin Rushforth, Pavel ??afrata ! modules/graphics/src/main/java/com/sun/javafx/tk/TKDragGestureListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKDropTargetListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSceneDnDEventHandler.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/scene/input/DataFormat.java ! modules/graphics/src/main/java/javafx/scene/input/Dragboard.java Changeset: 5946bd72bbc0 Author: pchelko Date: 2013-09-03 16:13 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5946bd72bbc0 RT-32661: Regression Mac OS : some keycode accelerators are badly rendered Reviewed-by: art, Alexander Zvegintsev ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java ! modules/graphics/src/main/native-glass/mac/GlassKey.m Changeset: 94e96dbe02db Author: Petr Pchelko Date: 2013-09-03 16:21 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/94e96dbe02db RT-31873: [SwingNode] : Something throws NullPointerException Reviewed-by: ant, art ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java Changeset: b84125298242 Author: ant Date: 2013-09-03 18:55 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b84125298242 RT-32656: [SwingNode]: correct the code sample with respect to thread safety Reviewed-by: art, pchelko ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java Changeset: ec2f564fb7a1 Author: Petr Pchelko Date: 2013-09-03 19:05 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ec2f564fb7a1 RT-26949: Mac: 8.0-b67: SW pipeline is broken on MacOS Reviewed-by: art, snorthov, ddhill ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewScene.java ! modules/graphics/src/main/java/com/sun/prism/GraphicsPipeline.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPipeline.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWPipeline.java ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m Changeset: e0f3abebc024 Author: jgodinez Date: 2013-09-03 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e0f3abebc024 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! build.gradle - modules/graphics/src/main/java/com/sun/javafx/WeakReferenceMap.java - modules/graphics/src/test/java/com/sun/javafx/WeakReferenceMapTest.java From hang.vo at oracle.com Tue Sep 3 14:02:28 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 21:02:28 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed RT29844: Create PrinterJob hangs on Mac Message-ID: <20130903210300.665F3624E4@hg.openjdk.java.net> Changeset: 0a2518e15882 Author: prr Date: 2013-09-03 13:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0a2518e15882 Fixed RT29844: Create PrinterJob hangs on Mac ! modules/graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java From cognitionmission at gmail.com Tue Sep 3 14:08:54 2013 From: cognitionmission at gmail.com (David Ray) Date: Tue, 3 Sep 2013 16:08:54 -0500 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> Message-ID: <0BF18F5F-8061-4606-B191-289B9625B171@gmail.com> When you have a new version of your app to distribute, you would repackage it using the same tool you did before - maybe specifying a new JVM target (if you would like to update the JVM that gets bundled with the app). Then upload your app to the Apple App Store and voila' :) (Ok so there's the extra step of the endless slew of provisioning licensing and packaging hurdles introduced by Apple -- then voila' !!!) :-D David On Sep 3, 2013, at 1:48 PM, Mario Torre wrote: > But this puts the task to update the jre in the hands of the developer, no? This would be very insecure in my opinion then. > > Cheers, > Mario > > Il giorno 03/set/2013 20:36, "Richard Bair" ha scritto: > >> I would strongly recommend leaving the shared JRE install world behind. > > > > As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems? > > If my business were betting on it, I'd not use a shared install for a couple reasons: > - I want to control the *exact* version of the JRE such that my app testing was done against a specific version of the JRE > - I have the freedom to modify the JRE as needed for my app > - I can deploy as a normal desktop app using normal mechanisms > - Related, I don't have to field support requests around what version of Java is installed or not, or Java install problems > > I can still have auto-update with an app cobundle, so I don't miss out there either. > > None of these points are suggesting the problem is with WebStart's implementation, they all hold even if WebStart were completely bug free. They're just the natural side-effect of a shared install system. > > Richard From tbee at tbee.org Tue Sep 3 13:53:46 2013 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 03 Sep 2013 22:53:46 +0200 Subject: ServiceLoader In-Reply-To: <830FBB88-3016-40E8-A9C8-DDB86E800548@oracle.com> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> <522611A1.5070804@tbee.org> <631A3551-BDBA-4D22-BD84-EC8D808AE708@oracle.com> <52262E07.2090509@tbee.org> <830FBB88-3016-40E8-A9C8-DDB86E800548@oracle.com> Message-ID: <52264C5A.6030005@tbee.org> No, but there is a less-than-optimal-but-fast approach, and that is to write a custom BuilderFactory with if statements for all 3rd party controls. On 2013-09-03 20:46, Richard Bair wrote: > It is a real problem though (how to support 3rd party controls well). Is there a JIRA for this case? > > Richard > > On Sep 3, 2013, at 11:44 AM, Tom Eugelink wrote: > >> True, so we'll leave it JFXtras then. >> >> >> On 2013-09-03 20:28, Richard Bair wrote: >>> The only knee-jerk reaction to the service loader is that it can be bad at startup, because for the service loader to work, it has to scan all jar files, which means downloading all jar files. Maybe with Jigsaw we'll have a better mechanism for this such that we can just read the first few bytes of a module and determine whether it supports a certain service or not. >>> >>> Richard >>> >>> On Sep 3, 2013, at 9:43 AM, Tom Eugelink wrote: >>> >>>> On 2013-09-03 17:49, Richard Bair wrote: >>>>>> In this case, since JavaFX is Free Software! you can actually suggest >>>>>> the fix, prototype and propose the patch yourself, limiting the round >>>>>> trip time substantially. >>>>>> >>>> That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? >>>> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java >>>> >>>> It does require a slightly extended Builder interface though. >>>> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java >>>> >>>> A little blabla about this on this blog entry: >>>> http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ >>>> >>>> Tom >>>> >> From hang.vo at oracle.com Tue Sep 3 14:47:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 21:47:09 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-32571: Debug build failure. Reviewed by Kevin, Chien. Message-ID: <20130903214725.ECABA624EC@hg.openjdk.java.net> Changeset: 977346aedf74 Author: Thor Johannesson Date: 2013-09-03 14:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/977346aedf74 Fix RT-32571: Debug build failure. Reviewed by Kevin, Chien. ! modules/graphics/src/main/native-prism-d3d/D3DResourceManager.cc From tom.schindl at bestsolution.at Tue Sep 3 14:48:57 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 03 Sep 2013 23:48:57 +0200 Subject: ServiceLoader In-Reply-To: <52264C5A.6030005@tbee.org> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> <522611A1.5070804@tbee.org> <631A3551-BDBA-4D22-BD84-EC8D808AE708@oracle.com> <52262E07.2090509@tbee.org> <830FBB88-3016-40E8-A9C8-DDB86E800548@oracle.com> <52264C5A.6030005@tbee.org> Message-ID: <52265949.2080603@bestsolution.at> Well once we have a replacement for builders this is not needed anymore so I don't think there's a JIRA needed. When we discussed replacements for builders in context of FXML the consensus was to have annotations on the constructor to map the arguments appropriately. Eva suggested @ConstructorProperties, I was more in favor of explicit @FXMLValue annotation on each argument. Tom On 03.09.13 22:53, Tom Eugelink wrote: > > No, but there is a less-than-optimal-but-fast approach, and that is to > write a custom BuilderFactory with if statements for all 3rd party > controls. > > > > On 2013-09-03 20:46, Richard Bair wrote: >> It is a real problem though (how to support 3rd party controls well). >> Is there a JIRA for this case? >> >> Richard >> >> On Sep 3, 2013, at 11:44 AM, Tom Eugelink wrote: >> >>> True, so we'll leave it JFXtras then. >>> >>> >>> On 2013-09-03 20:28, Richard Bair wrote: >>>> The only knee-jerk reaction to the service loader is that it can be >>>> bad at startup, because for the service loader to work, it has to >>>> scan all jar files, which means downloading all jar files. Maybe >>>> with Jigsaw we'll have a better mechanism for this such that we can >>>> just read the first few bytes of a module and determine whether it >>>> supports a certain service or not. >>>> >>>> Richard >>>> >>>> On Sep 3, 2013, at 9:43 AM, Tom Eugelink wrote: >>>> >>>>> On 2013-09-03 17:49, Richard Bair wrote: >>>>>>> In this case, since JavaFX is Free Software! you can actually >>>>>>> suggest >>>>>>> the fix, prototype and propose the patch yourself, limiting the >>>>>>> round >>>>>>> trip time substantially. >>>>>>> >>>>> That said, in JFXtras I've created an extended FactoryBuilder that >>>>> dynamically loads builder classes using Java's standard >>>>> ServiceLoader approach. Would this be of interest for inclusion >>>>> directly into JavaFX? >>>>> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java >>>>> >>>>> >>>>> It does require a slightly extended Builder interface though. >>>>> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java >>>>> >>>>> >>>>> A little blabla about this on this blog entry: >>>>> http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ >>>>> >>>>> Tom >>>>> >>> > > From snfuchs at gmx.de Tue Sep 3 15:22:11 2013 From: snfuchs at gmx.de (Stefan Fuchs) Date: Wed, 04 Sep 2013 00:22:11 +0200 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> Message-ID: <52266113.5020607@gmx.de> Richard Bair wrote: >> Wouldn't it be better to allow developers to override methods at >> their own risk. > There's no such thing. When some big customer overrides methods, we > have no choice but to support their app for the foreseeable future. > Which is why deprecated stuff never could be removed from the JDK as > well. And a host of bugs won't be fixed. When the CEO of a customer > with a major hardware contract comes knocking -- well, at that time > you really wish you had designed the API differently. So I just must make a major hardware contract, when I want to have a final keyword removed Anyway... if its clearly documented in the API (by an annotation), that this method should not have been overwritten by the developers of CEO of a customer with a major hardware contract and they did it anyway there is a strong hint, whose fault it was. But I must admit, that it might not save you in cooperate politics. >> Yet, those that are willing to take the risks, can do something to >> keep their business alive. > I would strongly recommend leaving the shared JRE install world behind. > > Richard Well, one of the main reasons to invest in JavaFX, was the ability to start the application web-like. We develop a fotobook application for both business and consumer customers. (e.g.: available german only at http://www.lidl-druckservice.de/) In the past like most of our competitors we had 2 applications. One was a very limited web application (html, javascript, php), the other a complex. full featured application in C#. For our business it is critical to get customers to design their product as fast as possible. Many are unwilling or unable (e.g.: in a cooperate environment) to install software from semi-untrusted sources. JavaFx provided us the chance to develop an application from the same codebase, which - has full access to the filesystem (no lengthy picture uploads, before design can begin) - can be started similar to a web-application (via webstart) - can be installed as a native application - works on all major desktop platforms - in the future might run on tablets Note that we leave our customers the choice between the webstart application and the installer version. Webstart gets increasingly unreliable due to problems with browsers (e.g.: Firefox currently blocks webstart, because of unpatched security problems) and the jre (e.g.: last security update killed Swing - luckily we found a workaround (no final method was involved :-)) and the problem is hopefully fixed with Java 7 u40). If webstart is no longer a viable choice, we might have to reconsider our strategy and develop a html 5 application for the web and tablet use cases. Stefan From hang.vo at oracle.com Tue Sep 3 15:47:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 22:47:44 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32674: Win: Fatal JNI error in DirectWrite code Message-ID: <20130903224816.6521A624FB@hg.openjdk.java.net> Changeset: 55316c1ad394 Author: Felipe Heidrich Date: 2013-09-03 15:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/55316c1ad394 RT-32674: Win: Fatal JNI error in DirectWrite code ! modules/graphics/src/main/native-font/directwrite.cpp From hjohn at xs4all.nl Tue Sep 3 16:15:43 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 04 Sep 2013 01:15:43 +0200 Subject: Why is almost everything in the API final In-Reply-To: References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> Message-ID: <52266D9F.7010102@xs4all.nl> On 3/09/2013 20:34, Richard Bair wrote: >>> I would strongly recommend leaving the shared JRE install world behind. >> As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems? > If my business were betting on it, I'd not use a shared install for a couple reasons: > - I want to control the *exact* version of the JRE such that my app testing was done against a specific version of the JRE > - I have the freedom to modify the JRE as needed for my app > - I can deploy as a normal desktop app using normal mechanisms > - Related, I don't have to field support requests around what version of Java is installed or not, or Java install problems > > I can still have auto-update with an app cobundle, so I don't miss out there either. > > None of these points are suggesting the problem is with WebStart's implementation, they all hold even if WebStart were completely bug free. They're just the natural side-effect of a shared install system. Actually, one of the best things of Java is that in like 99.9% of the cases, my app will run flawlessly on whatever version of the JDK or JRE is installed... on multiple platforms. If Java goes down the road of requiring testing against a specific JRE (and thus specific platform by extension) then that is its biggest advantage lost. In fact, any framework that does not aspire to do the same (being backwards compatible to a flaw) is not a framework I'll consider for production use. I want to be able to upgrade, and at most run my unit tests to have the confidence that it will perform as expected. There can always be mistakes, both in the frameworks or in my code doing something that was undocumented or incorrectly interpreted, but in the end backwards compatibility is what makes or breaks a framework -- a big reason for that is that such frameworks are actually designed with some care, exactly because they aspire to be backward compatible... and a good API is everything. --John From richard.bair at oracle.com Tue Sep 3 16:31:24 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 3 Sep 2013 16:31:24 -0700 Subject: Why is almost everything in the API final In-Reply-To: <52266D9F.7010102@xs4all.nl> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <5226253A.4030701@gmx.de> <255C7753-3DBE-4658-977F-AB17A50ED10F@gmail.com> <52266D9F.7010102@xs4all.nl> Message-ID: <105C43F7-3E8B-458A-A059-6E38F0FCE670@oracle.com> >> None of these points are suggesting the problem is with WebStart's implementation, they all hold even if WebStart were completely bug free. They're just the natural side-effect of a shared install system. > Actually, one of the best things of Java is that in like 99.9% of the cases, my app will run flawlessly on whatever version of the JDK or JRE is installed... on multiple platforms. If Java goes down the road of requiring testing against a specific JRE (and thus specific platform by extension) then that is its biggest advantage lost. > > In fact, any framework that does not aspire to do the same (being backwards compatible to a flaw) is not a framework I'll consider for production use. I want to be able to upgrade, and at most run my unit tests to have the confidence that it will perform as expected. There can always be mistakes, both in the frameworks or in my code doing something that was undocumented or incorrectly interpreted, but in the end backwards compatibility is what makes or breaks a framework -- a big reason for that is that such frameworks are actually designed with some care, exactly because they aspire to be backward compatible... and a good API is everything. When you have 9 million developers and hundreds of millions of apps, any change we make breaks somebody. Every bug fix. Everything. For any one developer the chance of breakage may be less or greater (we get reports from some customers who spend 6 months fixing breaks between major releases and others from developers who've never experienced a break). Having seen the carnage, I myself would avoid using a shared install if possible. That is a separate issue from trying to maintain backwards compatibility. Having to rewrite a large chunk of your app to move from version N to N+1 is obviously not desirable, but having sat in this seat for a while now, I wouldn't personally risk running my app against any random release of *anybodies library*, if I could help it. Richard From hang.vo at oracle.com Tue Sep 3 16:32:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Sep 2013 23:32:11 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32698: Dirty region count is higher than it used to be by default Message-ID: <20130903233226.854F6624FF@hg.openjdk.java.net> Changeset: 57a0f2653086 Author: rbair Date: 2013-09-03 16:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/57a0f2653086 RT-32698: Dirty region count is higher than it used to be by default Reviewed By: Felipe ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java From hang.vo at oracle.com Tue Sep 3 21:17:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 04:17:47 +0000 Subject: hg: openjfx/8/controls/rt: 6 new changesets Message-ID: <20130904041938.2B3E962506@hg.openjdk.java.net> Changeset: 673a1107114b Author: jgiles Date: 2013-09-04 10:44 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/673a1107114b RT-32684: onEdit<> events are never fired in tree table ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableRowTest.java Changeset: 771594e0b347 Author: jgiles Date: 2013-09-04 13:06 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/771594e0b347 RT-32683: F2 cause editing to cancel in TreeView ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeTableCell.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 9dafb5c352f3 Author: jgiles Date: 2013-09-04 14:10 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9dafb5c352f3 RT-32621: ProgressBar cells are rendered after collapsing root ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java Changeset: 6c9898b47f64 Author: jgiles Date: 2013-09-04 14:11 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6c9898b47f64 [TEST ONLY] slightly improved test infrastructure for virtualFlow controls and mouse event firing. ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java Changeset: 9257caffde99 Author: jgiles Date: 2013-09-04 14:53 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9257caffde99 [TEST ONLY] Re-enabling test for RT-28556. ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java Changeset: e94c28bc5396 Author: jgiles Date: 2013-09-04 15:57 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e94c28bc5396 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From tbee at tbee.org Tue Sep 3 22:02:40 2013 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 04 Sep 2013 07:02:40 +0200 Subject: ServiceLoader In-Reply-To: <52265949.2080603@bestsolution.at> References: <52244E27.2010103@oracle.com> <62382472-87F5-43D1-B4DE-3CB09DD79A75@gmx.de> <5224D248.6000003@gmx.de> <9756D85B-458F-4AE1-AA08-79B809501CCA@oracle.com> <52257096.5070503@tbee.org> <1378219082.28083.28.camel@galactica.localdomain> <51F84AD0-7122-4F56-87B5-74C97B44917D@gmail.com> <1378222012.28083.35.camel@galactica.localdomain> <487715A2-CACC-402D-9E5D-3699F07960C6@oracle.com> <522611A1.5070804@tbee.org> <631A3551-BDBA-4D22-BD84-EC8D808AE708@oracle.com> <52262E07.2090509@tbee.org> <830FBB88-3016-40E8-A9C8-DDB86E800548@oracle.com> <52264C5A.6030005@tbee.org> <52265949.2080603@bestsolution.at> Message-ID: <5226BEF0.9020304@tbee.org> Richard said (2013-08-30 08:08) that builders still will be supported / needed; I need one to convert the string annotation in FXML to an appropriate data type (list of DateFormats). On my question what the alternative would be, if we're not to use builders because they were deprecated, the answer was that the build-in builders are deprecated, but the builders as a concept in FXML will still be used. On 2013-09-03 23:48, Tom Schindl wrote: > Well once we have a replacement for builders this is not needed anymore > so I don't think there's a JIRA needed. > > When we discussed replacements for builders in context of FXML the > consensus was to have annotations on the constructor to map the > arguments appropriately. Eva suggested @ConstructorProperties, I was > more in favor of explicit @FXMLValue annotation on each argument. > > Tom > > On 03.09.13 22:53, Tom Eugelink wrote: >> No, but there is a less-than-optimal-but-fast approach, and that is to >> write a custom BuilderFactory with if statements for all 3rd party >> controls. >> >> >> >> On 2013-09-03 20:46, Richard Bair wrote: >>> It is a real problem though (how to support 3rd party controls well). >>> Is there a JIRA for this case? >>> >>> Richard >>> >>> On Sep 3, 2013, at 11:44 AM, Tom Eugelink wrote: >>> >>>> True, so we'll leave it JFXtras then. >>>> >>>> >>>> On 2013-09-03 20:28, Richard Bair wrote: >>>>> The only knee-jerk reaction to the service loader is that it can be >>>>> bad at startup, because for the service loader to work, it has to >>>>> scan all jar files, which means downloading all jar files. Maybe >>>>> with Jigsaw we'll have a better mechanism for this such that we can >>>>> just read the first few bytes of a module and determine whether it >>>>> supports a certain service or not. >>>>> >>>>> Richard >>>>> >>>>> On Sep 3, 2013, at 9:43 AM, Tom Eugelink wrote: >>>>> >>>>>> On 2013-09-03 17:49, Richard Bair wrote: >>>>>>>> In this case, since JavaFX is Free Software! you can actually >>>>>>>> suggest >>>>>>>> the fix, prototype and propose the patch yourself, limiting the >>>>>>>> round >>>>>>>> trip time substantially. >>>>>>>> >>>>>> That said, in JFXtras I've created an extended FactoryBuilder that >>>>>> dynamically loads builder classes using Java's standard >>>>>> ServiceLoader approach. Would this be of interest for inclusion >>>>>> directly into JavaFX? >>>>>> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java >>>>>> >>>>>> >>>>>> It does require a slightly extended Builder interface though. >>>>>> https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java >>>>>> >>>>>> >>>>>> A little blabla about this on this blog entry: >>>>>> http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ >>>>>> >>>>>> Tom >>>>>> >> From hang.vo at oracle.com Wed Sep 4 01:32:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 08:32:07 +0000 Subject: hg: openjfx/8/graphics/rt: RT-23660: WinApi User32.sendMessage HWND_BROADCAST Message-ID: <20130904083241.37B4062533@hg.openjdk.java.net> Changeset: fc56181afdd6 Author: vadim Date: 2013-09-04 12:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fc56181afdd6 RT-23660: WinApi User32.sendMessage HWND_BROADCAST Reviewed-by: Steve Northover, Kevin Rushforth, Chien Yang ! modules/graphics/src/main/native-prism-d3d/D3DContext.cc ! modules/graphics/src/main/native-prism-d3d/D3DContext.h ! modules/graphics/src/main/native-prism-d3d/D3DContextInit.cc ! modules/graphics/src/main/native-prism-d3d/D3DPipelineManager.cc ! modules/graphics/src/main/native-prism-d3d/D3DPipelineManager.h From hang.vo at oracle.com Wed Sep 4 03:03:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 10:03:29 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29584: Implement window.localStorage Message-ID: <20130904100405.1554562540@hg.openjdk.java.net> Changeset: bb696d27c662 Author: Vasiliy Baranov Date: 2013-09-04 13:53 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bb696d27c662 RT-29584: Implement window.localStorage ! modules/web/src/main/java/com/sun/webkit/FileSystem.java ! modules/web/src/main/java/com/sun/webkit/WebPage.java + modules/web/src/main/java/javafx/scene/web/DirectoryLock.java ! modules/web/src/main/java/javafx/scene/web/WebEngine.java + modules/web/src/main/java/javafx/scene/web/WebErrorEvent.java ! modules/web/src/main/native/Source/WebCore/TargetJava.pri ! modules/web/src/main/native/Source/WebCore/mapfile-macosx ! modules/web/src/main/native/Source/WebCore/mapfile-vers ! modules/web/src/main/native/Source/WebCore/platform/java/FileSystemJava.cpp ! modules/web/src/main/native/Source/WebCore/platform/java/FrameLoaderClientJava.cpp ! modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp ! modules/web/src/main/native/Source/WebCore/storage/StorageStrategy.cpp + modules/web/src/main/native/Source/WebCore/storage/StorageThread.cpp + modules/web/src/main/native/Source/WebCore/storage/StorageThread.h - modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.cpp - modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.h - modules/web/src/main/native/Source/WebCore/storage/java/StorageNamespaceJava.cpp - modules/web/src/main/native/Source/WebCore/storage/java/StorageNamespaceJava.h + modules/web/src/test/java/javafx/scene/web/DirectoryLockTest.java ! modules/web/src/test/java/javafx/scene/web/LoadNotificationsTest.java + modules/web/src/test/java/javafx/scene/web/UserDataDirectoryTest.java From hang.vo at oracle.com Wed Sep 4 05:47:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 12:47:31 +0000 Subject: hg: openjfx/8/graphics/rt: RT-17714 Support collection events in FXML Message-ID: <20130904124805.7217562549@hg.openjdk.java.net> Changeset: dc4e8f0255ba Author: Martin Sladecek Date: 2013-09-04 14:36 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dc4e8f0255ba RT-17714 Support collection events in FXML - modules/fxml/src/main/java/com/sun/javafx/fxml/ObservableListChangeEvent.java - modules/fxml/src/main/java/com/sun/javafx/fxml/ObservableMapChangeEvent.java ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java ! modules/fxml/src/test/java/javafx/fxml/RT_17714Controller.java + modules/fxml/src/test/java/javafx/fxml/RT_17714Controller2.java ! modules/fxml/src/test/java/javafx/fxml/RT_17714Test.java ! modules/fxml/src/test/java/javafx/fxml/Widget.java ! modules/fxml/src/test/resources/javafx/fxml/rt_17714.fxml From hang.vo at oracle.com Wed Sep 4 06:17:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 13:17:22 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20130904131809.75AFE6254C@hg.openjdk.java.net> Changeset: 04f6adb4eada Author: Pavel Safrata Date: 2013-09-04 14:03 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/04f6adb4eada RT-32602: TriangleMesh picking optimized by not creating lots of Point3Ds. ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java Changeset: 520a712d8a10 Author: Martin Sladecek Date: 2013-09-04 15:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/520a712d8a10 [DOC] RT-17714 : updated fxml documentation ! modules/fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html Changeset: dcce9cea3af1 Author: Martin Sladecek Date: 2013-09-04 15:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dcce9cea3af1 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt From hang.vo at oracle.com Wed Sep 4 06:03:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 13:03:07 +0000 Subject: hg: openjfx/8/controls/rt: RT-15121) ScrollBar emitting requestLayout() up hierarchy every time it's value changes Message-ID: <20130904130352.AB4496254A@hg.openjdk.java.net> Changeset: bab22eeb95fd Author: mickf Date: 2013-09-04 13:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bab22eeb95fd RT-15121) ScrollBar emitting requestLayout() up hierarchy every time it's value changes ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollBarSkin.java From hang.vo at oracle.com Wed Sep 4 06:32:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 13:32:31 +0000 Subject: hg: openjfx/8/graphics/rt: Temporarily exclude unit tests that are failing on Hudson. Message-ID: <20130904133247.5A6406254D@hg.openjdk.java.net> Changeset: 128976a231a2 Author: Vasiliy Baranov Date: 2013-09-04 17:20 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/128976a231a2 Temporarily exclude unit tests that are failing on Hudson. ! modules/web/src/test/java/javafx/scene/web/UserDataDirectoryTest.java From hang.vo at oracle.com Wed Sep 4 08:02:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 15:02:54 +0000 Subject: hg: openjfx/8/graphics/rt: iOS: crosslibs 07; transition to jdk8-mobile-ios-ejdk Message-ID: <20130904150330.545B26255A@hg.openjdk.java.net> Changeset: c590bf86c848 Author: Oldrich Maticka Date: 2013-09-04 16:59 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c590bf86c848 iOS: crosslibs 07; transition to jdk8-mobile-ios-ejdk ! buildSrc/ios.gradle From hang.vo at oracle.com Wed Sep 4 07:03:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 14:03:06 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130904140353.D65816254F@hg.openjdk.java.net> Changeset: 0b6186f39a8f Author: Martin Sladecek Date: 2013-09-04 15:45 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0b6186f39a8f RT-32697 NPE in hashCode method of SimpleSetProperty ! modules/base/src/main/java/javafx/beans/property/ReadOnlySetProperty.java Changeset: cfdb41b7b640 Author: Martin Sladecek Date: 2013-09-04 15:45 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cfdb41b7b640 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt From hang.vo at oracle.com Wed Sep 4 10:17:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 17:17:54 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130904171844.9A72A62563@hg.openjdk.java.net> Changeset: 61ded8479309 Author: kcr Date: 2013-09-04 09:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/61ded8479309 RT-32701: Debug build fails to build T2K on Linux ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/linux.gradle ! buildSrc/x86egl.gradle Changeset: fd5c3a88cd07 Author: kcr Date: 2013-09-04 10:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fd5c3a88cd07 RT-31500: Gradle: build in debug mode by default ! build.gradle ! gradle.properties.template From hang.vo at oracle.com Wed Sep 4 10:32:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 17:32:57 +0000 Subject: hg: openjfx/8/graphics/rt: ECLIPSE: work around Eclipse jdk8 compiler problem Message-ID: <20130904173313.02C8862564@hg.openjdk.java.net> Changeset: 9d380c47ef14 Author: snorthov Date: 2013-09-04 13:26 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9d380c47ef14 ECLIPSE: work around Eclipse jdk8 compiler problem ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java From hang.vo at oracle.com Wed Sep 4 10:48:00 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 17:48:00 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31476: Exception when font size is set to 0 Message-ID: <20130904174818.6207F62565@hg.openjdk.java.net> Changeset: 906d256bc339 Author: Felipe Heidrich Date: 2013-09-04 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/906d256bc339 RT-31476: Exception when font size is set to 0 ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontFile.java From hang.vo at oracle.com Wed Sep 4 13:03:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 20:03:44 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130904200432.1B9966256C@hg.openjdk.java.net> Changeset: 35ec849231d5 Author: kcr Date: 2013-09-04 12:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/35ec849231d5 Debug builds do not work on Linux, so reverting fix for RT-31500 Backed out changeset fd5c3a88cd07 ! build.gradle ! gradle.properties.template Changeset: 948f04472075 Author: kcr Date: 2013-09-04 12:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/948f04472075 Debug builds do not work on Linux, so reverting fix for RT-32701 Backed out changeset 61ded8479309 ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/linux.gradle ! buildSrc/x86egl.gradle From hang.vo at oracle.com Wed Sep 4 13:32:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 20:32:55 +0000 Subject: hg: openjfx/8/graphics/rt: Fix to RT-31666: Core dump when forcing es2 pipeline on Linux with Intel GPU. Message-ID: <20130904203327.C0C986256F@hg.openjdk.java.net> Changeset: 55411f1b25b3 Author: Chien Yang Date: 2013-09-04 13:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/55411f1b25b3 Fix to RT-31666: Core dump when forcing es2 pipeline on Linux with Intel GPU. Reviewed-by: David Hill, Kevin Rushiforth and Yao Wang ! modules/graphics/src/main/native-prism-es2/windows/WinGLContext.c ! modules/graphics/src/main/native-prism-es2/x11/X11GLContext.c From hang.vo at oracle.com Wed Sep 4 13:47:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 20:47:47 +0000 Subject: hg: openjfx/8/graphics/rt: Fix to RT-30446: ES2: Minimize round trip GL calls in production code Message-ID: <20130904204814.58FDD62575@hg.openjdk.java.net> Changeset: c06259a9d8b7 Author: Chien Yang Date: 2013-09-04 13:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c06259a9d8b7 Fix to RT-30446: ES2: Minimize round trip GL calls in production code Reviewed-by: Daniel Blaukopf, Kevin Rushiforth, Thor Johannesson ! modules/graphics/src/main/java/com/sun/prism/es2/GLContext.java ! modules/graphics/src/main/native-prism-es2/GLContext.c From hang.vo at oracle.com Wed Sep 4 14:18:12 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 21:18:12 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32378: add parfait support to gradle build Message-ID: <20130904211832.520E86257A@hg.openjdk.java.net> Changeset: 92d277a8419c Author: Felipe Heidrich Date: 2013-09-04 14:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/92d277a8419c RT-32378: add parfait support to gradle build ! build.gradle ! buildSrc/genVSproperties.bat ! buildSrc/linux.gradle ! buildSrc/mac.gradle ! buildSrc/src/main/groovy/com/sun/javafx/gradle/LinkTask.groovy ! buildSrc/win.gradle From hang.vo at oracle.com Wed Sep 4 16:48:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Sep 2013 23:48:26 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26952 Delete Dead D3DWindow.cc code in prism-d3d-native Message-ID: <20130904234857.A0F3A6257E@hg.openjdk.java.net> Changeset: 1edf46aeb5f7 Author: Yao Wang Date: 2013-09-04 16:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1edf46aeb5f7 RT-26952 Delete Dead D3DWindow.cc code in prism-d3d-native - modules/graphics/src/main/native-prism-d3d/D3DWindow.cc From hang.vo at oracle.com Thu Sep 5 00:04:04 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 07:04:04 +0000 Subject: hg: openjfx/8/graphics/rt: 4 new changesets Message-ID: <20130905070527.D45F862586@hg.openjdk.java.net> Changeset: e0a443614907 Author: peterz Date: 2013-09-05 10:49 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e0a443614907 RT-32595 Exception when printing contents of WebView ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java Changeset: 9cf30bb25652 Author: peterz Date: 2013-09-05 10:50 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9cf30bb25652 RT-32607 Removal of the about: protocol handler causes many DRT tests to fail ! modules/web/src/main/java/com/sun/webkit/network/URLs.java + modules/web/src/main/java/com/sun/webkit/network/about/AboutURLConnection.java + modules/web/src/main/java/com/sun/webkit/network/about/Handler.java Changeset: 9ab492f337a5 Author: peterz Date: 2013-09-05 10:51 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9ab492f337a5 RT-32611 Remove PolicyClientImpl - modules/web/src/main/java/com/sun/javafx/webkit/PolicyClientImpl.java ! modules/web/src/main/java/javafx/scene/web/WebEngine.java Changeset: a18f63e9aba6 Author: peterz Date: 2013-09-05 10:53 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a18f63e9aba6 RT-31729 HiDPI: WebView hasn't hidpi rendering ! modules/web/src/main/java/com/sun/javafx/webkit/prism/PrismGraphicsManager.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/RTImage.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCBufferedContext.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCPageBackBufferImpl.java From hang.vo at oracle.com Thu Sep 5 00:33:14 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 07:33:14 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32384: localToParentTx kept as simple as possible. Message-ID: <20130905073330.90EC962589@hg.openjdk.java.net> Changeset: 3e8b6b2d3c1e Author: Pavel Safrata Date: 2013-09-05 08:26 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3e8b6b2d3c1e RT-32384: localToParentTx kept as simple as possible. ! modules/graphics/src/main/java/com/sun/javafx/geom/transform/Affine2D.java ! modules/graphics/src/main/java/com/sun/javafx/geom/transform/Affine3D.java ! modules/graphics/src/main/java/com/sun/javafx/geom/transform/AffineBase.java ! modules/graphics/src/main/java/com/sun/javafx/geom/transform/BaseTransform.java ! modules/graphics/src/main/java/com/sun/javafx/geom/transform/Identity.java ! modules/graphics/src/main/java/com/sun/javafx/geom/transform/Translate2D.java ! modules/graphics/src/main/java/com/sun/javafx/scene/transform/TransformUtils.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/transform/Affine.java ! modules/graphics/src/main/java/javafx/scene/transform/Rotate.java ! modules/graphics/src/main/java/javafx/scene/transform/Scale.java ! modules/graphics/src/main/java/javafx/scene/transform/Shear.java ! modules/graphics/src/main/java/javafx/scene/transform/Transform.java ! modules/graphics/src/main/java/javafx/scene/transform/Translate.java ! modules/graphics/src/test/java/com/sun/javafx/test/TransformHelper.java ! modules/graphics/src/test/java/javafx/scene/NodeTest.java + modules/graphics/src/test/java/javafx/scene/transform/TransformDeriveTest.java ! modules/graphics/src/test/java/javafx/scene/transform/TransformTest.java From hang.vo at oracle.com Thu Sep 5 01:18:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 08:18:01 +0000 Subject: hg: openjfx/8/graphics/rt: ScrollEvent - fixed constructor argument names to match javadoc and other constructors. Message-ID: <20130905081816.8B5E86258B@hg.openjdk.java.net> Changeset: acf4b07fa2f6 Author: Pavel Safrata Date: 2013-09-05 09:03 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/acf4b07fa2f6 ScrollEvent - fixed constructor argument names to match javadoc and other constructors. ! modules/graphics/src/main/java/javafx/scene/input/ScrollEvent.java From hang.vo at oracle.com Thu Sep 5 02:18:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 09:18:02 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32680: DRT test harness is broken Message-ID: <20130905091849.D144D6258F@hg.openjdk.java.net> Changeset: c8461294f0e2 Author: Vasiliy Baranov Date: 2013-09-05 13:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c8461294f0e2 RT-32680: DRT test harness is broken ! modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp From hang.vo at oracle.com Thu Sep 5 06:18:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 13:18:22 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32720 Subclassing SimpleObjectProperty results in many listeners causing eventual high CPU use Message-ID: <20130905131859.944726259D@hg.openjdk.java.net> Changeset: 06fd648260a0 Author: Martin Sladecek Date: 2013-09-05 15:03 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/06fd648260a0 RT-32720 Subclassing SimpleObjectProperty results in many listeners causing eventual high CPU use ! modules/base/src/main/java/com/sun/javafx/binding/SelectBinding.java From hang.vo at oracle.com Thu Sep 5 07:17:51 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 14:17:51 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31356 FXML loader: bad exception returned in case of incorrect URL Message-ID: <20130905141824.C68AC625A1@hg.openjdk.java.net> Changeset: eac39a252c9a Author: Martin Sladecek Date: 2013-09-05 16:08 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eac39a252c9a RT-31356 FXML loader: bad exception returned in case of incorrect URL ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java From hang.vo at oracle.com Thu Sep 5 07:33:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 14:33:11 +0000 Subject: hg: openjfx/8/controls/rt: RT-20698 : Pannable ScrollPane behaves badly when content changes during panning Message-ID: <20130905143347.15E03625A2@hg.openjdk.java.net> Changeset: c1e031aecfea Author: mickf Date: 2013-09-05 15:27 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c1e031aecfea RT-20698 : Pannable ScrollPane behaves badly when content changes during panning ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From hang.vo at oracle.com Thu Sep 5 07:43:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 14:43:08 +0000 Subject: hg: openjfx/8/master/rt: 89 new changesets Message-ID: <20130905150609.1055D625A3@hg.openjdk.java.net> Changeset: 93f3f06641e8 Author: mv157916 Date: 2013-08-29 14:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/93f3f06641e8 RT-32599: Update the JDK build number to b105 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 2285e786059a Author: leifs Date: 2013-08-27 10:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2285e786059a RT-32492 + RT-32493 DatePicker: Add shortcuts for switching months/years directly when the calendar is open ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerContent.java Changeset: 7f98f57fecd2 Author: David Grieve Date: 2013-08-28 07:36 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7f98f57fecd2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 3db94ad212b6 Author: jgiles Date: 2013-08-28 16:35 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3db94ad212b6 RT-29885: Regression: issue with ComboBox focusedProperty I've fixed this for both ComboBox and DatePicker, which is built on top of the same ComboBox base code and so had the same problem. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/java/javafx/scene/control/ComboBoxBase.java Changeset: bf88b13087fd Author: jgiles Date: 2013-08-29 09:34 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bf88b13087fd Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 2fd809b11dfd Author: psomashe Date: 2013-08-28 14:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2fd809b11dfd RT-30317 ChoiceBox failed to update the displayed text after calling setItems from Platfrom.runLater ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java + modules/controls/src/test/java/com/sun/javafx/scene/control/skin/ChoiceBoxSkinNodesRetriever.java ! modules/controls/src/test/java/javafx/scene/control/ChoiceBoxTest.java Changeset: 1d4565315819 Author: jgiles Date: 2013-08-29 15:43 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1d4565315819 RT-21444: SelectionModel.getSelectedItem() API does not work correctly in case when multiple selection is enabled and Shift key is down. Issue resolved in ListView, TreeView, TableView, and TreeTableView. Unit tests have been developed to prevent future regressions. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! modules/controls/src/test/java/javafx/scene/control/ListViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java Changeset: 9b8894841264 Author: jgiles Date: 2013-08-29 15:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9b8894841264 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: c52ac94b9d02 Author: leifs Date: 2013-08-29 12:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c52ac94b9d02 RT-24920: [CheckBox, RadioButton] Layout regression (was: Text Overrun incorrect work in CheckBox and RadioButton) ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: c661253e25cf Author: jgiles Date: 2013-08-30 13:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c661253e25cf RT-32559: TableView: replaced columns disappear ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: b2d31f6fb68d Author: jgiles Date: 2013-08-30 16:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b2d31f6fb68d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 0339d4004e85 Author: mickf Date: 2013-08-30 15:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0339d4004e85 RT-32327 : Threading issues with ProgressBar / ProgressIndicator after fix for RT-27791 ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 79af5cf2bf70 Author: mickf Date: 2013-08-30 15:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/79af5cf2bf70 RT-32584 : Indeterminate ProgressIndicator's spin property ignored for first play ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 16d1fc60bd6a Author: leifs Date: 2013-08-30 10:41 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/16d1fc60bd6a RT-2529: Locale specific runtime errors (Turkish) ! build.gradle ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/WebColorFieldSkin.java ! modules/fxml/src/main/java/com/sun/javafx/fxml/builder/TriangleMeshBuilder.java ! modules/graphics/src/main/java/com/sun/glass/ui/Platform.java ! modules/graphics/src/main/java/com/sun/glass/ui/PlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/accessible/AccessibleLogger.java ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensLogger.java ! modules/graphics/src/main/java/com/sun/javafx/css/converters/EnumConverter.java ! modules/graphics/src/main/java/com/sun/javafx/css/converters/FontConverter.java ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/main/java/javafx/scene/Cursor.java ! modules/graphics/src/main/java/javafx/scene/input/KeyCombination.java ! modules/graphics/src/main/java/javafx/scene/paint/Color.java ! modules/graphics/src/test/java/com/sun/javafx/css/StylesheetTest.java ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubFontLoader.java Changeset: 98073a78b861 Author: leifs Date: 2013-08-30 11:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/98073a78b861 RT-31857: DatePicker: "<" and ">" buttons for previous/next year are missing. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerContent.java Changeset: 089d0e8cb4d6 Author: leifs Date: 2013-08-30 14:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/089d0e8cb4d6 RT-31349: TextField, bidi text drifts when caret moves to bidi boundary. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 91a0d78259d2 Author: jgiles Date: 2013-08-31 08:07 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/91a0d78259d2 RT-32582: [ComboBox] unnecessary scroll bar in dropdown ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 9245ffbe8c4f Author: jgiles Date: 2013-08-31 12:18 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9245ffbe8c4f RT-32618: change listener on ListView is called one extra time. The same problem was also being exhibited on the other virtualised controls, so this changeset resolves it in all cases, and adds a parameterised test for both single and multiple selection models, to prevent this appearing again. ! modules/controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/MultipleSelectionModelImplTest.java ! modules/controls/src/test/java/javafx/scene/control/SelectionModelImplTest.java Changeset: a11427375c9b Author: jgiles Date: 2013-08-31 12:20 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a11427375c9b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 3acaf13c190c Author: jgiles Date: 2013-09-02 12:54 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3acaf13c190c RT-32253: Uncaught exception in static initializer for Control prevents creation of all controls ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java Changeset: 2e11c8f35ee5 Author: jgiles Date: 2013-09-02 13:16 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2e11c8f35ee5 RT-31104: TableView makes multiple selection drags difficult ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: bd2c6e6b661a Author: jgiles Date: 2013-09-02 13:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bd2c6e6b661a RT-32620: CheckBox cell factory in tree view unselects every cell ! modules/controls/src/main/java/javafx/scene/control/TreeItem.java Changeset: e60e9a5396e6 Author: jgiles Date: 2013-09-02 17:18 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e60e9a5396e6 RT-29885: Regression: issue with ComboBox focusedProperty ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/java/javafx/scene/control/ComboBox.java ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java Changeset: 18a02cf34ddf Author: mickf Date: 2013-09-02 13:14 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/18a02cf34ddf RT-32654 : ScrollPane - remove DOS line endings, no code changed ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 3f656fbd508f Author: mickf Date: 2013-09-02 13:44 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3f656fbd508f RT-31901 - Regression: scrollbar issue with TitledPane ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 74c06be0319b Author: jgiles Date: 2013-09-03 16:46 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/74c06be0319b RT-31093: Drag doesn't start from Date Picker text field The same problem existed for ComboBox, so it is now resolved in both places. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java Changeset: cb91a18c5738 Author: jgiles Date: 2013-09-03 17:08 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cb91a18c5738 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: e7d52acb03ee Author: mickf Date: 2013-09-03 13:45 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e7d52acb03ee RT-32676 - ProgressIndicator : possible null timeline if clipped, and then set invisible. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: a0ec3cc8567c Author: David Grieve Date: 2013-09-03 09:15 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a0ec3cc8567c RT-32551: don't consider origin of already found font sub-properties when getting the other font sub-properties ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/test/java/com/sun/javafx/css/FontTypeTest.java ! modules/graphics/src/test/resources/com/sun/javafx/css/HonorDeveloperSettingsTest_AUTHOR.css Changeset: 20c49dd998fd Author: David Grieve Date: 2013-09-03 10:54 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/20c49dd998fd Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: ec82a5c0079b Author: David Grieve Date: 2013-09-03 12:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ec82a5c0079b fix NPE in CssStyleHelper found while running Shapes3DSceneLightTester ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java Changeset: 6c72b0975d08 Author: rbair Date: 2013-08-27 14:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6c72b0975d08 Make getters final ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java Changeset: 259a333fe8c3 Author: Oleg Mazurov Date: 2013-08-27 17:20 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/259a333fe8c3 [TOOLS] port gltrace to Mac OS X ! tools/gltrace/Makefile ! tools/gltrace/egl.c ! tools/gltrace/enums.c ! tools/gltrace/gles.c ! tools/gltrace/iolib.c ! tools/gltrace/os.h ! tools/gltrace/retrace.c ! tools/gltrace/trace.h Changeset: 926292821d67 Author: Oleg Mazurov Date: 2013-08-27 17:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/926292821d67 [TOOLS] gltrace: new files + tools/gltrace/Makefile.linux + tools/gltrace/Makefile.macosx + tools/gltrace/egl.h + tools/gltrace/gles.h + tools/gltrace/os-macosx.c + tools/gltrace/trace-macosx.c Changeset: 767b6cf4c7a7 Author: rbair Date: 2013-08-27 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/767b6cf4c7a7 Updated some printlns for the benchmarks ! apps/performance/GraphicsPerformance/src/main/java/nodecount/BenchBase.java ! apps/performance/GraphicsPerformance/src/main/java/nodecount/BenchTest.java ! apps/performance/GraphicsPerformance/src/main/java/scrolling/ScrollingBenchBase.java Changeset: 1e32e7f401fe Author: rbair Date: 2013-08-27 17:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1e32e7f401fe Added PULSE_LOGGER output for number of times we go down the slow paths for rendering an NGRegion's background or shape ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 7218b4a0e399 Author: rbair Date: 2013-08-27 17:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7218b4a0e399 RT-32568: Redundant calls to GL Viewport ! modules/graphics/src/main/java/com/sun/prism/es2/GLContext.java Changeset: 11a3223d951e Author: rbair Date: 2013-08-27 17:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/11a3223d951e Typo fix in Ensemble ! apps/samples/Ensemble8/src/app/java/ensemble/HomePage.java ! apps/samples/Ensemble8/src/app/java/ensemble/PageBrowser.java Changeset: 1e133a8c7a60 Author: peterz Date: 2013-08-28 11:43 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1e133a8c7a60 Removed stray references to libxml2 from build.gradle ! build.gradle Changeset: fbab6330a073 Author: Vasiliy Baranov Date: 2013-08-28 12:27 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fbab6330a073 RT-21460: Unit test javafx.scene.web.IrresponsiveScriptTest hangs ! build.gradle + modules/web/src/main/java/com/sun/webkit/WatchdogTimer.java ! modules/web/src/main/native/Source/JavaScriptCore/TargetJava.pri ! modules/web/src/main/native/Source/JavaScriptCore/runtime/Watchdog.cpp ! modules/web/src/main/native/Source/JavaScriptCore/runtime/Watchdog.h + modules/web/src/main/native/Source/JavaScriptCore/runtime/WatchdogJava.cpp ! modules/web/src/main/native/Source/WebCore/mapfile-macosx ! modules/web/src/main/native/Source/WebCore/mapfile-vers ! modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp ! modules/web/src/test/java/javafx/scene/web/IrresponsiveScriptTest.java Changeset: fa2f68455df7 Author: snorthov Date: 2013-08-28 12:32 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fa2f68455df7 Add a prism properties to set glyph cache width and height Reviewed by Richard B ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java Changeset: 470b1208edc5 Author: snorthov Date: 2013-08-28 13:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/470b1208edc5 oops, remove bogus println() ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java Changeset: 5044e490ca48 Author: snorthov Date: 2013-08-28 13:13 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5044e490ca48 RT-27006: unread transferData field in FXCanvas [fix was to comment out the variable] ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java Changeset: 2e57da87f2fc Author: Chien Yang Date: 2013-08-28 10:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2e57da87f2fc Added a simple texCoord test program + apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMeshTexCoordTest.java Changeset: 0795d1f82705 Author: snorthov Date: 2013-08-28 13:42 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0795d1f82705 ECLIPSE: work around Eclipse jdk8 compiler problem ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java Changeset: bc3aed6f8860 Author: Chien Yang Date: 2013-08-28 13:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bc3aed6f8860 Minor adjustment to mesh size to improve code readability. ! apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMeshTexCoordTest.java Changeset: 90987ded4e33 Author: Felipe Heidrich Date: 2013-08-28 15:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/90987ded4e33 RT-32183: [TextFlow] Strange symbol and objects position with '\n'. ! modules/graphics/src/main/java/com/sun/javafx/text/GlyphLayout.java Changeset: e1d138d550e9 Author: Petr Pchelko Date: 2013-08-29 11:06 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e1d138d550e9 RT-27065 Win: [GlassRobot] GlassRobot can't press some keyboard buttons in one time Reviewed-by: anthony, art ! modules/graphics/src/main/native-glass/win/KeyTable.cpp ! modules/graphics/src/main/native-glass/win/KeyTable.h ! modules/graphics/src/main/native-glass/win/Robot.cpp Changeset: 02dab18d5824 Author: Alexander Zvegintsev Date: 2013-08-29 17:09 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/02dab18d5824 RT-31730 Gtk: Incorrect screen coordinates reporting ! modules/graphics/src/main/native-glass/gtk/GlassView.cpp ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp Changeset: f219f9bc5347 Author: Pavel Safrata Date: 2013-08-29 14:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f219f9bc5347 Graphics NetBeans project: fixed debugging tests. ! netbeans/graphics/build.xml Changeset: b4067344e883 Author: Pavel Safrata Date: 2013-08-29 14:40 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b4067344e883 RT-32455: removed obsolete WeakReferenceMap. - modules/graphics/src/main/java/com/sun/javafx/WeakReferenceMap.java - modules/graphics/src/test/java/com/sun/javafx/WeakReferenceMapTest.java Changeset: 40312b689a50 Author: snorthov Date: 2013-08-29 14:48 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/40312b689a50 RT-31367 [SWT] Custom data types cannot be transfered with DnD reviewed by anton ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java Changeset: 4cf6e02ce489 Author: rbair Date: 2013-08-29 14:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4cf6e02ce489 RT-32589: Add better diagnostic and debug tools for dirty regions, culling, and overdraw Reviewed-By: Steve Northover, Martin Sladecek Added a new dirty bit for debug information that needs to be sent down. Also completely changed the way we draw in ViewPainter, specifically when dirty regions are used and even more specifically when show dirty and show overdraw are turned on. Added some new prism settings for showing overdraw, and printing the render graph to the pulse logger. Also replaced the drawCullBits to instead draw overdraw boxes. You can get a better sense of cull bits by looking at the output of the render graph being printed to the pulse logger. ! modules/graphics/src/main/java/com/sun/javafx/scene/DirtyBits.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NodePath.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java ! modules/graphics/src/main/java/com/sun/prism/Graphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/OcclusionCullingTest.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/RenderRootTest.java Changeset: d7de1fc065a0 Author: rbair Date: 2013-08-29 14:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d7de1fc065a0 Added Hello app for showing overdraw. + apps/toys/Hello/src/main/java/hello/HelloOverdraw.java Changeset: 056f995f83e4 Author: rbair Date: 2013-08-29 16:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/056f995f83e4 Fixed bug I introduced where "reset" always set the pointer to -1, whereas the assumption before was that reset would put the pointer on the first item. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NodePath.java Changeset: 74bd12468ff2 Author: Pavel Safrata Date: 2013-08-30 08:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/74bd12468ff2 RT-31256: Added ZERO constants to Point2D and Point3D. ! modules/graphics/src/main/java/javafx/geometry/Point2D.java ! modules/graphics/src/main/java/javafx/geometry/Point3D.java Changeset: eb5c0efd242d Author: Artem Ananiev Date: 2013-08-30 13:56 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/eb5c0efd242d RT-32138: Win: Java crashes on Windows 2008 R2 with JavaFX Reviewed-by: Anthony Petrov, Petr Pchelko ! modules/graphics/src/main/native-glass/win/ViewContainer.cpp Changeset: 8b9ed2be92ac Author: Lisa Selle Date: 2013-08-30 12:22 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8b9ed2be92ac Fix for rt-32583 - major rendering artifacts on BouncingBalls on eglfb path. ! modules/graphics/src/main/java/com/sun/prism/es2/GLContext.java Changeset: bf594c19a7a6 Author: rbair Date: 2013-08-30 09:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bf594c19a7a6 Change BenchBase to use the iPad resolution, and also exit on completion. ! apps/performance/GraphicsPerformance/src/main/java/nodecount/BenchBase.java Changeset: aec474945f1c Author: rbair Date: 2013-08-30 10:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/aec474945f1c Removed println and added extra check for 0 width / height when drawing dirty regions (since the code in paintOverdraw is unhappy about such things, and you can't draw a rect with 0 width or height anyway). ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: 3e92a5d12221 Author: rbair Date: 2013-08-30 10:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3e92a5d12221 Fixed typo ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java Changeset: 85a00128048f Author: rbair Date: 2013-08-30 10:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/85a00128048f Clean up HelloRectangle ! apps/toys/Hello/src/main/java/hello/HelloRectangle.java Changeset: c6f13b9fd75d Author: rbair Date: 2013-08-30 10:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c6f13b9fd75d ViewPainter shouldn't be painting anything if the width or height is <= 0 ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: a2677d23fe0e Author: rbair Date: 2013-08-30 11:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a2677d23fe0e RT-32603: Bad analysis in NGGroup#computeRenderRoot results in Nodes being rendered that need not be ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGTestBase.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/OcclusionCullingTest.java Changeset: 0c83c172d42c Author: Yao Wang Date: 2013-08-30 12:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0c83c172d42c RT-31521 8.0-graphics-scrum-h1423: Memory leak in PhongMaterial ! modules/graphics/src/main/java/com/sun/javafx/geom/transform/Affine3D.java ! modules/graphics/src/main/java/javafx/scene/paint/PhongMaterial.java ! modules/graphics/src/main/java/javafx/scene/shape/MeshView.java ! modules/graphics/src/main/java/javafx/scene/shape/Shape3D.java Changeset: 49f80deda70a Author: rbair Date: 2013-08-30 14:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/49f80deda70a RT-32639: NGRegion can avoid invalidating the backgroundInsets if the Background in question does not have any percentage-based CornerRadii on any BackgroundFills ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/javafx/scene/layout/Background.java ! modules/graphics/src/test/java/javafx/scene/layout/BackgroundTest.java Changeset: 348b5b2c38ea Author: Chien Yang Date: 2013-08-30 16:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/348b5b2c38ea Fix to RT-30723: EGL: Disable clipping when clearing framebuffer Reviewed by Dave, Lisa and Kevin ! modules/graphics/src/main/java/com/sun/prism/es2/EGLFBGLDrawable.java Changeset: a8e13d82e298 Author: rbair Date: 2013-08-30 22:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a8e13d82e298 Minor comment fixes to NGRegion, also minor change to RegionImageCache to have the constructor take a ResourceFactory instead of a Graphics object (since the Graphics object was only used to get at its resource factory, and it is better style to pass what is really needed instead of a carrier). ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/RegionImageCache.java Changeset: e200bd15abc2 Author: rbair Date: 2013-08-30 22:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e200bd15abc2 RT-32646: Regions go down a very slow rendering path when width / height are not pixel aligned and image cache is used ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 6789dad991cb Author: rbair Date: 2013-08-30 22:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6789dad991cb Updated TODO in NGRegion -- we definitely don't support background loaded images as image fills for a Region. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 89fe014f6435 Author: Assaf Yavani Date: 2013-09-01 13:11 +0300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/89fe014f6435 [RT-32593] - fb: fb cannot load on the pi Problem - fx failed to load with java.lang.UnsatisfiedLinkError when trying to run FX on raspberry pi with fb Analysis - lens platofrm utils was not linked to the .so fix - update the gradle files to include the file in the link command Reviewed by : Daniel B. Patch - http://sthinfra10.se.oracle.com:8060/cru/CR-FX8GFX-309 Tested on device ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle Changeset: f0620fe44d8a Author: tb115823 Date: 2013-09-02 14:22 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f0620fe44d8a Android: Fix failing build. Use lens_wm_notifyMultiTouchEvent instead of lens_wm_notifyTouchEvent ! buildSrc/android.gradle ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c Changeset: ad37f3adc5df Author: Alexander Zvegintsev Date: 2013-09-02 17:37 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ad37f3adc5df RT-32565 Gtk: mouse grab issue with dialogs activated from mouse handler ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp Changeset: b3d0c8df51b6 Author: Oldrich Maticka Date: 2013-09-02 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b3d0c8df51b6 iOS: Ensemble8 - fixing check for iOS; removing ScrollEvent synthesis for iOS - not needed; we have native scroll events + momentum/inertia ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java Changeset: 42e1b2938f98 Author: Rafi Tayar Date: 2013-09-02 18:19 +0300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/42e1b2938f98 RT-32468 Lens: Touch keyboard is not reliable on Raspberry Pi ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c Changeset: 3c9ebc34f4b7 Author: Rafi Tayar Date: 2013-09-02 18:19 +0300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3c9ebc34f4b7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: b2c061caf644 Author: Daniel Blaukopf Date: 2013-09-03 08:55 +0300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b2c061caf644 RT-32600 Lens: Pulse starvation because of overwhelming amount of MOUSE_MOVED events ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java Changeset: 514d70fdc70c Author: tb115823 Date: 2013-09-03 09:47 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/514d70fdc70c Android: Fixed renamed prism property glDepthSize. Default value 24 doesn't work on GT10.1 must be 16. Although such eglconfig is available glCreateContext fails with BAD_EGL_CONFIG 3005 error. Don't know why, need to investigate. ! buildSrc/android.gradle Changeset: 655f1ead4bc8 Author: tb115823 Date: 2013-09-03 09:47 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/655f1ead4bc8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: d04fe4c584d4 Author: Lubomir Nerad Date: 2013-09-03 14:41 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d04fe4c584d4 Include debug info in native for debug build ! buildSrc/ios.gradle Changeset: f56e0d2cbfc7 Author: Martin Sladecek Date: 2013-09-03 12:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f56e0d2cbfc7 RT-32657 Teleportation of animated object during TranslateTransition ! modules/graphics/src/main/java/javafx/animation/Animation.java ! modules/graphics/src/test/java/javafx/animation/AnimationTest.java Changeset: 357f66506342 Author: Martin Sladecek Date: 2013-09-03 12:44 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/357f66506342 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt Changeset: 391542e56deb Author: Artem Ananiev Date: 2013-09-03 15:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/391542e56deb RT-29095: Dragging from Swing to JavaFX (JFXPanel) that was working in JavaFX 2.2 fails in JavaFX 8.0 Reviewed-by: Kevin Rushforth, Pavel ??afrata ! modules/graphics/src/main/java/com/sun/javafx/tk/TKDragGestureListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKDropTargetListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSceneDnDEventHandler.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/scene/input/DataFormat.java ! modules/graphics/src/main/java/javafx/scene/input/Dragboard.java Changeset: 5946bd72bbc0 Author: pchelko Date: 2013-09-03 16:13 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5946bd72bbc0 RT-32661: Regression Mac OS : some keycode accelerators are badly rendered Reviewed-by: art, Alexander Zvegintsev ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java ! modules/graphics/src/main/native-glass/mac/GlassKey.m Changeset: 94e96dbe02db Author: Petr Pchelko Date: 2013-09-03 16:21 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/94e96dbe02db RT-31873: [SwingNode] : Something throws NullPointerException Reviewed-by: ant, art ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java Changeset: b84125298242 Author: ant Date: 2013-09-03 18:55 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b84125298242 RT-32656: [SwingNode]: correct the code sample with respect to thread safety Reviewed-by: art, pchelko ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java Changeset: ec2f564fb7a1 Author: Petr Pchelko Date: 2013-09-03 19:05 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ec2f564fb7a1 RT-26949: Mac: 8.0-b67: SW pipeline is broken on MacOS Reviewed-by: art, snorthov, ddhill ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewScene.java ! modules/graphics/src/main/java/com/sun/prism/GraphicsPipeline.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPipeline.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWPipeline.java ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m Changeset: e0f3abebc024 Author: jgodinez Date: 2013-09-03 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e0f3abebc024 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! build.gradle - modules/graphics/src/main/java/com/sun/javafx/WeakReferenceMap.java - modules/graphics/src/test/java/com/sun/javafx/WeakReferenceMapTest.java Changeset: 361d97db0d1c Author: hudson Date: 2013-09-05 07:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/361d97db0d1c Added tag 8.0-b106 for changeset e0f3abebc024 ! .hgtags From hang.vo at oracle.com Thu Sep 5 13:04:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 20:04:08 +0000 Subject: hg: openjfx/8/graphics/rt: Add -Dsun.perflog.fx.firstpaintexit and move properties to PrismSettings Message-ID: <20130905200447.D28AD625DB@hg.openjdk.java.net> Changeset: 877523a1e150 Author: snorthov Date: 2013-09-05 15:44 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/877523a1e150 Add -Dsun.perflog.fx.firstpaintexit and move properties to PrismSettings Reviewed by: Richard B ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PerformanceTrackerHelper.java ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java ! modules/graphics/src/main/java/javafx/scene/Scene.java From hang.vo at oracle.com Thu Sep 5 14:18:00 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 21:18:00 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130905211900.DC9A8625DC@hg.openjdk.java.net> Changeset: d6db14ea1ca7 Author: David Grieve Date: 2013-09-05 17:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d6db14ea1ca7 RT-29773: take sub-property style if it is closer or more specific than font shorthand ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/test/java/com/sun/javafx/css/FontTypeTest.java ! modules/graphics/src/test/resources/com/sun/javafx/css/HonorDeveloperSettingsTest_AUTHOR.css Changeset: 39bc7a47c6cb Author: David Grieve Date: 2013-09-05 17:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/39bc7a47c6cb RT-24621: if node has same cssFlag value as parent, process parent first ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: 5c3ec77e5d2a Author: David Grieve Date: 2013-09-05 17:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5c3ec77e5d2a RT-31865: check error status of image, return null from CSS image cache if image isError ! modules/controls/src/main/java/javafx/scene/control/Labeled.java ! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java From hang.vo at oracle.com Thu Sep 5 15:18:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Sep 2013 22:18:07 +0000 Subject: hg: openjfx/8/graphics/rt: [TOOLS] GLTrace.java is not initialized on Mac OS X Message-ID: <20130905221839.B343E625E4@hg.openjdk.java.net> Changeset: dc0086b1cad0 Author: Oleg Mazurov Date: 2013-09-05 15:19 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dc0086b1cad0 [TOOLS] GLTrace.java is not initialized on Mac OS X ! tools/gltrace/agent.c ! tools/gltrace/os.h ! tools/gltrace/retrace.c From hang.vo at oracle.com Thu Sep 5 17:18:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Sep 2013 00:18:01 +0000 Subject: hg: openjfx/8/controls/rt: [TEST ONLY] RT-31865 caused failures in RegionCSSTest. Need to register images with stub toolkit Message-ID: <20130906001838.472C4625E8@hg.openjdk.java.net> Changeset: 5707c927c106 Author: David Grieve Date: 2013-09-05 20:03 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5707c927c106 [TEST ONLY] RT-31865 caused failures in RegionCSSTest. Need to register images with stub toolkit ! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java ! modules/graphics/src/main/java/javafx/scene/layout/Background.java ! modules/graphics/src/main/java/javafx/scene/layout/BackgroundConverter.java ! modules/graphics/src/test/java/javafx/scene/layout/RegionCSSTest.java From hang.vo at oracle.com Thu Sep 5 17:33:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Sep 2013 00:33:22 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130906003407.40066625F1@hg.openjdk.java.net> Changeset: f00dbf5f48e9 Author: rbair Date: 2013-09-05 14:20 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f00dbf5f48e9 Fixed debug statements ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: fc17d9decdce Author: rbair Date: 2013-09-05 14:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fc17d9decdce Improved pulse log debugging by adding timings for present ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PresentingPainter.java From hang.vo at oracle.com Fri Sep 6 01:03:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Sep 2013 08:03:47 +0000 Subject: hg: openjfx/8/graphics/rt: RT-19329 FXMLLoader could expose error line number and error location Message-ID: <20130906080417.D14C4625FA@hg.openjdk.java.net> Changeset: b81242a973ce Author: Martin Sladecek Date: 2013-09-06 09:57 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b81242a973ce RT-19329 FXMLLoader could expose error line number and error location ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java From hang.vo at oracle.com Fri Sep 6 04:32:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Sep 2013 11:32:53 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130906113358.0E7A562600@hg.openjdk.java.net> Changeset: 3e59deb21105 Author: tb115823 Date: 2013-09-06 13:15 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3e59deb21105 Android: Create abstraction layer for application launcher to better support alternative VMs. + modules/graphics/src/android/java/com/oracle/dalvik/DalvikLauncher.java ! modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java - modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java.jfx78 + modules/graphics/src/android/java/com/oracle/dalvik/JavaSELauncher.java + modules/graphics/src/android/java/com/oracle/dalvik/Launcher.java ! modules/graphics/src/main/native-glass/lens/android/android.c ! modules/web/src/android/native/android_webview.c Changeset: 73c7426d2a0b Author: tb115823 Date: 2013-09-06 13:17 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/73c7426d2a0b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java.jfx78 From hang.vo at oracle.com Fri Sep 6 04:48:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Sep 2013 11:48:27 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130906114916.3934A62601@hg.openjdk.java.net> Changeset: f16a4c87f37c Author: Martin Sladecek Date: 2013-09-06 13:42 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f16a4c87f37c RT-32728 NPE thrown from EventType.EventTypeSerialization#findSubType ! modules/base/src/main/java/javafx/event/EventType.java Changeset: 91790a94caed Author: Martin Sladecek Date: 2013-09-06 13:42 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/91790a94caed Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt From hang.vo at oracle.com Fri Sep 6 05:04:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Sep 2013 12:04:09 +0000 Subject: hg: openjfx/8/graphics/rt: iOS: javascript source escaping in more effective way Message-ID: <20130906120428.4382262602@hg.openjdk.java.net> Changeset: 7ba79f409b2c Author: Oldrich Maticka Date: 2013-09-06 13:48 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7ba79f409b2c iOS: javascript source escaping in more effective way https://javafx-jira.kenai.com/browse/RT-32510 ! modules/web/src/ios/java/javafx/scene/web/WebEngine.java From hang.vo at oracle.com Fri Sep 6 09:03:51 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Sep 2013 16:03:51 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130906160447.48C906260B@hg.openjdk.java.net> Changeset: fa70a7506503 Author: David Grieve Date: 2013-09-06 11:47 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fa70a7506503 RT-32507: twiddleate the string before calling Cursor.cursor(string). Added more css cursor conversion unit tests. ! modules/graphics/src/main/java/com/sun/javafx/css/converters/CursorConverter.java ! modules/graphics/src/test/java/com/sun/javafx/css/CursorTypeTest.java Changeset: c28a7f760bee Author: David Grieve Date: 2013-09-06 11:47 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c28a7f760bee RT-27088: add -fx-close-tab-animation and -fx-open-tab-animation to cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html From hang.vo at oracle.com Fri Sep 6 11:03:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Sep 2013 18:03:43 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32678 [FX3D] Light: light crashes. Message-ID: <20130906180431.403BE6260F@hg.openjdk.java.net> Changeset: 241aa8bcd937 Author: Yao Wang Date: 2013-09-06 10:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/241aa8bcd937 RT-32678 [FX3D] Light: light crashes. ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DMeshView.java ! modules/graphics/src/main/java/com/sun/prism/es2/ES2MeshView.java ! modules/graphics/src/main/native-prism-d3d/D3DMeshView.cc ! modules/graphics/src/main/native-prism-es2/GLContext.c From pedro.duquevieira at gmail.com Fri Sep 6 12:40:13 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 6 Sep 2013 20:40:13 +0100 Subject: Will video and audio recording make it to jdk8? Message-ID: Hi, Will video and audio recording be on jdk8? Thanks in advance, best regards, -- Pedro Duque Vieira From randahl at rockit.dk Fri Sep 6 12:48:07 2013 From: randahl at rockit.dk (Randahl Isaksen) Date: Fri, 6 Sep 2013 21:48:07 +0200 Subject: Will video and audio recording make it to jdk8? In-Reply-To: References: Message-ID: I am holding my breath in anticipation for the answer to this question... This is one of the most voted for issues. Den 06/09/2013 21.43 skrev "Pedro Duque Vieira" : > Hi, > > Will video and audio recording be on jdk8? > > Thanks in advance, best regards, > > -- > Pedro Duque Vieira > From pedro.duquevieira at gmail.com Fri Sep 6 12:49:58 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 6 Sep 2013 20:49:58 +0100 Subject: Will video and audio recording make it to jdk8? In-Reply-To: References: Message-ID: I was under the impression that it will be. But have heard some people saying it won't... On Fri, Sep 6, 2013 at 8:48 PM, Randahl Isaksen wrote: > I am holding my breath in anticipation for the answer to this question... > This is one of the most voted for issues. > Den 06/09/2013 21.43 skrev "Pedro Duque Vieira" < > pedro.duquevieira at gmail.com>: > > Hi, >> >> Will video and audio recording be on jdk8? >> >> Thanks in advance, best regards, >> >> -- >> Pedro Duque Vieira >> > -- Pedro Duque Vieira From christian.schudt at gmx.de Fri Sep 6 13:02:10 2013 From: christian.schudt at gmx.de (Christian Schudt) Date: Fri, 6 Sep 2013 22:02:10 +0200 Subject: Will video and audio recording make it to jdk8? In-Reply-To: References: Message-ID: Just recently the Camera and Microphone feature was rescheduled from Lombard to Van Ness. As well as some related issues, like radio streaming. So unfortunately, I guess no. https://javafx-jira.kenai.com/browse/RT-3458 Christian Am 06.09.2013 um 21:49 schrieb Pedro Duque Vieira: > I was under the impression that it will be. But have heard some people > saying it won't... > > > On Fri, Sep 6, 2013 at 8:48 PM, Randahl Isaksen wrote: > >> I am holding my breath in anticipation for the answer to this question... >> This is one of the most voted for issues. >> Den 06/09/2013 21.43 skrev "Pedro Duque Vieira" < >> pedro.duquevieira at gmail.com>: >> >> Hi, >>> >>> Will video and audio recording be on jdk8? >>> >>> Thanks in advance, best regards, >>> >>> -- >>> Pedro Duque Vieira >>> >> > > > -- > Pedro Duque Vieira From pedro.duquevieira at gmail.com Fri Sep 6 13:15:16 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 6 Sep 2013 21:15:16 +0100 Subject: Creating custom charts Message-ID: Hi, I'm trying to create a custom chart: a XYBarChart. That is a chart that won't have the same limitation as the BarChart which only allows you to specify a ValueAxis/CategoryAxis pair. In doing this I was looking at the code for BarChart and copying as much as I can from its implementation. The problem is that it uses a lot of package private methods and fields from XYChart. I think the framework chart implementations should be less reliant on package private methods because if that happens then programmers trying to create their own charts will probably need to rely on those same methods which of course they won't be able to call. Best regards, -- Pedro Duque Vieira From swpalmer at gmail.com Fri Sep 6 13:52:06 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 6 Sep 2013 16:52:06 -0400 Subject: Will video and audio recording make it to jdk8? In-Reply-To: References: Message-ID: <7E061061-78D4-4A76-95D1-F59CB84AEA5D@gmail.com> Is VanNess 8.1 or 9.0? Scott On 2013-09-06, at 4:02 PM, Christian Schudt wrote: > Just recently the Camera and Microphone feature was rescheduled from Lombard to Van Ness. > As well as some related issues, like radio streaming. > > So unfortunately, I guess no. > https://javafx-jira.kenai.com/browse/RT-3458 > > Christian > > > > Am 06.09.2013 um 21:49 schrieb Pedro Duque Vieira: > >> I was under the impression that it will be. But have heard some people >> saying it won't... >> >> >> On Fri, Sep 6, 2013 at 8:48 PM, Randahl Isaksen wrote: >> >>> I am holding my breath in anticipation for the answer to this question... >>> This is one of the most voted for issues. >>> Den 06/09/2013 21.43 skrev "Pedro Duque Vieira" < >>> pedro.duquevieira at gmail.com>: >>> >>> Hi, >>>> >>>> Will video and audio recording be on jdk8? >>>> >>>> Thanks in advance, best regards, >>>> >>>> -- >>>> Pedro Duque Vieira >>>> >>> >> >> >> -- >> Pedro Duque Vieira > From rdarrylr at yahoo.com Fri Sep 6 16:01:25 2013 From: rdarrylr at yahoo.com (rdarrylr at yahoo.com) Date: Fri, 6 Sep 2013 23:01:25 +0000 Subject: Will video and audio recording make it to jdk8? In-Reply-To: References: Message-ID: <900091956-1378508450-cardhu_decombobulator_blackberry.rim.net-2128949463-@b15.c11.bise6.blackberry> That's really disappointing :( -Darryl -----Original Message----- From: Christian Schudt Sender: openjfx-dev-bounces at openjdk.java.net Date: Fri, 6 Sep 2013 22:02:10 To: Pedro Duque Vieira Cc: OpenJFX Mailing List Subject: Re: Will video and audio recording make it to jdk8? Just recently the Camera and Microphone feature was rescheduled from Lombard to Van Ness. As well as some related issues, like radio streaming. So unfortunately, I guess no. https://javafx-jira.kenai.com/browse/RT-3458 Christian Am 06.09.2013 um 21:49 schrieb Pedro Duque Vieira: > I was under the impression that it will be. But have heard some people > saying it won't... > > > On Fri, Sep 6, 2013 at 8:48 PM, Randahl Isaksen wrote: > >> I am holding my breath in anticipation for the answer to this question... >> This is one of the most voted for issues. >> Den 06/09/2013 21.43 skrev "Pedro Duque Vieira" < >> pedro.duquevieira at gmail.com>: >> >> Hi, >>> >>> Will video and audio recording be on jdk8? >>> >>> Thanks in advance, best regards, >>> >>> -- >>> Pedro Duque Vieira >>> >> > > > -- > Pedro Duque Vieira From hang.vo at oracle.com Sun Sep 8 16:04:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 08 Sep 2013 23:04:10 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30741: Super Shader Message-ID: <20130908230505.CB0E16266E@hg.openjdk.java.net> Changeset: 9222246db895 Author: Felipe Heidrich Date: 2013-09-08 15:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9222246db895 RT-30741: Super Shader ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/RegionImageCache.java ! modules/graphics/src/main/java/com/sun/prism/ResourceFactory.java ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DContext.java ! modules/graphics/src/main/java/com/sun/prism/es2/ES2Context.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseContext.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseResourceFactory.java ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java ! modules/graphics/src/main/java/com/sun/prism/impl/VertexBuffer.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderContext.java ! modules/graphics/src/main/jsl-prism/CompileJSL.java + modules/graphics/src/main/jsl-prism/PaintMaskTextureSuper.jsl ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/TestGraphics.java From hang.vo at oracle.com Mon Sep 9 01:32:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Sep 2013 08:32:50 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31076 WebEngine.print() gets margins incorrectly Message-ID: <20130909083326.28BB662679@hg.openjdk.java.net> Changeset: 512ddab21ba0 Author: peterz Date: 2013-09-09 12:22 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/512ddab21ba0 RT-31076 WebEngine.print() gets margins incorrectly ! modules/web/src/main/java/com/sun/webkit/WebPage.java ! modules/web/src/main/java/javafx/scene/web/WebEngine.java ! modules/web/src/main/native/Source/WebCore/platform/java/WebPage.cpp ! modules/web/src/main/native/Source/WebCore/platform/java/WebPage.h From ozemale at ozemail.com.au Mon Sep 9 03:30:42 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Mon, 9 Sep 2013 20:30:42 +1000 Subject: Media classes still missing from JavaDoc Message-ID: <006a01cead47$a3bc8f50$eb35adf0$@ozemail.com.au> Just FYI, media classes are still missing from the JavaDoc for JavaFX in JDK 8 b105. -jct From hang.vo at oracle.com Mon Sep 9 06:32:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Sep 2013 13:32:58 +0000 Subject: hg: openjfx/8/controls/rt: RT-32714 : Modena.jar java.lang.NullPointerException to select colors Message-ID: <20130909133401.F08CF62680@hg.openjdk.java.net> Changeset: 554ecdb56a76 Author: mickf Date: 2013-09-09 14:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/554ecdb56a76 RT-32714 : Modena.jar java.lang.NullPointerException to select colors ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java From richard.bair at oracle.com Mon Sep 9 07:19:31 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 9 Sep 2013 07:19:31 -0700 Subject: [API Review] : Baseline offset depends on layout bounds which are calculated during layout In-Reply-To: <5226BBF8.9000904@oracle.com> References: <5225DFFB.5000601@oracle.com> <1A52967E-6C24-4CD6-BB1C-AC2382838402@oracle.com> <52263A75.3010702@oracle.com> <3F6A504A-FF0E-4E8F-A1B9-406958C19989@oracle.com> <5226BBF8.9000904@oracle.com> Message-ID: Sorry we flew off the list accidentally. I like BASELINE_OFFSET_SAME_AS_HEIGHT. This change in behavior will potentially break other layout managers which are handling the baseline case. Specifically, we should test with MigLayout. Otherwise this seems like a significant improvement in that we can avoid multiple passes and also correct layout the first time around instead of having things in the wrong place the first time, only to be moved around the next pass. Richard On Sep 3, 2013, at 9:50 PM, Martin Sladecek wrote: > Maybe the USE_COMPUTED_BASELINE_OFFSET should be rather BASELINE_OFFSET_SAME_AS_HEIGHT. > It's up to the layout container to compute the baseline of such Node, as the layout container must compute the height as well. > Currently, the layoutBounds height is returned, but this is incorrect, as the layoutBounds contain the old width&height and will be updated during the layout. > > So it actually means, for the baseline of this Node, use it's newly computed height. > > -Martin > > On 09/03/2013 09:45 PM, Richard Bair wrote: >> I must be missing something. I thought the getBaselineOffset method was the means by which that was done? Meaning, if I'm a layout container, then I would call getBaselineOffset to get this value. Now, I call it and it tells me USE_COMPUTED_BASELINE_OFFSET, so how do I compute it? Or do you mean, if somebody gets USE_COMPUTED_BASELINE_OFFSET, then it really means, use the layoutBounds height? >> >> Richard >> >> On Sep 3, 2013, at 12:37 PM, Martin Sladecek wrote: >> >>> The layout container will need to compute the baseline for Nodes with USE_COMPUTED_BASELINE_OFFSET, because it's the layout container who needs to compute the child's height (which is equal to it's baseline). I've prepared the code of all the layout Panes so that the baseline is computed after the heights and the heights are computed with respect to the baseline. There are many package-private helper methods in Region that I've updated and used in our layout Panes, so it's a matter of a few calls for us, but 3rd party layouts will have to compute this by themselves (as they aways had). >>> >>> -Martin >>> >>> On 09/03/2013 05:56 PM, Richard Bair wrote: >>>> So how does the layout container ask for the computed baseline offset? It used to be, by calling this method. >>>> >>>> Richard >>>> >>>> On Sep 3, 2013, at 6:11 AM, Martin Sladecek wrote: >>>> >>>>> Hi, >>>>> related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31006 >>>>> >>>>> I propose to add constant "public static final double USE_COMPUTED_BASELINE_OFFSET" to Node class. >>>>> >>>>> This would be returned by the default Node implementation of getBaselineOffset. Currently, the layout bounds are returned, but they are not computed at the time getBaselineOffset is called, which leads to incorrect layout and other problems (see more in description of the issue). >>>>> >>>>> Thanks, >>>>> -Martin > From hang.vo at oracle.com Mon Sep 9 07:32:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Sep 2013 14:32:57 +0000 Subject: hg: openjfx/8/graphics/rt: ios: WebView - making javacall