Version: (using KDE KDE 3.5.5) Installed from: Gentoo Packages Compiler: gcc (GCC) 4.1.1 (Gentoo 4.1.1-r1) OS: Linux Switch the clock applet to the "fuzzy" mode, and add several timezones. Now, if you scroll over the clock, it changes the timezone and displays the correct time for a fraction of a second. But, then it changes to "Twelve o'clock". Only a few minutes later, when it updates the text, it displays the correct time again. If you change the timezone using the context menu, then the clock displays complete garbage - looks like some repaint errors. If you try to do that several times in a row, then the context menu sometimes disappears even before you click anything!
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