How to scroll a QChart as realtime data come in

[mustermann.klaus@gmx.de]

Hallo,

I am running a timeline-like QChart. To follow the graph as data come in I continuously call a slot to dateTimeAxis->setMin and ->setMax.

// create chart
timeLine = new QChart();
 
// manage X-axis
dateTimeAxis = new QDateTimeAxis;
dateTimeAxis->setTickCount(9);
dateTimeAxis->setFormat("hh:mm");
dateTimeAxis->setMin(currentTime.addSecs(-rangeAxisX / 2));
dateTimeAxis->setMax(currentTime.addSecs( rangeAxisX / 2));
 
chartView = new QChartView(timeLine);
 
connect(&timer, SIGNAL(timeout()), this, SLOT(updateChart()));
 
void MainWindow::updateChart(){
 
     // get current time
     currentTime = QDateTime::currentDateTime();
 
     dateTimeAxis->setMin(currentTime.addSecs(-rangeAxisX / 2));
     dateTimeAxis->setMax(currentTime.addSecs( rangeAxisX / 2));
}

// create chart
timeLine = new QChart();

// manage X-axis
dateTimeAxis = new QDateTimeAxis;
dateTimeAxis->setTickCount(9);
dateTimeAxis->setFormat("hh:mm");
dateTimeAxis->setMin(currentTime.addSecs(-rangeAxisX / 2));
dateTimeAxis->setMax(currentTime.addSecs( rangeAxisX / 2));

chartView = new QChartView(timeLine);

connect(&timer, SIGNAL(timeout()), this, SLOT(updateChart()));

void MainWindow::updateChart(){

     // get current time
     currentTime = QDateTime::currentDateTime();

     dateTimeAxis->setMin(currentTime.addSecs(-rangeAxisX / 2));
     dateTimeAxis->setMax(currentTime.addSecs( rangeAxisX / 2));
}

To copy to clipboard, switch view to plain text mode 

Problem: the grid does not move as one expect it to do on a timeline. Much more it remains static as the labels on the ticks change instead.

I would like to have a "moving grid" with ticks at every - lets say - five minutes.


<..|.....|.....|.....|...<
<-5---10--15---20-<


I tried a little bit around in the chartview-class and the scroll-thing. But it turned out, that (as far as my sorrier knowledge allows me to conclude) these things work in integers while my chart lives in qreal. So - this results in a quite rough user-experience.

Any idea welcome.

Thanks in advance, Lars

[mustermann.klaus@gmx.de]

In the meantime I thought the dynamic-spline-example would guide me, but it failed. I also found, that there is as well a scroll() for the QChart itself. But I really have no clue about what it does, since i can not, or at least I didn't find out how, zoom only in x-direction an then scroll along.
And what about the rubberband? Can I set the rubberband-coordinates hard coded? I am about to return to Qwt.

[d_stranz]

I am about to return to Qwt.

LOL. Welcome to the brain-dead world of QtCharts. As long as you never want to do anything more complicated than what they give you in the example programs, QtCharts is for you. If you want to, say, add a new series type, nope, can't do that. Want to use a Qt model as the source for the data rather than each series having a duplicate array? Nope, can't do that either. No virtual functions, no way to derive a new class, nada, zip. You get what comes out of the box, can't change anything.

From what I can tell of QChart and the QXYSeries, they don't communicate much with each other. Even though QXYSeries has a pointAdded() signal, it doesn't appear that the QChart listens for it. So once you initially set the series on the chart, that's it. AFAIK, the only way to implement real-time behavior is to remove the series from the chart, add the points to it, then add it back to the chart. And then you may have to adjust the x-axis yourself after doing that.

I can't see QtCharts changing in a way that makes it functional and allows customization. To do so would require a complete rewrite. I have looked into the internals when trying to implement my own series type (one which draws data from a model) and concluded that it was impossible without rewriting a major part of the code. Whoever designed and wrote it seems to have had a road map where every road ends at a brick wall.

I have philosophical differences with Uwe over how things were reimplemented in Qwt6, so I no longer use it. If you have been happy with it, by all means go back to it instead of continuing to struggle with QtCharts. I am looking at QCustomPlot, but using it will require me to buy a commercial license. My real desire is for a Qt-based 3D technical graphics package, but nothing like that seems to exist (Qwt3d is obsolete in its use of OpenGL), and Qt's own Qt3D has nothing in it that supports basic charting.


Good luck.

[mustermann.klaus@gmx.de]

Yeah, though I don't go so negative for it. Was a nice try. And - as you said - simple solution for simple tasks. I think you can append data to series and manipulate them via pointer and call some refresh-routine which behaves pretty much the same as the setRawData - killer-feature of qwt, doesn't it? Allright so far, but everything else really cost me a big deal of time just to find out it wont work. This non-functionallity certainly doesn't feel like what Qt is all about.

I remember a Qt-example (Qt-version 4.something) about how to implement a chart using Qt (I think it was QPainter-example). Promising at first glance. This times I did some real time plotting with high refresh-rates. I clearly remember me rejecting this approach due to the unflexability provided there. Am I wrong or that was QChart's grandma?

Thanks (as always) d_stranz.

Cheers, Lars

[d_stranz]

Yeah, though I don't go so negative for it.

Every time I want to do a new version of my product, I dip my toes back into the QtCharts water and end up getting them bitten by piranhas. It is disappointing that QtCharts is so unlike the rest of Qt, which is flexible, adaptable, derivable - everything that QtCharts is not. I don't know how such a library became part of the official Qt distribution.

I have written several charting widgets of my own, the latest of which uses the Graphics / View architecture along with axes and a few other things borrowed from Qwt5. It does what it needs to do for the application (including a setRawData()-like functionality implemented in the form of an abstract "DataAccessor" class hierarchy which can pull data from arrays, vectors, item models, whatever). The DataAccessor idea lets me very quickly build a chart that draws x, y, value triples from table models simply by defining a proxy that uses only three columns. The "value" part can be mapped to a color, marker shape, marker size, and so forth.

Unfortunately, my users want something a bit more "professional" looking so they can copy images directly for publication. So I need to find something that looks nicer than what I have done and supports more chart types and options. It would also be nice if it supported 3D...

[Uwe]

I have philosophical differences with Uwe over how things were reimplemented in Qwt6, ...

To be honest I can't remember having much related discussions with you. But as you have written similar statements several times it would be fair to elaborate what exactly you have problems with ?

Uwe

[d_stranz]

To be honest I can't remember having much related discussions with you. But as you have written similar statements several times it would be fair to elaborate what exactly you have problems with ?

It was a long time ago, back in the Qwt listserver days when you were first implementing Qwt 6.0, and it involved how arguments were being passed. In certain cases, the argument was a const pointer, but the instance on the receiving end took over control of the pointer's lifetime. The const-ness was what bothered me. You argued that this was simply telling the caller that the receiver would not change the state of the object's content, but my feeling was that if the receiver was eventually going to destroy the object you couldn't get more non-const than that. In the rest of Qt when an instance takes control of another's lifetime, such as the QObject hierarchy, the pointer is passed as non-const. It was a religious argument, mostly, and sort of silly as I look back on it but at the time it really bothered me. I am sorry for bringing it up.

I had many more problems with the big architectural changes that took place between Qwt5 and Qwt6, which would have involved rewriting major parts of my code to accommodate them. If I were starting fresh with new code, I would probably use Qwt6 now. In a way, since I am considering QCustomPlot and others you could say I am starting fresh, so I'll look at Qwt6 too. But none of what I can see does what I really want, which is a single library that will produce 2D and 3D plots of all sorts.

[Uwe]

It was a religious argument, mostly, and sort of silly as I look back on it ...

Try to step in my shoes for a moment:

someone starts a discussion about some detail - in your case about removing a const keyword - that has zero effect on application or library code. As the maintainer I have to respond - even if I don't even have much of an opinion about it. Finally the user does not like my answer, is frustrated and starts posting negative recommendations for the complete library.

I had many more problems with the big architectural changes that took place between Qwt5 and Qwt6, which would have involved rewriting major parts of my code to accommodate them.

But this is a totally different story, one about stable APIs.

Look at Qt: it has been heavily criticized because of all the changes that happened between Qt3/4. As a consequence it has very strict compatibility policies since those days.
But is this much better: we now have 2 different graphic stacks without any migration path. The old one has fallen into maintenance mode and the new one suffers from design problems, that can't be fixed before Qt6. We even saw Quick Controls 2 being started instead of solving the problems of Quick Controls 1.

I don't expect all users being happy when APIs are changing, but for Qwt there have only been only 2-3 substantial API changes in ~20 years. And having one with Qwt6 was unavoidable - I couldn't support Qt3 forever.

But none of what I can see does what I really want, which is a single library that will produce 2D and 3D plots of all sorts.

There once was Michas QwtPlot3D ( http://qwtplot3d.sourceforge.net/ ) library. When he lost his interest nobody had been found, who had enough interest and/or skills to keep it alive.
The code is still there - if you are unhappy with what others are doing: make things better.

Uwe

[d_stranz]

Try to step in my shoes for a moment

Like I said, I'm sorry for bringing it up and I apologize for doing so. Qwt5 was great and I was enthusiastic about using it. Moving to Qwt6 would have required me to make big code changes as well as swallow coding conventions that disturbed me at the time, so I chose not to do it. I should have kept my opinions to myself and let others form their own.

So I am sorry and will not mention it again. You have done a great service to the Qt community by adopting Qwt, continuing to improve upon it, and by participating actively in supporting those who want to use it on this forum and elsewhere. You've released it under license terms that allow its use anywhere, and haven't asked for fees for commercial use. It is admirable of you for doing it and your company for allowing you.

But this is a totally different story, one about stable APIs.

It goes beyond stable APIs. Somewhere between Qt 5.4 and later versions, disabled menu items stopped responding to hover events. I was relying on these events to enable / disable menu items based on my application state. When I switched to 5.5 or 5.6 (don't remember) users started to complain that they could no longer do things because the menus were always disabled. So I got stuck on 5.4.1 for a while until I decided to just enable everything and deal with it in other parts of the code.

Probably the Qt organization has had just too many ownership and management changes over the past few years and they have lost some focus in the process. Software is coming out under the Qt banner that isn't well thought-out.

QwtPlot3D

Yes, and it produces nice plots, but it is based on such an old version of OpenGL that it would require nearly a complete rewrite to bring it up to current standards. I don't know if I have tried building it with Qt5, so it might need more than just an OpenGL update.

Anyway, we've hijacked this thread, so maybe we can bury it and move on?

[mustermann.klaus@gmx.de]

Well, harmony is not a save haven. But it is the ocean.
Thanks to both of you for greatly contributing to my knowledge.

[Uwe]

...and your company for allowing you.

Not really important, but for the record: there has never been any company involved. All work being done for Qwt is/was done in free time.

Uwe

[d_stranz]

there has never been any company involved. All work being done for Qwt is/was done in free time.

Some companies in the US, particularly near here in the Silicon Valley, consider anything you do in your free time as their property if it uses the same skills you use on the job. Luckily for you and us that doesn't seem to be the case with Qwt.

Qwt3d - I don't know if I have tried building it with Qt5, so it might need more than just an OpenGL update.

After some effort, it does build and the examples run with Qt5 (64-bit Qt 5.9.0 MSVC on Windows to be precise). The last update was over 10 years ago. If I can find the free time, I might adopt it and bring it into the modern age.

[Uwe]

After some effort, it does build and the examples run with Qt5 (64-bit Qt 5.9.0 MSVC on Windows to be precise). If I can find the free time, ...

That would be cool - let me know if you need some support from the Qwt related part.

By the way: Guðjón finished his work on the Qwt python wrapper ( https://github.com/GauiStori/PyQt-Qwt ) and with an updated version of QwtPlot3d he might be interested to do the same for QwtPlot3D. Then we would have everything back, that existed for Qt4/Qwt5.

Uwe