Bug 146007

I've noticed this too, but after readding it to the panel (ie. RightClick -> Remove From Panel .... && RightClick -> Add Applet to Panel) it gets its transparency.
But unfortunately it introduces a new bug then, see:
http://bugs.kde.org/show_bug.cgi?id=146056

Same behaviour here. Re-adding the applet to the panel changes to a different colour, which still doesn't quite match the transparent kicker background. It looks like it just picks up the single background colour of the desktop, not the colour of the wallpaper.

Same thing here, on Kubuntu Feisty with recent KDE 3.5.7.

Created attachment 20996 [details]
KWeather taking background from incorrect h-position

Comment on attachment 20996 [details]
KWeather taking background from incorrect h-position

My panel bar is shaded top to bottom, but it also takes different colors on the
left and right sides, so I noticed something else.  KWeather appears to be
drawing the background behind itself as though it were on the left and right
side, and does so no matter where it's positioned--even at a spot where the
background should clearly be grayscale.

*** Bug 147430 has been marked as a duplicate of this bug. ***

*** Bug 145844 has been marked as a duplicate of this bug. ***

*** Bug 145803 has been marked as a duplicate of this bug. ***

*** Bug 146056 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

*** Bug 148579 has been marked as a duplicate of this bug. ***

So we know there's a problem, can the main developer fix it or should someone else look into it?

*** Bug 148839 has been marked as a duplicate of this bug. ***

I just noticed my original bug report was moved here after posting some observations so just so I'm putting what I just posted elswhere here;

I had a bit of a play here and have observed the following on my desktop which is set to transparent with transparency all the way to the left (max minimum): 
 (1) kweatherservice grabs the area of background on which it lands when added to panel, 
 (2) it keeps this original section of the background no matter where it is moved on the panel, 
 (3) I can remove a kweather service applet which seems to have lost it's transparent attributes and add a new kweatherservice applet and it will seem to have transparent background again just as in item (1) above, 
 (4) upon start up the panel is grey before it becomes transparent, 
 (5) kweatherservice appears on the panel before it becomes transparent and assumes transparency over a grey background, 
 (7) because kweatherservice retains the initial background it lands on it, will continue to remain transparent with a grey background no matter where I move it to on the panel. 
 
 I'd bet that if the panel was not grey but instead transparent (i.e. with background)when kweatherservice started up, that it would appear transparent having assumed the section of background upon which it lands this startup. 

I have the same trouble that the kweather gets the panels original color instead of the transparency that I have selected to use on the panel. No problem in earlier versions of kdetoys, only in 3.5.7.

This on the following architectures: amd64, x86 and ppc (haven't compiled kde for Sparc,, but I don't think it would be different). 

Made a quick diff compare between 3.5.6 and 3.5.7 and it wasn't really much differences, but haven't had the time to investigate the differences, so I took the easy way and compiled kweather from kdetoys 3.5.6 against KDE 3.5.7 and then replaced the binaries/libraries and now I have the transparency back.

This is a solution for those of you who can't wait for a update released.

For what its worth, Debian Sid exhibits the same behavior.  I'm stuck at 3.5.5-3, so its not a Ubantu packaging problem.

Still happens in 3.5.8...

My quick fix (using kweather from 3.5.6) don't work with KDE 3.5.8, so there been changes in the KDE core that worsens the bug.

This issue persists with KDE 3.5.9 and Kweather 2.1.0 (using KDE 3.5.9) as released with Mandriva Linux 2008.0.

One possible solution may be to add an option to select the icon's background color in a manner similar to that provided to select the text's foreground color (in display tab).

A better solution (as suggested above) would be to start kicker transparent so Kweather starts with a transparent background, then it would match any background placed under it by kicker as it finishes loading.

There been quite big changes in KDE 3.5.9, so the trick of using kweather from 3.5.6 and compile it against 3.5.9 won't work. 

I begun to experiment with the transparency and got a good start where I could get the transparency if I did remove and then select kweather to my panel, but sadly I stored the test source code in my /tmp and completely unaware that my laptops /tmp was always cleaned out at shutdown.

If I remember it right, the "background color" given for kweather is the original color of the kicker, which is always a solid color and kweather don't update background color on all events needed. I would guess it's less than a hours work for someone who knows qt3 well, while for someone like me it's more likely a day or two, sadly I don't have that much time at the moment.   

KDE 3.5 is unmaintained and kicker is no more in KDE 4. That's why I close this old bug. Please complain if that's wrong.