Version: (using KDE 4.1.3) Installed from: Fedora RPMs Icons, when using a transluscent theme such as glassified the background of the icons are not transparent.
To follow up on the OP, this bug is spun off from bug 158094. Specifically, this bug covers the case of tray icon requests via the FDO spec from applications that don't support the ARGB extension into a panel that has a transparent background on a system with composite enabled. Wasn't that a mouthful? ;) Unfortunately, that very specific set of circumstances is what everyone wants right now.
OK Thanks Jason. That somebody understands whats going is reassurring and helpful. I look forward to the fix when it arrives.
is this a diferent bug from #158094, or the same one? and is that use case even fixable?
I currently see three issues with the background drawing: 1) Having the panel/desktop/etc background propogated to tray icons 2) Appearing transparent when on a transparent panel 3) Qt doing the hide-snapshot-show dance causing failures with composite I consider bug #158094 to cover the first issue. It's pretty much fixed, but I still see noise drawn on certain icons - only the gtk scim tray icon actually. I'm not sure whether the second issue (this bug) can be fixed or not. The only way I can see to do it would be to capture the desktop (the root window?), manually blend it with the captured panel and then set that as the background pixmap on the tray icons. If the desktop can be captured (and the hack isn't too ugly) it should be doable with minimum fuss. As for number three, well... Another hack might be found, but I don't really have high hopes.
Great thing about Open Source. Since KDE and Qt go together hand in glove, maybe talking to the developers over there might provide insight, or better yet a fix. As far as the second problem, if its only one icon maybe you can talk to the developers of gtk scim. Maybe, they would show enough good will to change the icon so that it work ok. Problem solved. No hacks ugly or otherwise.
capturing the desktop is not an option; it doesn't blend with windows, it leads to all sorts of manual positioning of pixmaps and isn't very efficient to boot. i did it with kicker, i really don't want to see plasma infected with such braindamage. toolkits can simply catch up with the argb times, people can stop using those apps and/or we can move on to a non-stupid systray protocol. but compromising plasma for stupidity elsewhere isn't an option =) as such, i really don't think this BR is solvable within acceptable parameters.
(In reply to comment #5) > Great thing about Open Source. Since KDE and Qt go together hand in glove, > maybe talking to the developers over there might provide insight, or better yet > a fix. Probably.. But it'd be better coming from somebody more knowledgeable than me. ;) > As far as the second problem, if its only one icon maybe you can talk to > the developers of gtk scim. Maybe, they would show enough good will to change > the icon so that it work ok. Problem solved. No hacks ugly or otherwise. Not sure where the problem is yet.. Needs further investigation. (In reply to comment #6) > capturing the desktop is not an option; it doesn't blend with windows, it leads > to all sorts of manual positioning of pixmaps and isn't very efficient to boot. > i did it with kicker, i really don't want to see plasma infected with such > braindamage. Unfortunately, this is pretty much the kind of brain damage that is getting the backgrounds painted at the moment. IOW, manual positioning and non-efficiency is already there - ARGB icons aren't affected though. As well as not blending with windows, there's also the issue of not updating after a wallpaper change. ;) It wouldn't be perfect, but it'd be fairly easy to slot into the current code. > toolkits can simply catch up with the argb times, people can stop using those > apps and/or we can move on to a non-stupid systray protocol. but compromising > plasma for stupidity elsewhere isn't an option =) > > as such, i really don't think this BR is solvable within acceptable parameters. I'm pretty much in agreement with this and am not planning on working on this bug any time soon. I'd much prefer to reimplement KSystemTrayIcon and have it use DBus to talk to the tray, which'd solve all the issues in one shot (for kde4 apps at least). I'd just like any/all discussion about it kept out of the other bug report. :)
*** This bug has been confirmed by popular vote. ***