Bug 98398 - Clock applet doesn't take the current color scheme
Summary: Clock applet doesn't take the current color scheme
Status: RESOLVED FIXED
Alias: None
Product: kicker
Classification: Unmaintained
Component: kclockapplet (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Aaron J. Seigo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-02 10:53 UTC by Georgi Ivanov
Modified: 2008-09-23 11:51 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
date area not repainted (5.04 KB, image/png)
2008-03-31 17:26 UTC, Georgi Ivanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Georgi Ivanov 2005-02-02 10:53:31 UTC
Version:            (using KDE KDE 3.3.91)
Installed from:    Compiled From Sources
OS:                Linux

After changing the color scheme, Clock applet doesn't take these colors.
Same behaviour in KDE 3.3.2 .

Also after changeing the transparency setting OFF and than ON, the background of the date in the Clock is not transaprent (in KDE 3.3.2)(it's ok in 3.4 ).
Comment 1 Aaron J. Seigo 2005-02-02 18:15:50 UTC
> After changing the color scheme, Clock applet doesn't take these colors.

there is not enough information here. i'll need to know some of your kicker settings (transparency?) as well as which clock face you are using, the colors set in the configuration of it (if any), what parts of the clock in specific didn't pick up the new colours, etc...
Comment 2 Georgi Ivanov 2005-02-03 09:58:09 UTC
The Clock type is Digital.The problem appears with other types too.

I think i figured out what is the problem. After changing the color scheme of KDE clock doesn't take it . But if i kill kicker and run it again everything is correct.

When Kicker is transparent (only when transparent !) the same problem appears with Taskbar.
The color of the applications in taskbar is not updated .
I hope this information is enough.

cheers
Joro
Comment 3 Aaron J. Seigo 2005-02-03 10:50:40 UTC
yes, that'll do. thanks =)
Comment 4 Aaron J. Seigo 2005-02-12 10:28:32 UTC
CVS commit by aseigo: 

another way to break transparency in the clock fixed.
BUG:98398


  M +14 -3     clock.cpp   1.202
  M +1 -0      clock.h   1.56


--- kdebase/kicker/applets/clock/clock.cpp  #1.201:1.202
@@ -365,5 +365,5 @@ void DigitalClock::loadSettings()
 }
 
-void DigitalClock::paintEvent( QPaintEvent*)
+void DigitalClock::paintEvent(QPaintEvent*)
 {
     QPainter p(_buffer);
@@ -373,5 +373,6 @@ void DigitalClock::paintEvent( QPaintEve
         p.drawTiledPixmap(0, 0, width(), height(), lcdPattern);
     }
-    else if (_prefs->digitalBackgroundColor() != palette().active().background())
+    else if (_prefs->digitalBackgroundColor() !=
+             KApplication::palette().active().background())
     {
         p.fillRect(0, 0, width(), height(), _prefs->digitalBackgroundColor());
@@ -861,4 +862,5 @@ ClockApplet::ClockApplet(const QString& 
       m_layoutTimer(new QTimer(this)),
       m_layoutDelay(0),
+      m_followBackgroundSetting(true),
       _prefs(new Prefs(sharedConfig())),
       zone(new Zone(config())),
@@ -1132,18 +1134,24 @@ void ClockApplet::reconfigure()
     }
 
+    QColor globalBgroundColor = KApplication::palette().active().background();
+    QColor bgroundColor;
     switch (_prefs->type())
     {
         case Prefs::EnumType::Plain:
             _clock = new PlainClock(this, _prefs, this);
+            bgroundColor = _prefs->plainBackgroundColor();
             break;
         case Prefs::EnumType::Analog:
             _clock = new AnalogClock(this, _prefs, this);
+            bgroundColor = _prefs->analogBackgroundColor();
             break;
         case Prefs::EnumType::Fuzzy:
             _clock = new FuzzyClock(this, _prefs, this);
+            bgroundColor = _prefs->fuzzyBackgroundColor();
             break;
         case Prefs::EnumType::Digital:
         default:
             _clock = new DigitalClock(this, _prefs, this);
+            bgroundColor = _prefs->digitalBackgroundColor();
             break;
     }
@@ -1174,4 +1182,7 @@ void ClockApplet::reconfigure()
     updateDateLabel();
 
+    // FIXME: this means you can't have a transparent clock but a non-transparent
+    //        date or day =/
+    m_followBackgroundSetting = (bgroundColor == globalBgroundColor);
     setBackground();
 
@@ -1211,5 +1222,5 @@ void ClockApplet::setBackground()
     // if the clock has the same background color that we do,
     // let's propagate the background brush too
-    if (_clock->widget()->paletteBackgroundColor() == palette().active().background())
+    if (m_followBackgroundSetting)
     {
         _clock->widget()->setBackgroundOrigin(AncestorOrigin);

--- kdebase/kicker/applets/clock/clock.h  #1.55:1.56
@@ -320,4 +320,5 @@ protected:
         QTimer *m_layoutTimer;
         int m_layoutDelay;
+        int m_followBackgroundSetting;
 
         // settings


Comment 5 Georgi Ivanov 2005-02-28 13:12:54 UTC
Hi,
There is still a very small bug with the Clock's colors.If i change the color scheme of KDE , the Clock doesn't update its colors right now.The colors are updated in following cases:
1)Hide/Unhide kicker
2)Put the mouse over the clock and wait for the tootip
3)The time changes.
There may be other condition related with the updating of the clock applet.

Cheers,
Joro
Comment 6 Georgi Ivanov 2005-02-28 13:28:59 UTC
Another small thing . 
The tooltip(color) is not updated too. The color stays the same until i restart the kicker.
Comment 7 Jes Hall 2005-03-01 22:52:28 UTC
I can confirm this in CVS head updated today. If the colour scheme changes, the clock doesn't change it's background unless you restart kicker. I'm using a non transparent kicker to test this. :(
Comment 8 Adrian Dziubek 2006-05-12 02:56:34 UTC
On my system it changes only the clock area, not the date area. And even this after a kill-restarting kicker. I personally consider the colour feature unnecessary. I would at least give the possibility to use the default kicker/background colour explicitly and make it default.
Comment 9 András Manţia 2006-05-26 10:56:40 UTC
Confirmed in current svn (3.5.3) as well.
Comment 10 Maciej Pilichowski 2008-03-31 16:29:18 UTC
ad. 5 (Georgi)

Currently:
1) not true
2) can't tell because there is not tooltip
3) not true
Comment 11 Georgi Ivanov 2008-03-31 17:25:23 UTC
>>Additional Comment #10 From Maciej Pilichowski  2008-03-31 16:29 -------
>>ad. 5 (Georgi)

I don't know what do you mean with the last comment. If it is to remind me check what is the status, here it is :
Currently in KDE 3.5.8 the problem remains the same . Changing color scheme does not change the background color of the clock applet. The color will change after the time is changed or restart kicker. If i enable "blinking dots" the clock got repainted and the problem is gone . But .. the date area is not repainted.
See attachment for details.
Comment 12 Georgi Ivanov 2008-03-31 17:26:55 UTC
Created attachment 24138 [details]
date area not repainted
Comment 13 Maciej Pilichowski 2008-03-31 17:48:41 UTC
Georgi, it wasn't reminder to anyone ;-)

Just update of information, your post about clock getting correct colors was from 2005, in 2008 the colors are not updated. Not after panel on/off, not after time change. Of course this does not change a thing in solving this issue, because we all would like to see applied color scheme right away.
Comment 14 Pino Toscano 2008-06-15 14:11:13 UTC
*** Bug 164139 has been marked as a duplicate of this bug. ***
Comment 15 gambas 2008-08-18 20:35:58 UTC
Fixes in KDE 3.5.10
Comment 16 George Kiagiadakis 2008-09-23 11:51:57 UTC
SVN commit 848935 by bminisini:

BUG: 98398

The clock applet finally answers correctly to global palette changes.


 M  +29 -3     clock.cpp  
 M  +1 -0      clock.h