Qt Charting Component - Feedback request



  • [quote author="ZapB" date="1299499026"][quote author="Andre" date="1299497646"]
    No, sorry, I think I have not made myself clear. I was more thinking about visualizations like the one used in "this presentation":http://www.youtube.com/watch?v=pLqjQ55tz-U&feature=player_embedded (from 45 seconds onwards) or even in a hierarchical form as used for things like visualizing hard disk space used, such as in "this application":http://lifehacker.com/#!219058/geek-to-live--visualize-your-hard-drive-usage.
    [/quote]

    Ah yes I know what you mean now. I am not sure of the technical name for this type of visualisation either. I have not yet implemented this. I'll have to have a think about this one because as you say it uses a potentially hierarchical data source.
    [/quote]
    Well, it would already be useful in a non-hierarchical version, as you can see in the movie. But yes, hierarchy would add to the data-richness, especially if you can navigate through it.

    [quote]
    [quote author="Andre" date="1299497646"]
    How does this relate to the ZAbstractVariableMapper class you described above? Wouldn't it make more sense to query that class for a suitable color, or do I misunderstand what you are doing here?
    [/quote]

    They are not related. This is where I have diverged from the QModelView pattern. I have never been particularly comfortable with having to provide properties that affect the appearance of the views in the data model for QModelView. IMHO the view properties should be set independently from the actual data.

    My approach also allows the user to specify a functional form for the colour/scale/other property whereas in QModelView each property has its own role that must be queried from the model.

    I suppose I could allow the view to check if the data set provides a value for that property for each point and use that if it does. Then, if the data set does not provide the needed property value it can fall back to the functional form. Hmmm, this would impact performance though. I wonder if I can make it a noop in the common case? I'll take a look.
    [/quote][/quote]
    Hmmm, I think I agree on principle that separating presentation and data is a good thing, and that the way these two interfere in the Qt model/view design is less than ideal. I like being able to provide a function for a property, that is pretty neat actually. But it does not make sense in all cases. What you might do, is create a set of standard functions that do nothing more than retrieve the value in question from the model directly? And just set another function to use if you want that? Again, with a bit of template magic, I think it need not even impact runtime performance.



  • Hi again,
    [quote author="Andre" date="1299499404"]
    I don't really understand you design yet, I am sorry. I don't quite see the relationship between ZAbstractVariableMapper and ZAbstractDataSet. I am right that variable from virtual ZAbstractDataSet::QVariant data( int index, const QString& variable ) const plays the role that role does in QAbstractItemModel::data(QModelIndex& index, int role = Qt::DisplayRole) const;?
    [/quote]

    Yes that is correct.

    [quote author="Andre" date="1299499404"]
    If so, what then is the place of the ZAbstractVariableMapper?
    [/quote]

    Ah OK. ZAbstractVariableMapper is a way for me to provide something akin to the body of the data() function from QAIM for the common cases and to allow users to easily provide a similar body without having to subclass ZAbstractDataSet for themselves.

    I appreciate that the need here may not be immediately obvious. I will try to explain a little more. Imagine that the user wishes to plot an xy scatter plot of some data they have calculated. Their calculation routines provide data in the form of My2dPoint objects say. Now, my charting component obviously has no knowledge of this type whatsoever.

    "OK", you say, "I can subclass ZAbstractDataType and reimplement all the pure virtual functions". This is correct but then you have to reimplement all of the other logic too such as inseting/removing data, remembering to emit signals or call base class functions when appropriate.

    By simply providing a customised sub-class of ZAbstractVariableMapper and registering it, you can get what you need much easier. In this case you can then just use the concrete ZDataSet which provides all the nitty-gritty book-keeping and signal emission code. This effectively removes a lot of the headaches of reimplementing QAIM to get read-write models up and running. The common stuff is done once in ZDataSet and the variable mappers provide an abstraction for the part that varies from user to user.

    As a bonus the variable mapper will also work with the ZModelDataSet if you already happen to have a QAIM that exposes the data. It will also work with the circular buffer based dataset when I get that finished too.

    I suppose there are alternative ways of doing this too. For example, ZDataSet is based upon a QVector of data points and I have mentioned the upcoming circular buffer one. I could maybe abstract these away using template policy classes. I have some more experimentation to do yet.

    Having said all that, I do not expect most people to have to any of this. In the common case you can simply use ZDataSet or another concrete class.

    [quote author="Andre" date="1299499404"]
    A move to an enum would be wise, I think. You can define a set of standard "roles" (like is done for QAIM) and extend it as needed.
    [/quote]

    Yes I will do this very soon. Not enough hands/brains ;-)

    [quote author="Andre" date="1299499404"]
    Also unclear for me is the ZAbstractDataSet::boundingBox() method. What exactly is returned there, especially in conjunction with the ZAbstractVariableMapper? A bounding rect makes sense conceptually for graphs like a vector field or a scatter plot, but what is a bounding rect for a simple one dimensional series you plan to draw in a bar or pie chart?
    [/quote]

    This is true. It could be made clearer. As you guessed it is used to determine what x/y limits should be placed on the axes when auto-scaling is enabled. For pie charts and other similar things I adopt a coordinate system of -1 to 1 in the shortest axis with a unity aspect ratio. In this case the plot elements do not call boundingRect() at all and so a stubbed implementation can be used. Once again though simply using the provided ZDataSet will do the right thing (tm) :D

    [quote author="Andre" date="1299499404"]
    Last (for now ;-) ) idea that popped up in my head, is that you might be able to optimize your ZAbstractVariableMapper if you resort to use templates here. For a graph type, you just need to be sure that the mapper class implements the interface required for that graph type, but you would not need the additional virtual method call and the conversions to and from QVariant. But perhaps I totally misunderstand the purpose of this class, so I may be off the mark here. [/quote]

    Yes I have wondered about using templates here too. I have just not gotten around to trying it yet.

    Thank you again for your comments. They are very useful food for thought and I will try out these ideas.



  • [quote author="Andre" date="1299500755"]
    Well, it would already be useful in a non-hierarchical version, as you can see in the movie. But yes, hierarchy would add to the data-richness, especially if you can navigate through it.
    [/quote]

    True. I would like to solve it in general and then simplify. It is often harder to implement the simple case and then generalise it in a clean way without breaking existing code. I am open to ideas if you have any for this. ;-)

    [quote author="Andre" date="1299500755"]
    Hmmm, I think I agree on principle that separating presentation and data is a good thing, and that the way these two interfere in the Qt model/view design is less than ideal. I like being able to provide a function for a property, that is pretty neat actually. But it does not make sense in all cases. What you might do, is create a set of standard functions that do nothing more than retrieve the value in question from the model directly? And just set another function to use if you want that? Again, with a bit of template magic, I think it need not even impact runtime performance.
    [/quote]

    I do provide default implementations. For example, with the bubble plots the default colour function implementation just returns an invalid QColor. This means that the colour function does not override the default behaviour which is for the data series to be given a colour based upon the data series number. The colour for the i'th data series is provided by the style/theme. Similarly for the bubble-point shape. I do like the idea of being able to potentially override this in the data set though.

    In my default theme the series colours are just taken from a selection of the colours in the KDE Oxygen colour palette. I intend to ship more themes/styles with the official release. I'll be after some artistic inspiration a bit later :-)



  • Hi there!

    I think you are doing a great job. I'm really interested in such a library, and would be very happy to try it out.

    One particular feature I'm very interested in is plotting of streams of data (such as scrolling curves and scrolling images).

    You have any plans for this sort of stuff? What kind of API would it have?

    cheers and best luck on your project!
    ricard



  • [quote author="rikrd" date="1301938309"]Hi there!
    I think you are doing a great job. I'm really interested in such a library, and would be very happy to try it out.
    [/quote]

    Thank you.

    [quote author="rikrd" date="1301938309"]
    One particular feature I'm very interested in is plotting of streams of data (such as scrolling curves and scrolling images).

    You have any plans for this sort of stuff? What kind of API would it have?
    [/quote]

    Do you mean like plotting time series of real-time data? If so then yes, this will be supported. The API will be similar to that used in the Qt ModelView framework. The data set that you are plotting will emit (either manually in a custom sub-class or by calling the append() function of one of the provided convenience classes) an internal signal that is connected to the data series (the graphical representation). The data series then makes the necessary adjustments to take the new data into account and triggers an update. I'll try to make a simple example and post it.

    What sort of data do you want to plot as a scrolling image?



  • bq. Do you mean like plotting time series of real-time data? If so then yes, this will be supported.

    Yes, that was what I was looking for.

    bq. The API will be similar to that used in the Qt ModelView framework. The data set that you are plotting will emit (either manually in a custom sub-class or by calling the append() function of one of the provided convenience classes) an internal signal that is connected to the data series (the graphical representation).

    This sounds simple and nice. I like the idea of having a similar API as Qt's ModelView framework. Looking forward to trying it and seeing how it performs.

    bq. What sort of data do you want to plot as a scrolling image?

    I was thinking of spectrogram-like data. Let's say you want to show a spectrogram of an audio stream scrolling while it is playing.

    Another visualization I would be interested in, is a plot that that changes entirely very frequently. Such as the instantaneous spectrum of an audio stream. But I can imagine the API, if it will be similar to the ModelView framework.

    If I didn't explained myself well, checkout the "SonicVisualiser":http://www.sonicvisualiser.org/ for the sort of plots I am interested in.

    Finally my last question is if you plan to publish your library under some Free software license?



  • Yes that is what I thought you meant but thought I should check. I will try to add in support for that type of plot but I am not sure if it will make it into version 1.

    As for the license I am planning to release it under a commercial license plus one or more FOSS licenses. I just wish I had more time to work on it but I am very busy at work at the moment.



  • Just a quick note to report a little bit of progress. I now have this charting component working under the Qt Simulator target. Next step is to get it working on a real Symbian device. Here's a "screenshot":http://gallery.theharmers.co.uk/picture.php?/165/category/5 showing a simple example running under the simulator.



  • Looking really good! Can't wait to get my hands on this.



  • hi,

    really nice plots !

    Do you use QGraphicsPathItems for the "line" plots?
    And the points symbols?

    the look and feel seems to be really well defined, yes I'd like to play with !

    great project,

    Michel



  • [quote author="Michel Pacilli" date="1307918063"]hi,
    really nice plots !
    [/quote]

    Thank you.

    [quote author="Michel Pacilli" date="1307918063"]
    Do you use QGraphicsPathItems for the "line" plots?
    And the points symbols?
    [/quote]

    Almost. I have written my own custom QGraphicsItem subclasses. In this case the lines are drawn by a ZSplinePathItem and the points are drawn by ZPointItem. Both these classes inherit from another class of mine called ZTransformedPlotItem which allows the subclasses to easily perform transformations between the natural plot coordinate system and the usual QGraphicsView parent item coordinate system. The idea being that by replacing the coordinate system in use you can change the plot type ie switch to a polar coordinate system.

    The ZSplinePathItem uses a QPainterPath internally.

    [quote author="Michel Pacilli" date="1307918063"]
    the look and feel seems to be really well defined, yes I'd like to play with !

    great project,

    Michel[/quote]

    Thank you again. I have a little more work left to do before I will make a first release but I am slowly getting there. Things left to do include:

    • Contour plots (these are almost done)
    • Bar/column charts
    • More style abstractions for easier customisation
    • Peformance optimisations
    • Lots more testing ;-)

    I'll post back here as I make progress.



  • Woohoo! I've just managed to get the basic plot example (shown above running in the simulator) to run natively on Symbian^3. This feels like a major step for me and it shows that we can now relatively easily create applications containing charts on desktop, embedded and mobile targets. :D

    The only changes I made compared to the same example built for desktop was to make the font size a little smaller to make better use of the available space and to call QWidget::showFullScreen() rather than QWidget::show() on the QGraphicsView. I'll try to factor the font size adjustments into the library. The choice between show() and showFullScreen() is down to the application writer.



  • Looks amazing can't wait to try it out :)



  • Thanks Zester. Not too long now hopefully.



  • "This question":http://developer.qt.nokia.com/forums/viewthread/6950/ was split off as a separate topic.



  • Can't wait to give it a try! Great work.
    Any idea when we shall have the chance to play with it?



  • Thx rafy. A few months I expect. I am working on the last couple of features for version 1.0 then I need to do lots of code tidy up and bug fixing ;-) As always my time is limited though.



  • Great work, Sean, i do really like your Charting Component :D



  • I now have the basics of contour plots working too. At the moment it just uses the Henry Ford colour scheme though so still work to do on making them look blingtastic ;-)



  • Hey Sean,

    Impressive work!

    Charttypes that I miss in your list are the financial stock charts like bar charts (open, high, low, close) and candlestick charts. I know that many developers are looking for something like that. I am using qwt for that purpose but it does not support these types either.

    It would be great to have these as well.

    Kind regards,
    Eric



  • Hi Eric, I have financial stock charts on my todo list but probably not for version 1.0. The good news is they should be very simple to add in.



  • Ok good. Can't wait for your first release.



  • Sean,

    Bump.

    How can I use your widget from within QML?
    Can I draw xy science plots using data from a C++ class (say a std::vector) ?
    In my app, the data may arrive any time, so how can I notify the plot widget to draw the new data?
    Is there an example ?

    Thank you for the great work. It seems what a lot of people have been waiting for!



  • How is it going on with version 1.0? Can't wait to play with it.
    Raph



  • Hey Guys,

    sorry for the delays on this. I'm in the middle of changing jobs and things are very hectic still at my existing job. I hope to get version 1.0 out very soon now.

    Victor: I am playing around with an idea on how to integrate this into QML 1. As for QML 2 I am not sure what is the best route to go down as yet so that requires some more experimentation.



  • Just wondering... will this project clash with the product portfolio of your new employer?



  • Potentially yes. Something to be resolved...



  • Thanks for the update.

    If you need a guinea pig I would enjoy helping. QML2 is fine.

    BTW, Good Luck with your new position! I know how crazy that can be.



  • Are you still working on the project?
    I hope so!



  • Anything new on this?
    I'm really keen on playing with it.



  • +1

    Best regards



  • Sean,

    This looks impressive. I've been toying with idea of adding graphing to my code and my main choice was QWT. I'd love to give this API a shot. By the way, I'm interested in plotting real-time data so the performance aspect would be important. Do you have a time-frame for when this might be available?

    Thanks

    BmanC



  • Hi Sean,

    I'm guessing you're not going to publish your component anymore?

    Just let us know to put us out of our misery, as a component like this would save me A LOT of time on a personal project I'm currently working on



  • Hi,

    I am still trying to sort out some things with my employer here. I have not forgotten about this but I have been super busy lately. Please bear with me for a little while.



  • Hi,
    where can i download the ZTPlot library? i'm quite interested to use it inside my own project

    thanks
    F.



  • [quote author="Cuke" date="1332835709"]Hi,
    where can i download the ZTPlot library? i'm quite interested to use it inside my own project

    thanks
    F.[/quote]
    At this moment, you can't yet. Sorry!



  • This is just what I'm looking for. Can I get a status update? Can ZTPlot do slide plots? Thank you.



  • Hello,

    Thank you for the post would be interested too by.

    Skylar



  • Hello,
    I'm also interested on this project. I hope you will be able to publish at some point.



  • Would love to play with this library too.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.