Bug 153193

On 12/01/07 Krush-day a user confirmed me that some other GTK applications crashed with the same error (i.e: Pidgin).
This bug is filed under the wrong component, not "general" but "plasma".

CC'ing panel-devel too as it seems a rather grave bug, a showstopper I'd say.

this is almost certainly a bug in gtk+. seems they don't handle setting the background of an xembeded window with argb visuals. suck. anybody feel like filing a gtk bug? =)

If it is a GTK+ error, why it doesn't happens with KDE 3? Anyway if confirmed I can file the bug to GTK... 

> If it is a GTK+ error, why it doesn't happens with KDE 3?

kde3 doesn't use gtk. it uses qt3. there's no connection between the two toolkits.

Yes, sure kde 3 doesn't use GTK ;)
After reading your blog post (http://aseigo.blogspot.com/2007/12/argb-visuals.html) I figured out why it doesn't work...

Bug in GNOME's bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=501842

I think we could use a proxy window that'd handle the background or different visuals somehow. That will still probably leave the systray with ugly background for those icons.

Seems gnome panel here is using ARGB visuals, and applications are not crashing:
http://www.cimitan.com/blog/2007/12/12/gtk-rgba-transparent-widgets-with-the-murrine-engine/

The panel transparency could be a hack, Cimi doesn't talks specifically of that, but I don't think so given what the post talks about.

DISCLAIMER: I don't know that code, just reporting from what I saw on the web :-)

obviously if all the apps are using ARGB visuals there would be no mismatch. which is the entire problem here. notice how in that blog entry every single widget in every single app is using alpha?

for the records, xchat doesn't crash here, yesterday's svn.

It still crashes here (with xchat), using version 3.97.1, release 6.5, from the open suse build service.

but we can't wait for GTK+ to fix this ... 
what is the workaround ?

can't you detect if the client application supports ARGB or not? if the apps does not support it, could not you default to some settings or wrap it into something so the app would run anyway, even though those apps might get uglier for a while. It does not matter so much I believe.

Please do not wait for them to fix/implement this.

Created attachment 22842 [details]
Backtrace for gtk+icon crash.

I reproduced this bug with both pidgin and azureus. Here is the backtrace for
azureus.

The audio player Audacious shows the systray icon without problems. It's a gtk application.

SVN commit 758247 by lunakl:

Work around problems with embedding windows with different visuals/depths.
BUG: 153193



 M  +2 -1      CMakeLists.txt  
 M  +37 -3     qx11embed_x11.cpp  
 M  +16 -5     qx11embed_x11.h  
 M  +1 -6      systemtraycontainer.cpp  
 M  +2 -2      systemtraycontainer.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=758247

I've tried to compile all (after the fix) with emesene and pidgin and the problem IS NOT fix for me.

What is the error/backtrace for it?

With pidgin the program crash..
 
Usign emesene I see this text
The program 'emesene' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 3030 error_code 8 request_code 2 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

That doesn't make sense. Please try to get a backtrace as said in the error message.

I've tried to pass --sync parameter to emesene but the error I received it is the same. Have you tried Pidgin in your computer to see if it's works ok? 

try to start emesene it in gdb ?

it works for me now, but the draw back is an ugly system tray. 

unfortunately we can't have both I guess

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

I haven't had a chance to look at any of the code related to this issue, but is it possible to paint the background black? Right now the icons are encased in white boxes, but people wouldn't notice if they were encased in boxes that matched the color of the panel.

> but people wouldn't notice if they were encased in boxes that matched the
> color of the panel

until they use a white panel svg ;) it should really use Plasma::Theme::self()->backgroundColor() i suppose, though i'm not sure how compatible that is with how it's done now in the systray applet; e.g. does WhitePixel return an indexed colour or an actual rgb value? i think the former which would make things difficult indeed.

I saw that commit 758246 removed these lines from systemtraycontainer.cpp

       // HACK: Tell the client to draw it's own black background rather than   
       // taking ours as things are broken with ARGB visuals it seems.   
       XSetWindowBackgroundPixmap(QX11Info::display(), clientId, None);   
       XSetWindowBackground(QX11Info::display(), clientId, 0 /* black */);

What was the reason behind removing them? We get a good looking systray when added back in and GTK apps still launch here.

Those lines were what was causing GTK apps to crash ;)

Now I can confirm that this workaround works with my emesene and pidgin... but the white background is really very ugly :-)

> but the white background is really very ugly

yep. best thing would be if gtk+ would simply fix their toolkit, but apparently they are living in some sort of state of denial (you'd think that just because everyone else can get their toolkit to Do The Right Thing(tm) that they'd be able to as well).

next best thing will be to wrap the entire systray icons glob in a white-background widget; while still glaring it at least won't have those visibly hard edges with black gaps between each icon.

ultimate solution is a long term one: kill the systray in its current incarnation because it is, by design, broken. i've been saying this for 4 years now, i know that Lubos is certain sympathetic to the idea now, as are the enlightenment people ... maybe the rest of the world will be able to catch up with the concept as well and we can move to something that works a lot better for modern needs. but yeah .. until then ... uglyness will be our friend.

This is not gtk's fault. It may be at most too strict about it, but it has every right to expect nobody will mess with its own windows.
Making the whole systray applet use normal background is the easiest workaround. Another possibility could be to patch QSystemTrayIcon to set shape on the window, matching the shape of the icon (not quite sure that'd work and possibly this would also have to be Plasma-only).
As for replacing systray with something else, I've hated systray since a looong time ago. I remember playing with alternatives as long ago as Ludwigsburg. I should finally find time to create something usable :-/.

White backgrounds are gone now

Any chance to see a patch against kde-4.0.0 for packagers to use? :)  (I've tried to naively make a svn diff of l.lunak's recent commits wrt this, but I failed miserably).

Created attachment 22913 [details]
Cross-bitdepth support for 4.0.0

There are a few other changes been made since 4.0.0 but this is just the
changes relevant to this bug (to be on the safe side)

Created attachment 22914 [details]
Plasma::Theme::backroundColor() patch

Turns out that the above change needs this addition to libplasma as well.
Both have been added to the 4.0 branch.

Thank you Jason!

Thank you very much Jason! Now the situation is really better!
I have another question, with pidgin and emesene the icon appair bigger than the kde icons. I try to explain me better: The space used from the icon is the same but the gtk icon are painted bigger and than cutted to stay in this space..

Created attachment 22919 [details]
Gtk icon cutted

To explain me better I attach this image. In the first part you can see the
icon that I define "cutted". It's strange that when I close pidgin icon,
emesene icon became normal.

Ok..I can confirm this situation:
- When you start a gtk application like (pidgin, emesene etc) the icon in the tray appair bigger (like in my attachment)
- If you close one application that has an icon in the tray (a kde application,too) and a refresh is done to the tray then the icons are painted normal

I try also opening pidgin, emesene and kmix. The first time pidgin and emesene used bigger icon, when I close kmix the pidgin and msn icons appair normal.

I hope this information could be useful for you.

Please open a seperate bug for this. This bug's been closed and your issue is a different one, although possibly related. After opening a new one, you might want to link to it from here though so that those that care can find it easily.

Ok Jason. I've opened a new bug. Bug 155381 - https://bugs.kde.org/show_bug.cgi?id=155381

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