DateAxis..
Diego Cirujano-Cuesta
diego.cirujano-cuesta at zeiss.com
Mon Sep 2 01:21:16 PDT 2013
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: 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.
More information about the openjfx-dev
mailing list