Description of problem: in archive mode, change the timezone using the pmtime menu, correctly updates the date string in the bottom right of the timescale window, but the time labels do not get refreshed until you change the archive position. Version-Release number of selected component (if applicable): 1.5.9 How reproducible: always Steps to Reproduce: 1. as per description Actual results: time scale NOT updated Expected results: time scale updated
Move pcp-gui bugs into pcp, post-package-merge.
What I'm seeing is worse. Neither the date string nor the time scale are updated when I change the time zone from my local (EDT+4) to UTC.
I finally found the cause of my observation of the time zone not being updated at all on my system (fedora 24). Within pmtime(1), PmTimeLive::addTimezone and PmTimeArch::addTimezone are both connecting the signal 'selected' from the action group (QActionGroup) representing the list of time zones on the menu. However, according to http://doc.qt.io/qt-4.8/qactiongroup.html#details the correct signal is 'triggered'. After connecting the 'triggered' signal, I now observe the partial time zone update as described above. I'm wondering if this was a change to the Qt API at some point and whether older platforms still require the use of the use of the 'selected' signal. Clearly the 'selected' signal was working on Mark's test platform. For now, I'm connecting both signals.
| I finally found the cause [...] Nice work Dave. | I'm wondering if this was a change to the Qt API at some point Almost certainly, and connecting both sounds like the way to go. It'd be worth checking we don't end up with two timezone-change signals in modern Qt versions though. cheers.
No problem with duplicate signals. The problem was that, in modern Qt, there is no 'selected' signal, so there was no signal received at all, and the following was printed on stderr: QObject::connect: No such signal QActionGroup::selected(QAction *) QObject::connect: (receiver name: 'PmTimeLive')
On to the reported bug now ... It turns out that QwtAbstractScaleDraw caches the tick labels. When GroupControl::updateTimeAxis calls pmchart->timeAxis()->replot(), although the time zone has changed, the actual time values have not. So the replot() becomes a no-op. The solution is to clear the cache by calling QwtAbstractScaleDraw::invalidateCache() before replotting. I implemented this in the existing TimeAxis::clearScaleCache() method which calls a new TimeScaleDraw::clearScaleCache() method. QwtAbstractScaleDraw::invalidateCache() could not be called directly because it is a protected method.
Changes committed to git://git.pcp.io/brolley/pcp rhbz968823 commit 9559192d2d7335e84fc9cd681a357b95818b6be7 commit 2dc51b271c6d6e91d228af770d6df4587282d61b
pcp-3.11.10-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c0a1605df5
pcp-3.11.10-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-466341873d
pcp-3.11.10-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c0a1605df5
pcp-3.11.10-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-466341873d
pcp-3.11.10-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
pcp-3.11.10-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.