DateAxis..
Pedro Duque Vieira
pedro.duquevieira at gmail.com
Tue Sep 3 07:47:20 PDT 2013
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<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: 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 <jonathan.giles at oracle.com>
> 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 <pedro.duquevieira at gmail.com>
> Subject: Why is almost everything in the API final
>
> To: OpenJFX Mailing List <openjfx-dev at openjdk.java.net>
> Message-ID:
> <CAAEud6aOYANarA1Zc1ps3EE01=SMNVwACV=
> 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 <pedro.duquevieira at gmail.com>
> Subject: DateAxis..
> To: OpenJFX Mailing List <openjfx-dev at openjdk.java.net>
> 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 <pedro.duquevieira at gmail.com>
> Subject: Creating custom chart - "XYBarChart"
>
> To: OpenJFX Mailing List <openjfx-dev at openjdk.java.net>
> Message-ID:
> <CAAEud6b=
> 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 <jonathan.giles at oracle.com>
> 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 <jonathan.giles at oracle.com>
> 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 <sven.reimers at gmail.com>
> Subject: Re: DateAxis..
> To: "jonathan.giles at oracle.com" <jonathan.giles at oracle.com>
> Cc: openjfx mailing list <openjfx-dev at openjdk.java.net>
> 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 <jonathan.giles at oracle.com
> >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
More information about the openjfx-dev
mailing list