Summary: | Fuzzy clock always displays "Twelve o'clock" after changing the timezone | ||
---|---|---|---|
Product: | [Unmaintained] kicker | Reporter: | Dima Ryazanov <dima> |
Component: | kclockapplet | Assignee: | Aaron J. Seigo <aseigo> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | finex, g4mba5 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Fuzzy clock displays the wrong time
Fuzzy clock displays garbage after chaning the timezone More garbage |
Description
Dima Ryazanov
2006-10-25 21:44:30 UTC
Created attachment 18264 [details]
Fuzzy clock displays the wrong time
This happens after scrolling over it using the mouse wheel.
Created attachment 18265 [details]
Fuzzy clock displays garbage after chaning the timezone
Created attachment 18266 [details]
More garbage
Same thing for me here. KDE 3.5.5 from Debian unstable and a slightly larger applet; it shows 12:00 when I'm in fuzzy mode and change timezones, but fixes the time if I go to another mode and back. This not only happens when the timezone is changed, but also when KDE ist started. It displays "Twelve o'clock" for a few seconds and then changes to the right time (openSUSE 10.2, KDE 3.5.5). Yay! I figured it out: --- kdebase-3.5.6/kicker/applets/clock/clock.cpp.orig 2007-05-02 18:45:12.000000000 -0700 +++ kdebase-3.5.6/kicker/applets/clock/clock.cpp 2007-05-02 18:50:19.000000000 -0700 @@ -1571,8 +1571,8 @@ { zone->setZone(z); TZoffset = zone->calc_TZ_offset( zone->zone() ); - _clock->updateClock(); _clock->forceUpdate(); /* force repaint */ + _clock->updateClock(); updateDateLabel(); } You can see the functions forceUpdate() and updateClock() called in that order in another place in the code, on line 1235 - so I think it's correct... This bug also happens in analog clock (if seconds are disabled, otherwise the clock gets updated before you notice anything). But plain and digital clocks did not have this bug simply because their "paint" methods aren't directly affected by forceUpdate(). (Specifically: 1. updateClock() calculates the time for a new timezone, and gives it to QLabel or QLCDNumber. 2. forceUpdate() sets the time string to NULL 3. paint event is handled by QLabel or QLCDNumber - so the NULL string has no effect.) So..? Can someone check that the fix is correct, and if so, apply it? Fixed in KDE 3.5.10. Kicker is no more mantained and all bugs/wishes will not be fixed/implemented in KDE3. A list of the most interesting/unresolved issues which is still valid for KDE4 has been created. Before reopening old kicker bugs on KDE4 Plasma, please try the new KDE 4.3.1, check the current behaviour and, only if you find new bugs or if you need a particular feature, open a new bug report. Remember that KDE 4 is a full rewrite of KDE 3 so some old features will not be re-implemented because the behaviour has be changed a lot on some sides. Thanks for the comprehension and enjoy the new KDE 4! -- FiNeX & D. Andres |