Bug 968823 - change timezone in pmtime doesn't refresh time scale in pmchart (in archive mode)
change timezone in pmtime doesn't refresh time scale in pmchart (in archive m...
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: pcp (Show other bugs)
el6
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Dave Brolley
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-29 23:58 EDT by Mark Goodwin
Modified: 2017-06-09 15:02 EDT (History)
8 users (show)

See Also:
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-27 23:56:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Goodwin 2013-05-29 23:58:08 EDT
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-27 23:25:44 EST
Move pcp-gui bugs into pcp, post-package-merge.
Comment 2 Dave Brolley 2017-03-27 15:59:29 EDT
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 14:40:25 EDT
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 18:40:22 EDT
| 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 10:22:38 EDT
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 10:30:22 EDT
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 11:07:21 EDT
Changes committed to git://git.pcp.io/brolley/pcp rhbz968823

commit 9559192d2d7335e84fc9cd681a357b95818b6be7
commit 2dc51b271c6d6e91d228af770d6df4587282d61b
Comment 8 Fedora Update System 2017-05-18 12:30:51 EDT
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 12:31:58 EDT
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 17:10:04 EDT
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-19 23:01:45 EDT
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-27 23:56:52 EDT
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 15:02:27 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.