Charts: Was The Next Great Thing: An Application Framework

[Tom Eugelink]

To add my €0.02 on the chart topic; Dan here does hit the nail on the head. I started an email yesterday trying to explain exactly this, but I did not succeed (may have something to do with this fever thing I've got going on), so I'm gladly stealing Dan's points here. To me it most definitely is something of a higher abstraction level than controls. I can understand Richard's point of view though, but then a lot of stuff (like Dan's examples) are at the same level. Why only charts?

Naturally this is of absolutely no practical consequence, because it is great that JFX has charts, no discussion there. But it may be interesting in light of how end-users look at charts and indeed on how OpenJFX is organized into modules or separate projects.

Tom


On 2012-02-12 07:38, Daniel Zwolenski wrote:
> Hi Richard,
>
> It's not that I don't like having charts available when I want them and
> although I haven't looked at them in depth yet, it looks like it is a very
> powerful toolkit. It's just that I feel only a sub-set of applications
> (specifically business/data apps) will actually use charts, whereas things
> like buttons, labels, textfields are fairly ubiquitous building blocks for
> everything. Charts feel more like a higher-level feature to me, on par with
> things like 'mapping', file editing, PDF browsing, a 'game engine', or a
> statistics package, etc.
>
> It is definitely possible that I may not fully understand the chart API as
> yet though and my comments may be premature. I haven't had call to use them
> yet in my applications, perhaps when I do I will change my viewpoint. With
> that caveat in mind, the main drawbacks I see to charts being in the core
> platform are these:
>
> 1. Resourcing - I have a gut feel that building/maintaining something like
> this was and will be something of a hassle that will draw all-important
> JavaFX resources away from more fundamental features. The community would
> probably pick charts up if it was left out, so it feels like Oracle is
> blowing 'coin' I'd rather see spent on stuff that can't (easily) be done by
> the community because it is more 'core' (like video playback, true 3D
> support, mobile phone support, etc).  If Oracle's got resources to burn on
> this then this is not such an issue, but I'd personally rather get a media
> capture API, or a mobile version in there over charts, because charts I can
> build myself, whereas media capture and/or mobile requires nasty native
> libraries and weird non-java magic.
>
> 2. Bloat - it's good to keep the base platform as small and light as
> possible so when we look at supporting platforms (like mobile, set top
> boxes, etc) we only have to move the core features on to these and not be
> moving a massive codebase across (and also downloading a massive jar). It's
> easier to keep the platform stable too, less code means less bugs. If we
> didn't have charts when we go 'mobile' then the move would be easier (i.e.
> catering for touch screens, smaller screens, etc). Modularisation may help
> with this, but I think the additional code in the core platform will still
> result in more work.
>
> 3. Change management - my gut feel is something like charts will have a
> more rapid change/fix cycle than the core platform. I don't particularly
> want my end user to have to download a new JFX RT every other week
> (especially if there are more annoying popups) because there has been a fix
> in the way 'ticks' are rendered on a chart if I'm not using charts (whereas
> HBox probably isn't going to change too often). Again maybe modularisation
> will help with this, but it is still a way off and the deployment battle
> may well be fought and lost before Java8 gets on it's horse and makes a
> charge.
>
> As per my previous email, all of the above is not to say I wouldn't love to
> see a separate ChartsFX library published by Oracle that had the exact
> features in the core jfx charts module at the moment (deployed into Maven
> would be even better :) ).
>
> As always, I'm definitely not putting down any of the effort put in by the
> JFX team. I'm an unashamed platform zealot and a fan. JFX is the
> development environment I've been dreaming about for years and I love it.
> I'm more concerned about providing (hopefully) constructive feedback on
> making it better and making sure the platform is sustainable so it can
> become the standard and every new job I look at uses it. As we get stuck
> into nutting out features and working through problems, it's easy to forget
> to say it, so for the record: very nice work guys.
>
> Cheers,
> Dan
>
>
>
> On Sat, Feb 11, 2012 at 6:49 AM, Sven Reimers<sven.reimers at gmail.com>wrote:
>
>> There are some ideas sitzung in Jira that would be good for msking Charts
>> even more successful, e.g. logarithmic axis and multiple y-axis..
>>
>> Hope OpenJFX will be the place to make those things happen.
>>
>> Sven
>> Am 10.02.2012 19:39 schrieb "Richard Bair"<richard.bair at oracle.com>:
>>
>>
>>>> - Charts: seems like an add-on that will become something of a hassle
>>> for the JFX team to maintain, grow, support at the rate it will need, as
>>> well as adding complexity for mobile platforms (should a pie chart look the
>>> same on a mobile app with touch screen, no mouse over, etc).
>>>
>>> Different topic, but I thought this comment was interesting. Why are
>>> charts any different than controls? We see them as the same thing really.
>>> Charts are extensible -- folks can add new charts, or use the built in
>>> ones, exactly like controls. Both are intended to be drop-in use for
>>> applications. Charts are actually much more powerful than we've gotten
>>> credit for so far (I suspect this is because nobody has dug into them
>>> deeply and we've not documented a lot of the capabilities on fxexperience
>>> or javafx.com yet).
>>>
>>> Richard
>>