[Qt-interest] Qt Charting Component - Feedback Request
K. Frank
kfrank29.c at gmail.com
Sat Mar 5 21:33:01 CET 2011
Hi Sean!
On Sat, Mar 5, 2011 at 3:47 AM, Sean Harmer
<sean.harmer at maps-technology.com> wrote:
> Hi K Frank!
> ...
>> 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.
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...)
My first suggestion (at the risk of suggesting something that's a
lot of work) is to make the charting package very full-featured.
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.
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...
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.
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.
> ...
> 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.
(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.
> 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.
> ...
>> 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.
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...)
> ...
> 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.
> ATB,
>
> Sean
Thanks, and again, good luck.
K. Frank
More information about the Qt-interest-old
mailing list