Version: (using KDE 4.0.1) Installed from: Gentoo Packages OS: Linux I have changed my plasma theme (http://www.kde-look.org/content/show.php/Theme%3A+Slim+Glow?content=74329) and I've noticed that systray icons do not have a real transparent background but a black one. Check out this screenshot: http://www.kde-look.org/CONTENT/content-pre2/74329-2.jpg
In my system the background color in 4.0.1 of the system tray icons is white. The 4.0.0 was ok, with no opaque background. I use the standard plasma theme. Someone in #plasma noted though that it is qt 4.3.3 related and a mishing regression fix in gentoo. So I did not report it as bug, and I just wait.
there is really not much we can do about this problem due to the way systray works on x11.
I use KDE 4.0.3, and the same problem occures. The background of the application in the tray is ugly and the icons next to the clock are white. After I added some Plasmoids and changed to compositing happened this and I cannot revert. I'll attach a screenshot.
Created attachment 24183 [details] KDE panel plasmoid bug
*** This bug has been confirmed by popular vote. ***
*** Bug 164526 has been marked as a duplicate of this bug. ***
In fact, it is a random background, like bits taken arbitrarily from memory - sometimes it appears as a garbled copy of another icon, sometimes it contains noise.
*** Bug 165200 has been marked as a duplicate of this bug. ***
Created attachment 25670 [details] Screenshot @Aaron J. Seigo: Is there an upstream bug filed at x11 then?
it's not x.org, it's freedesktop.org where this fix needs to happen. it will require a re-write of the systray spec.
see also bug #153193 why we can't go with a real transparent icon :-/
@Aaron: Could you provide us with the details so that we can file a bug at freedesktop? I did a few simple searches but did not see anything relevant, that could be because I don't know enough about the inner workings of the projects involved. If you want to file the bug with freedesktop, this is their bugzilla: https://bugs.freedesktop.org/
Dotan; just look at bug #153193 - we had transparent icons but had to disable them cause they lead to crashes if different visuals/colormap with ParentRelative is used. See here also; http://lists.freedesktop.org/archives/xorg/2005-January/005790.html http://bugzilla.gnome.org/show_bug.cgi?id=501842 So, it's not a new problem ;) You are also able to find a rather long discusion about the topic at http://mail.kde.org/pipermail/panel-devel/2008-July/thread.html#14309
or a short summary what a systray should be; * http://mail.kde.org/pipermail/panel-devel/2008-July/014412.html * http://mail.kde.org/pipermail/panel-devel/2008-July/014431.html and some more text; * http://techbase.kde.org/Projects/Plasma/TheWaysOfThePlasma#System_tray
Thank you Sebastian. However, it does not seem that there is any bug filed at freedesktop for a change to be implemented. I'd file the bug, but I really don't have enough technical knowledge to word it properly. Would I be rude to suggest that either you or Aaron file the bug?
I can confirm this bug. the system tray icons have no transparent background. I, as a user, do not understand why this could not be solved, when it worked in kde-3.
Created attachment 25915 [details] screenshot from kde-4.0.85
Please, no more screenshots or "me too"s. White background, black background, transparent background that becomes corrupted.. they are all the same issue. The root problem is that plasma uses ARGB visuals while pretty much all applications use RGB. There's presently a hack in place in the system tray applet to work around it, but last I heard (which was before 4.0.0) it is Qt that should be handling this. There's just not many people that understand how it can be fixed, let alone where to fix it and have the time to fix it...
@Jason: Is there a bug filed with Qt then? Please point us to the upstream bug. Thanks.
Lubos, what's the state of the QX11EmbedContainer/SystemTrayContainer workaround?
I have no idea what you are asking about.
http://mail.kde.org/pipermail/panel-devel/2008-January/004558.html This thread. I know that there was (and still is) no other choice at the time, but the artifacts referenced in this bug started appearing after the above change was made.
That patch is in SVN.
Yes, rendering issues with icon backgrounds have been happening since that patch. Previous to it being committed, there weren't any rendering issues as long as ARGB visuals weren't enabled - of course, there weren't any icons at all when ARGB visuals were enabled either though.
@Jason; well, there may multiple other workarounds someone could try like providing the XCreateWindow-hack only if visual+colormap differ and ParentRelative was defined or trying to achieve something with XSetWindowBackground/XSetWindowBackgroundPixmap/XClearWindow or whatever else. But that needs time and may introduce new funny problems/regressions. So, 4.2 (which opens soon afaik)?
@Dotan; re filling bugs at whereever. I would really suggest to wait here at least till after akademy where this will probably a topic according to the links provided at comment #13 and comment #14.
@Sebatian: Alright, then. Thanks. You guys know what you're doing.
Yep, that could be a possible workaround - but not a complete fix, afaik. I'm not entirely sure what the cause is as I'm not familiar with X APIs at all. Nor am I asking Lubos to fix it. I'm just asking what the status of it going upstream is as the last I heard was that Lubos would be sending a patch, although things might have changed since then.
*** Bug 161894 has been marked as a duplicate of this bug. ***
*** Bug 164102 has been marked as a duplicate of this bug. ***
*** Bug 167186 has been marked as a duplicate of this bug. ***
*** Bug 165257 has been marked as a duplicate of this bug. ***
From what I can tell, corruption happens when an icon is rendered off-screen. For example, when there are two rows of icons in a horizontal panel and the panel is resized such that half a row of icons is off the screen, that half of the icons will be corrupted after they are moved to their new positions. Having a resizable panel is probably what has shown this issue to show up so blatantly... For the record, I tried setting BackingStore to Always on both the embed container window and the embedded window but without any luck. I think that one way to solve this issue would be to reset the background pixmap of the client window whenever a paint is issued in the containing window, but I can't seem to figure out how to convert/rerender a pixmap from one depth to another. Any pointers on how to do that so I can give it a try?
Created attachment 26566 [details] Trashed klipper icon under Fedora 9/KDE 4.1.
FWIW I can easily duplicate this bug under Fedora 9/KDE 4.1. Usually the klipper and/or kmix icon are trashed. - Gilboa
Please, no more screenshots or "me too"s.
*** Bug 168603 has been marked as a duplicate of this bug. ***
I also have this problem I use fedora core 9 with kde 4.1
I'm not understanding why this worked fine in KDE3 but not in KDE4. Although, if I had to guess, I would say that Plasma uses a different system than KDE3 did. Regardless, KDE 4.1 is absolutely beautiful, and this bug is one heck of an eye sore if you change the theme. :(
*** Bug 170289 has been marked as a duplicate of this bug. ***
Can't you just do fake transparency (i.e. ask the theme to draw the background then add the icon on top manually) until there is a better systray spec?
@Tim Hutt: With KDE4 the devs have been reluctant to 'temporarily patch' issues to hide them. Although it means that some features remain ugly, I support this approach for two reasons: 1) The issues stays visible, so that a correct implementation will be developed and not simply swept under the carpet 2) The developers do not waste their already strained resources on 'temporary patches' that will be disposed of anyway.
I'm rather confused about this though. I understand the issue and I agree with fixing it the right way rather than putting a band aide on it. But I don't understand how in all the screenshots of the different plasma themes on KDE Look, none of those screenshots show this problem, it looks perfect. I'm just wondering what the difference is.
@Jeremy: Ask that on a mailing list. Please do not hijack or otherwise take Bugzilla off topic. This is not a discussion forum. You can email me off-list and we can discuss it.
I just want to add that this bug in my opinion is not GPU-brand related as I experience it with Nvidia on the desktop and AMD (ati) on the laptop.
I have an experimental workaround that should be ready for 4.2
I also have the black background problem with the system tray icons. Is there any solution that doesn't involve waiting until KDE4.2?
"Is there any solution that doesn't involve waiting until KDE4.2? " barring a time machine ... no. =/
(In reply to comment #43) > I'm rather confused about this though. I understand the issue and I agree with > fixing it the right way rather than putting a band aide on it. But I don't > understand how in all the screenshots of the different plasma themes on KDE > Look, none of those screenshots show this problem, it looks perfect. I'm just > wondering what the difference is. > These screenshots maybe were taken with Desktop Effects enabled where transparency seems to work correctly.
Well, _is_ there at least a solution that involves waiting for KDE 4.2? Anyone knows if the refactored system-tray also suffers from this problem?
@David: ask those questions on IRC or on a mailing list. Bugzilla is the place to report problems and request features, ie, to stream information from the users to the devs. Not the other way around. Filling up bug reports with questions makes it difficult to navigate and delays features' implementation.
@Dotan: Well, I guess everyone who subscribed to this bug would be interested in the answer to that question, so imo this is the perfect place to answer it. And please don't reply to this message, because that would be really off topic.
A somewhat old version of the workaround that I put into the rewrite has been "backported" to trunk's system tray, so it will work in some shape or form in 4.2. Given that 4.2 isn't that far away, it very likely won't be put into 4.1.
*** Bug 171211 has been marked as a duplicate of this bug. ***
Jason, whats the SVN commit revision that put the workaround in place?
Ahh, sorry.. it's not in subversion. It's uncommitted (for several weeks) in my local checkout. Either way, something definitely will be done in time for 4.2.
Nice to know it's going to be fixed, good job on KDE4, it's best kde ever!
*** Bug 171718 has been marked as a duplicate of this bug. ***
Running the opensuse 11 default xorg and kde4.1.1, icons in the system tray appear normally, i.e. no transparency. Running xorg-7.4, none of the system-tray icons appear, except for superkaramba. Also in this case occasionally (~50%) the superkaramba systray icon has normal transparency!
*** Bug 172179 has been marked as a duplicate of this bug. ***
I'm curious how many more duplicates and Cc's it will take before this fix is backported to KDE 4.1.
until 4.2 is released.
*** Bug 173268 has been marked as a duplicate of this bug. ***
*** Bug 172109 has been marked as a duplicate of this bug. ***
Can anyone confirm that this bug is indeed fixed in 4.2 (and/or a 4.2 blocker)? - Gilboa
No, this bug is not fixed in KDE 4.2 devel. I'm using openSUSE 11 with KDE 4.1.71.
Running 4.2 from opensuse UNSTABLE repo (trunk) - there are still problems with background. With second computer (nvidia) is even worse (icons are dissappearing). So be happy if you are able to at least see them :)
Does anybody building from source have problems? It should be fixed.
I don't see this bug anymore. I'm using trunk compiled yesterday.
(In reply to comment #69) > I don't see this bug anymore. > I'm using trunk compiled yesterday. > So exactly yesterday this bug dissapeared?
(In reply to comment #70) > > So exactly yesterday this bug dissapeared? > I did not say that. But probably it was fixed between yesterday and the past couple weeks.
For a fact i still observed some problems with SVN trunk compiled yesterday evening.
Seems to nearly work now in the newest OpenSUSE KDE 4.2 devel packages. There is 2 remaining problems though: 1. When you change the plasma-theme, the background is not updated, and the result looks nearly as the old problem. This can be fixed by restarting plasma. 2. Transparent parts of the icons seem to be accumulated, instead of being painted onto a fresh background with each paint. This makes for example the soft shadow in the akkregator icon deep-black after some time.
The background should be updated on a theme change and I can't see any reason it's not being. I'd like to see what patches (if any) there are in opensuse. Can I see them via the build service site? A direct link would be very helpful. I'll need to try and reproduce the soft shadow issue. How does kopete look when its icon animates?
https://build.opensuse.org/package/show?package=kdebase4-workspace&project=KDE:KDE4:UNSTABLE:Desktop, I cannot see any plasma-specific patches there. I've rechecked this on my desktop-machine with an nvidia graphics card, and there the fix doesn't work at all. So I just hope they don't have the newest version in yet. :) I don't know in what situation the kopete icon animates, but what I can see is that it currently has very dark borders painted(after some usage), because of the re-painting issue.
*** Bug 174057 has been marked as a duplicate of this bug. ***
I don't know if I should open a new bug, or report here. I'll try here first. The BG of the tray icons are black as long as you have no application window behind the task bar panel, then they take the colour of the window currently underneath (at least if you have auto-hide on). When the icons update themselves their BG will turn black (f.i. the network applet and amarok, which update themselves frequently). This is very visible with taskbar auto-hide since the the movement of the emerging icons will create the appearance of animated icon BGs from the underlying windows.
*** Bug 174133 has been marked as a duplicate of this bug. ***
For some reason, the backgrounds are not working at all when composite is enabled. With composite disabled, things are working near perfectly. Need somebody with more composite knowledge to look at this... Pretty please!
Created attachment 28439 [details] Systray bug in the latest KDE The bug still exists in the openSUSE version 4.1.72 (KDE 4.1.72 (KDE 4.2 >= 20081104)) "release 4.1".
I can confirm this too from opensuse kde 4.2 trunk packages. Not so bad as it was, but icon background is still not transparent as panels and it has repaint issues.
Using KDE Version 4.1.3 (KDE 4.1.3) "release 52.2" on openSUSE 11.0. It's totally fixed and transparent now.
Recently updated to version 4.1.3 from ubuntu packages on kubuntu intrepid. Unfortunately I cannot confirm any improvement...
Like Komuves Akos, I too can confirm that opensuse 4.1 KDE factory build: kde: 4.1.3 build: 54.6 With kde desktop effects turn completely OFF, I see an almost perfect resolution to this problem. Note that with desktop effects turned off, the system tray is not transparent (with any desktop themes). All 10 icons in my system tray have adopted the panels' background colour. There is no way for me to confirm whether or not these icons adopt the transparent appearance, as the old problem resumes when desktop effects are turned on.
Let's recap. The status of 4.1.x is that this bug will never be fixed, so no reports regarding 4.1 are necessary. The status of trunk/4.2 is that it's pretty much perfect when compositing is off and that the background isn't correctly cleared when compositing is on. Also, themes that have a translucent panel are a whole other ballgame which won't be fixed with this bug. If there are any people running trunk/4.2 that disagree with this assessment, please post how it works on your system.
so someone should file a new bug for system tray glitches in themes with translucent panels?
Using trunk, does anybody have a corrupt background using compositing and drivers other than nvidia binaries? I haven't read anything definitive, but it looks like it should work as it is. (In reply to comment #86) > so someone should file a new bug for system tray glitches in themes with > translucent panels? Let's get this bug fully fixed first. The translucency stuff might be trivial, but it can't be tested (at least not by me) if background painting isn't working at all.
Yes, it still happens. I have a Radron HD 4850 running the proprietary drivers (no accelerated free drivers yet unfortunately) with compositing. I get some corruption with the kopete icon. When i receive a message it displays a rotating icon but the other one can still be seen in the background. I do not know if it is the same bug or not but i still had the problem with SVN trunk a few days ago. Thanks.
http://cgit.freedesktop.org/xorg/proto/compositeproto/tree/compositeproto.txt > RedirectSubwindows > ... > If update is Manual, then painting of the window background during window > manipulation and ClearArea requests is inhibited. So, either kwin is not doing something it should be or the systray isn't doing something it should be. kwin people?
It turns out I was looking in the wrong direction. On IRC, it was explained to me that it's actually a Qt4 problem. When doing updates, QSystemTrayIcon hides the window, takes a snapshot of what's below and then shows the window again, fully painting the entire area. Composite gets in the way of this hack and it also explains why the icons flicker so much.
Pardon the simple question (I'm a novice programmer), but what's the general solution for this? Request the screenshot from the compositor?
Problem exists with kde-4.1.73(kde-crazy overlay on gentoo). No system tray icons visible - just see black rectangles. :(
As far as I can see, it seems now fixed in kde 4.1.73 from the opensuse kde unstable repo. I can just see a repaint issue (when icons are repainted you can see them disappear/reappear). Tested with oxygen.
Ok, this is clearly opensuse-only fix, 4.2 trunk also seems to have it fixed, unless you are using desktop effects.
So is it never going to work with desktop effects?
(In reply to comment #92) > Problem exists with kde-4.1.73(kde-crazy overlay on gentoo). No system tray > icons visible - just see black rectangles. :( This sounds like bug 174964.
Why won't translucent themes get fixed. I like my tranluscent theme. I'm using glassified and I like it. I don't want to come off sounding rude or ungrateful, but what's the point of having a feature in place and bragging about how great it is if it contains bugs that are not going to get fixed?
Who said it's never going to get properly fixed? Please stick to the facts and don't add noise to bug reports. :)
Jason Stubs in Comment 85.
Comment #85 says "won't be fixed with *this* bug." (Emphasis mine) -- not that it won't be fixed at all. (I can't find a bug specific to that problem, so it may be the case that a new one should be filed.)
OK. Done and can be found at http://bugs.kde.org/show_bug.cgi?id=175277 And the 1 million dollar question is will it be marked as a duplicate of "this" bug?
background is not getting corrupted anymore, here and for many other people too (see the lastest comments). Moreover, bug #175277 has been filed, which is specific to transparency, the only currently remaining "issue". Time to close this! =)
This bug also happens sometimes in KDE 4.1.82 (KDE 4.2 >= 20081204)) "release 3.2". I have "Windows-can-cover" panel and the ugly background remains there until I click on the taskbar (and only that time will it be repainted). Maybe it is related to Bug 176325.
(In reply to comment #103) > This bug also happens sometimes in KDE 4.1.82 (KDE 4.2 >= 20081204)) "release > 3.2". > > I have "Windows-can-cover" panel and the ugly background remains there until I > click on the taskbar (and only that time will it be repainted). > Maybe it is related to Bug 176325. > Same problem here, but without "Windows-can-cover".
I'm not sure if this is exactly the same bug I am experiencing, but it looks similar. I am using KDE 4.1.82 in Archlinux x84_64 with nvidia drivers 177.82. It was the same with 4.1.81. Every time my panel hides, the background of all icons in system tray changes. It is often inherited from the window that was below the panel, but if I just show and hide the panel several times, this background changes - it could contain parts of the window below, or just simply black, or sometimes dark grey. And it can be different for different icons too. I'll try to include sshots.
Created attachment 29257 [details] Broken background of icons in systray (4.1.82)
Created attachment 29258 [details] Broken background of icons in systray (4.1.82)
I can confirm this bug in KDE 4.1.85, moreover sometimes (when new icon appears in system tray) tray applet covers clock applet..
*** Bug 179310 has been marked as a duplicate of this bug. ***
Created attachment 29846 [details] Screenshot in 4.1.86 This problem is still present in 4.1.86 using packages from kde42.debian.net (version 4:4.1.86+svn902265-0r1).
I noticed that this bug is marked as fixed. I still have this problem on 4.2RC1, yet it corrects itself when I unhide and then rehide the system tray icons, so it is a little better.
Created attachment 30373 [details] KDE 4.1 RC1 While looking better than KDE 4.1, KDE 4.2 still showing the same corruption. However, unlike previous releases, once the tray is refreshed (after ~20-30 seconds), the corrupted background disappears. - Gilboa
(P.S. KDE 4.2 RC1, KDE-SIG RPM's, Fedora 10)
I confirm this on kde 4.2 rc1. How to reopen this bug?
Read comment 90 and file a bug at Qt-Software.
I've filed a bug at QT.
And the link to the Qt bug is... ? :-/
It is not approved yet but I got auto reply saying "We have assigned it the issue number #241734." I think it may appear in some time to below url. http://trolltech.com/developer/task-tracker
I just got update that it is fixed in qt 4.5.
Also they pointed to this issue. http://www.qtsoftware.com/developer/task-tracker/index_html?id=238743&method=entry
*** Bug 181365 has been marked as a duplicate of this bug. ***
I have just tried today Qt 4.5 snapshot (without recompiling KDE) - Plasma crashed a lot (probably I should have recompiled KDE ;) ), but the background issue is gone.
(In reply to comment #122) > I have just tried today Qt 4.5 snapshot (without recompiling KDE) - Plasma > crashed a lot (probably I should have recompiled KDE ;) ), but the background > issue is gone. I don't know how you managed to run kde4.2 with qt4.5 (is it beta1?) since I tried it and plasma crashes. I can't run kde4.2 RC with Qt-4.5beta1. Yeah, I recompiled kdelibs and kdebase.
qt-copy (from today) doesn't fix it.
Nope, not beta1, I used snapshot 20090121. Firstable, kdm crashed, so I started X without it. And Plasma crashed, until I started it with desktop effects disabled, and enabled them later. Plasma still crashed a lot though, but at least it displayed something... ;)
*** Bug 181448 has been marked as a duplicate of this bug. ***
Resolution says FIXED, but it is not. Instead it is a bug in Qt. Why doesn't the resolution say "NOTOURBUG" or "UPSTREAM" or something like that? FIXED will only confuse users. Like myself :) This bug is not fixed. I'm running KDE 4.2 RC + Qt-copy, and I still get the systray background issue I describe here: http://bugs.kde.org/show_bug.cgi?id=181365 Best regards, Norberto
I agree with Norberto regarding resolution.
qt-copy is still 4.4. Wait until 4.5 is out.
Changing resolution to UPSTREAM in light of Comment #127. It is _not_ fixed yet, but it will trickle down soon.
*** Bug 182727 has been marked as a duplicate of this bug. ***
*** Bug 183161 has been marked as a duplicate of this bug. ***
*** Bug 182673 has been marked as a duplicate of this bug. ***
*** Bug 182338 has been marked as a duplicate of this bug. ***
*** Bug 183336 has been marked as a duplicate of this bug. ***
If you are getting sick of looking at your garbled icons while you are waiting for QT 4.5, just run 'kwin --replace' and they will be cleaned up.
*** Bug 183810 has been marked as a duplicate of this bug. ***
Just tried out qt 4.5 on Mandriva cooker using kde 4.2 and I can confirm that it looks to have cleared this issue.
*** Bug 184061 has been marked as a duplicate of this bug. ***
yep, tried 4.5-rc1 and it works flawless
I installed QT 4.5 rc1 but still see the icons not having transparent background. I have installed qt version 4.4.90+4.5.0rc1-33.1 from opensuse qt repository.
*** Bug 184916 has been marked as a duplicate of this bug. ***
*** Bug 184908 has been marked as a duplicate of this bug. ***
I noticed that this happens to non kde4 apps like knetworkmanager3, pidgin, etc.
*** Bug 185598 has been marked as a duplicate of this bug. ***
(In reply to comment #145) > I noticed that this happens to non kde4 apps like knetworkmanager3, pidgin, > etc. I sent mail to qt and got following response. > Remember, KDE 4.2 must be compiled and linked with 4.5.0 as well as all > QT/KDE based programs. If non QT/KDE program's Icons do the same > thing, then this needs to be taken up with KDE, and they can tell us > what exactly it is that causes this problem if it is in fact Qt.
Hmm, would like to know why plasma misbehaves with non-KDE applications. In my case it is WICD - would love to see a transparent background there as well. :)
*** Bug 186608 has been marked as a duplicate of this bug. ***
Created attachment 33440 [details] screenshot of system tray I got this bug in kde4.2.3 as well.
(In reply to comment #150) > Created an attachment (id=33440) [details] > screenshot of system tray > > I got this bug in kde4.2.3 as well. In order to get this bug fixed, you only have to install Qt 4.5.
Actually not totally... I'm runninf fedora 10 with KDE 4.2.2 & QT 4.5... it did totally resolved the problem for the QT/KDE based tray icons but still the Gtk/Gnome based one are not being displayed properly and that includes NetworkManager, SElinux and the "auto"-update applet... So sadly I tend to not agree with the statement as being "fully" resolved.
(In reply to comment #152) > Actually not totally... I'm runninf fedora 10 with KDE 4.2.2 & QT 4.5... it did > totally resolved the problem for the QT/KDE based tray icons but still the > Gtk/Gnome based one are not being displayed properly and that includes > NetworkManager, SElinux and the "auto"-update applet... > > So sadly I tend to not agree with the statement as being "fully" resolved. Mmm I have no problem even with GTK/Gnome applications :S I have KDE 4.2.2 and Qt 4.5.1, using ArchLinux and KDE from KDEmod.
Hi guys, I'm afraid I have to report that for some icons, networkmanager, pulseaudio applet icon etc... the story continues. Most of the icons are now fixed, but not all. The update of qt 4.4 to 4.5 made a difference, though the bug, for me, has not yet been fully resolved. System: Fedora 10 Kde 4.2.2 Qt 4.5.0 I noticed that fedora 11 (rawhide) has qt 4.5.1 packaged. Were there any bug fixes in this release for gtk icons?
I'm on qt 4.5.1 with qt-copy patches. Also I'm running 4.3 trunk. Currently I have problem with pidgin icon(gray background). As I specified in comment #147, if it is qt bug, kde developers need to send more info to qt to help them fix it.
Created attachment 33645 [details] QT 4.5 KDE 4.2.2 + System tray bug remains This is to show that non-QT icons are still being rendered incorrectly in the system tray with QT4.5.0 (where resolution was suppose to be), and KDE 4.2.2 Hope that helps.
Rob, Please read : Comment #18 From Jason Stubbs Comment #79 From Jason Stubbs Comment #86 From Domenico Camasta Comment #87 From Jason Stubbs You screenshot is of a similar problem but it is related to composing only. This problem has been resolved when composing is not used. So it's a separate issue. This problem is an upstream one, qt being the project upstream. Because this bug is resolved now, a report for the icons not working using composing maybe needs to be created but it should really be just taken straight upstream. There is also the new systray spec to be taken into account in some way; whether it resolves this or not. Either way, posting screen shots to this report seems counter productive seeing as the report is now closed and the problem has been resolved upstream.
I got this on xchat icon still. Using kde4.2.3 qt-copy 964497 I'm do not have effects enabled using an ATI card x1400 with catalyst-9.3 If this is the wrong place to report it then where should i report it?
http://www.qtsoftware.com/developer/task-tracker RESOLVED as UPSTREAM means the problem is upstream and the report here is resolved. Apart from the kde version info, the qt version you have is the only other thing of significant interest and it's easy to assume that you have a copy of kde that isn't compiled against latest qt. Is that the case? The bug was fixed in qt4.5 IIRC.
I use a rather fresh qt-copy version (it identifies it self as 4.5.1) as you can see and my kde is compiled against it (i compiled it my self). So i wouldn't say that the problem is gone in qt4.5
*** Bug 210362 has been marked as a duplicate of this bug. ***
As was pointed out https://bugs.kde.org/show_bug.cgi?id=158094#c120 - the problem was fixed upstream by adding support for _NET_SYSTEM_TRAY_VISUAL property, if it is supported by the system tray.
However the problem still exists with non-KDE applications (I found it again with Spotify under Wine). Here's a last message in thread describing possible fix for this: http://lists.kde.org/?l=kde-commits&m=123146417222291&w=2 So upstream problem is fixed, but KDE problem is still there - bug should be reopened.
@Dmitry Pisklov: the fix went into Qt (and at some point Gtk+ as well); Spotify doesn't use either, does it?
2Aaron: Doesn't Wine uses GTK (at least for tray access)?
For the sake of clarity (just spend few minutes discussing what my report is NOT about): I have issue with UPDATING of plasma background under Spotify (with Wine) icon in systray. When I start my Spotify, icon IS transparent (i.e. it uses background of current plasma theme around). When I'm trying to change plasma theme (darker or lighter), background is not updated thus Spotify icon in tray has artefacts around (square of color of old background). Restarting of either application or plasma fixes issue. Qt developer (Denis Dzyubenko, ddenis) says that it's because of using fake transparency by Wine (instead of real ARGB visuals). Anyway I think common fix to it will be readding (removing and adding back) of all tray icons within theme update.
Also same thing happens when we toggle desktop effects. Icon background is not updated.
Pidgin's tray icon has non transparent background. Is this pidgins issue or is it related to this?
I'm on kde 4.4 beta1 and qt 4.6 but the problem is still present. Pidgin icon background is not transparent.
Not sure if it was pidgin issue, after upgrading to pidgin 2.7.1, its icon is appearing properly in systray. Qt: 4.6.3 KDE Development Platform: 4.4.92 (KDE 4.4.92 (KDE 4.5 RC2)) "release 2"