Bug 968823

Summary: change timezone in pmtime doesn't refresh time scale in pmchart (in archive mode)
Product: [Fedora] Fedora EPEL Reporter: Mark Goodwin <mgoodwin>
Component: pcpAssignee: Dave Brolley <brolley>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: el6CC: brolley, fche, lberk, mbenitez, mgoodwin, nathans, pcp, scox
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pcp-3.11.10-1.fc24 pcp-3.11.10-1.fc26 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-05-28 03:56:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mark Goodwin 2013-05-30 03:58:08 UTC
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

Comment 1 Nathan Scott 2015-01-28 04:25:44 UTC
Move pcp-gui bugs into pcp, post-package-merge.

Comment 2 Dave Brolley 2017-03-27 19:59:29 UTC
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.

Comment 3 Dave Brolley 2017-05-10 18:40:25 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.

Comment 4 Nathan Scott 2017-05-10 22:40:22 UTC
| 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.

Comment 5 Dave Brolley 2017-05-11 14:22:38 UTC
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')

Comment 6 Dave Brolley 2017-05-11 14:30:22 UTC
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.

Comment 7 Dave Brolley 2017-05-11 15:07:21 UTC
Changes committed to git://git.pcp.io/brolley/pcp rhbz968823

commit 9559192d2d7335e84fc9cd681a357b95818b6be7
commit 2dc51b271c6d6e91d228af770d6df4587282d61b

Comment 8 Fedora Update System 2017-05-18 16:30:51 UTC
pcp-3.11.10-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c0a1605df5

Comment 9 Fedora Update System 2017-05-18 16:31:58 UTC
pcp-3.11.10-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-466341873d

Comment 10 Fedora Update System 2017-05-19 21:10:04 UTC
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

Comment 11 Fedora Update System 2017-05-20 03:01:45 UTC
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

Comment 12 Fedora Update System 2017-05-28 03:56:52 UTC
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.

Comment 13 Fedora Update System 2017-06-09 19:02:27 UTC
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.