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 < [email protected]> 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<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= > [email protected]> > 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= > [email protected]> > 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. > > -- Pedro Duque Vieira
