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<Date>". 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: [email protected] To: [email protected] Date: 02.09.2013 08:18 Subject: openjfx-dev Digest, Vol 22, Issue 2 Sent by: [email protected] Send openjfx-dev mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 ([email protected]) 8. Re: DateAxis.. (Sven Reimers) ---------------------------------------------------------------------- Message: 1 Date: Mon, 02 Sep 2013 08:44:44 +1200 From: Jonathan Giles <[email protected]> Subject: Re: FocusModel too restricted? To: [email protected] Message-ID: <[email protected]> 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 <[email protected]> Subject: Why is almost everything in the API final To: OpenJFX Mailing List <[email protected]> Message-ID: <CAAEud6aOYANarA1Zc1ps3EE01=SMNVwACV=6gw+elas9mw-...@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 <[email protected]> Subject: DateAxis.. To: OpenJFX Mailing List <[email protected]> Message-ID: <caaeud6y5cvk0pscer46czsf9kdxjhoik4bgxlk0mqhbfmbn...@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 <[email protected]> Subject: Creating custom chart - "XYBarChart" To: OpenJFX Mailing List <[email protected]> Message-ID: <CAAEud6b=nhq61+aaejdgvjc-b_oruydh0u6+zumlko5h4k5...@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 <[email protected]> Subject: Re: Why is almost everything in the API final To: [email protected] Message-ID: <[email protected]> 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 <[email protected]> Subject: Re: DateAxis.. To: [email protected] Message-ID: <[email protected]> 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: [email protected] Subject: hg: openjfx/8/controls/rt: 4 new changesets To: [email protected] Message-ID: <[email protected]> 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 <[email protected]> Subject: Re: DateAxis.. To: "[email protected]" <[email protected]> Cc: openjfx mailing list <[email protected]> Message-ID: <cap+jvx60qsnfqxe79mgzlovtmwscdyvusbqakkjn7qoqwng...@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 <[email protected]>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.
