[Qt-interest] Qt Charting Component - Feedback Request

[Sean Harmer]

Hi,

On Saturday 05 March 2011 15:33:01 K. Frank wrote:
> On Sat, Mar 5, 2011 at 3:47 AM, Sean Harmer
> 
> <sean.harmer at maps-technology.com> wrote:
> >> I have a very strong interest in this kind of charting capability.
> > 
> > OK that's good. I just wanted to make sure I am not wasting my time.
> 
> Not at all.  More power to you.

;-)

> Let me share with you some of my thoughts.

OK. Extra inputs are always welcomed.

> I've used a lot of different charting packages over the years (dating
> back to "character-cell" charting packages, where you'd print out
> the charts on an old-fashioned line printer)  When charting libraries
> haven't been available to link into my applications, I've used things
> like S-Plus and Excel as charting engines to which I would export
> the prepared data.  (Almost more trouble than it's worth, but if you
> need the charts...)

Yes I have had to do this in the past too.

> My first suggestion (at the risk of suggesting something that's a
> lot of work) is to make the charting package very full-featured.

That is the aim (despite the work).

> Data to be displayed graphically comes in a lot of different shapes
> and sizes, and a lot of different features are needed to display it
> effectively.

Agreed. Interfacing with the data is one of the most challenging parts.

> A simple x-y plot -- how complicated could that be?  But then, do
> you want to support multiple vertical axes with different scales?
> Do you want to support labels for data points?  If the data points
> are somewhat crowded, do you want to provide a built-in algorithm
> for positioning the labels so it's clear which label labels which point,
> but so that the labels don't bump into or overlap one another or
> the points they're labelling?  And on and on...

Again, I agree totally. These features are all on the list to implement. I'll 
try to put up a wiki page somewhere so that people can add feature requests.

NB I already have support for an arbitrary number of coordinate systems within 
each plot area although the support is a little broken right now since I am 
refactoring that feature. Hopefully it will be back up and working again soon.

As for the label placement algorithms, I have had a cursory look into these 
but have not selected one as yet. It appears that it can be an expensive 
operation though so is a candidate for something to be put into a worker 
thread which signals the gui with updated label positions when ready.

> Personally, I would much rather use a clunkier, less efficient, less
> easy to use package that does a lot of the things I'm likely to want
> than a "better," slicker package that is more likely not to have some
> feature I end up needing.

OK noted. I am however hoping that the two need not be mutually exclusive. By 
providing a choice of plot elements I am hoping to cater to both feature and 
performance requirements.

As an example, in an xy-scatter plot, having each data point plotted as its 
own QGraphicsItem makes the plot very customisable as you can easily alter the 
colour, scale, rotation etc of each point but the performance will of course 
not be optimal. 

On the flip side, if you need a high-performance xy-scatter plot, for real-
time data say, then having a single QGraphicsItem for the entire data series 
that paints all points in a single pass will be more performance but will make 
it more difficult to customise individual points.

> One particular pet peeve:  Sometimes I like to be able to specify a
> particular aspect ratio (e.g., one-to-one) for an x-y plot, and have
> that aspect ratio accurately maintained, both on the screen and
> when printed, and still be able to use auto-scaling.

Agreed. This is nice to have. I have abstracted the transformations involved 
in plotting charts into a ZCartesianCoordinateSystem class. This has support 
for maintaining aspect ratios and I think it does what you require here. I 
need to make an example demonstrating this though.

> > I also wanted to try and
> > provide an interface that requires less of the user so that it is
> > quicker to get simple plots/charts up and running very quickly - I
> > think I have it down to 3 or 4 lines of code now - but still make it
> > relatively simple to customise charts without a lot of sub-classing.
> 
> This is a very good goal.  I've used some charting packages where
> you have to do everything by hand -- a steep learning curve, and a lot
> of work.  But even more frustrating are the many packages I've used
> that offer a simple standard chart -- a bunch of defaults pre-set -- but
> if you want to change anything, you get bumped out of default mode
> and have specify a whole lot of things manually.  (Think of a class, not
> necessarily a class for charting, that offers exactly two constructors:
> one that takes no arguments, and one that takes fifty arguments.)
> 
> I'm just thinking out loud here, but maybe a two-fold approach could
> work well.  First, some kind of scheme where you can customize
> your charts piecemeal, and change one characteristic, without the
> need to specify (and learn about) all the other characteristics.  And
> second, have several different pre-defined charting styles available,
> so the user can pick one that close to what he needs, and then make
> a small number of customizations to meet his specific requirements.

Agreed and I hope this is what I (almost) have. I am also planning a 3rd 
approach which will allow even greater customisation. The extra approach I am 
thinking of is to have all customisable components created by factory objects 
which can be replaced by user-defined factories. This is just like Qt has for 
the itemview delegates of course.

If done correctly it should allow for things such as custom graphics items 
used as points in xy-scatter plots that animate upon a hover events for 
example. This is still in planning at the moment though.

> (Think of the pre-defined charts as airports:  You fly into a nearby
> airport, and then take a car to your final destination.  It doesn't
> make sense to have an airport on every street corner, but having
> just one giant "U.S. International Airport" in the middle of Kansas
> and driving everywhere else from there doesn't work either.  That's
> what some charting packages make me feel like I'm doing.)
> 
> Obviously, if your user wants to do something atypical and complicated,
> then it's fair to expect him to do some work.  But if you can achieve
> the goal that simple, standard things are done simply (from the user's
> perspective), you'll have a real winner.

That would nice indeed :D

> > I am also trying to build in direct
> > support for animation of chart elements.
> 
> Animation, and (as you mentioned later in this thread) 3D would be
> really cool.

OK. Those managers really love their pseudo-3D don't they? :D

> >> Would it make sense to try to coordinate with qwt?
> > 
> > Probably not at this stage given the totally different architectures.
> 
> Yeah, that sounds right, although it's too bad to see the duplication
> of effort.

Think of it more as healthy competition. Having a greater choice of tools 
won't be a bad thing and may drive some more innovation.

> Coming back the full-featured theme (and the "a lot of work" theme)
> you should do a survey of the capabilities that qwt offers.  I'm not
> suggesting that you should provide everything that qwt does, but
> certainly features of qwt that strike you as sensible and useful should
> be on your list of "features for consideration" for inclusion in your
> package.
> 
> Other sources of inspiration for possible charting features could be
> Excel, Mathematica, Matlab, and S-Plus / R.  (Just a thought...)

Yup, those are already on my list in addition to other charting packages such 
as Dundas Chart (now part of .Net framework).

There is no way I can possibly reach feature parity with some of the mature 
packages for the first release. I do however hope to provide a framework on 
which to build additional features as time goes on. For example, an interface 
to QtScript and QML are on the list. It is already possible to plot functions 
defined in QtScript (normal and parametric functions so far but it is simple 
to extend it to other function types).

> > Cheers. I'll keep plugging way at it. :D
> 
> Personally, if you can give me half-decent looking basic 2D line
> and scatter plots with multiple data series (similar to what qwt
> provides) and bar charts (which I don't think you get out-of-the-box
> from qwt), I'll offer myself up as a guinea pig with an exploratory
> project I'm working on.

Many thanks for the offer. I have not implemented bar charts yet but 2D line 
and scatter plots are certainly usable right now. Let me know if you wish to 
try it out as a guinea pig and I'll see what I can do. It will push me into 
implementing the bar/column charts feature ;-)

> Thanks, and again, good luck.

Cheers, I think I will need it.

ATB,

Sean