The code of those applications (or the GNOME library code) needs to be changed to do XSetWindowBackgroundPixmap( dpy, window, ParentRelative ) on the X window used as the systray icon. The fake transparency code relies on this.

How does kicker's systray deal with transparency?  Or how is it implemented in KDE tray icons?

Is the bug "GNOME tray icons don't let the kicker's normal background show through", or "GNOME tray icons don't let the desktop background show through when kicker is configured to be 'transparent'"?  Or both?

In the GNOME panel, a real applet's background (not a systray icon) is determined by the panel itself.  The panel<->applet protocol passes a Pixmap around so that applets can use that Pixmap as the starting contents of their drawing.  This works fine for "real" applets, but not systray icons.

I just did a quick test with the GNOME panel and its sytray *and* GNOME systray icons; they don't have any transparency either.  The GNOME systray doesn't do anything special with the background that the panel passes it with its own protocol.  Yes, it does look horrible on the screen :)

So, how does KDE implement this?  Maybe we can do the same thing in the GNOME panel.

The upstream bug about GNOME's own systray icons is http://bugzilla.gnome.org/show_bug.cgi?id=100600

Speaking of panel backgrounds, see this bug:  http://bugzilla.gnome.org/show_bug.cgi?id=164349

It describes the GNOME panel sometimes displaying garbage when an image background is not wide enough.

Created attachment 62499 [details]
Patch that went into HEAD to fix image backgrounds

This is the patch that went into HEAD to fix image backgrounds (http://bugzilla.gnome.org/show_bug.cgi?id=164349).  It needs to be backported to our version.

(14:32:12) vuntz: I think the function that was changed in panel-background.c is in panel-menu-bar.c for gnome-2-12

I'll do that pretty soon.

Re #2: As far as I understand it is just the ParentRelative background as explained in comment #1 is enough. That simply makes the systray icon's background use the same background like the parent window, so it is kind of transparent.
There probably shouldn't even need to be any modifications made to the GNOME panel.

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

Bug #91250 is the same, about systray icons of Netapplet, Groupwise Messenger and Ifolder.

raising severity as zen-updater is started by default now

I think you just have to do this:

1. Change egg_tray_icon_realize() to set the background pixmap of its widget->window to parent_relative, after it has called the parent_class->realize().  The GTK+ machinery will do the right thing when the tray icon or its subwidgets have to be exposed.

2. You *may* have to change panel/applets/notification_area/main.c to connect_after() to the "change_background" signal of the PanelApplet, and cause the child windows of the tray to be repainted.  Since those windows are not in your process, the easiest way to do this is to create a GdkWindow that covers your entire tray, map it, unmap it, and destroy it (this is how xrefresh works).  To avoid flicker, you may want to set the background of that window to None before mapping it.

(reassign to my ximian address to work around bugzilla.novell.com stupidity)

Unfortunately, since the tray icon code is still in libegg and doesn't have a
permanent home, that means we need to separately patch every affected package.

  nm-applet
  beagle-search
  Groupwise Messenger
  iFolder
  zen-updater
  tomboy

any others?
  

gaim would be nice too

Banshee has a tray icon, too.  I don't know if this lives in gtk-sharp.

Just want to add 'Resolution Switcher' and 'Bluetooth File Sharing' tray icons.

Stephan: do you run the GNOME bluetooth tray icon under KDE? Or are you running
GNOME with a panel background image?

I started both of #15 under KDE.

Submitted gaim, ifolder3, NetworkManager, resapplet, tomboy, and zen-updater.
(Patch based on http://bugzilla.gnome.org/attachment.cgi?id=59957&action=view
from http://bugzilla.gnome.org/show_bug.cgi?id=150726)

Fix for banshee is blocking on bug 147970 but should be in soon. The fix for
beagle will either go in at the same time, or will come via an upstream
release.

Lowering severity a bit as comment #9 / #147051 is not current anymore.

There is a banshee dbus sharp issue on 64bit that is being fixed in a patch bug 151273 that should be committed today.

committed banshee fix to autobuild and beagle-search fix to beagle CVS,
where it will eventually make its way into autobuild.

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