Probably related to/duplicate of #77895 and #78945

do you mean the klaptop-daemon systray icon?
no problem here.
is there any other /applet/ to provide this functionality?
and is the battery thing the only one that "disappears"
what exactly do you mean by "disappear" is it there and then vanishes (just visually) or is it removed from the tray (or is the applet removed)
what happenes if you deactivate the translucency support by calling 
dcop kwin default stopKompmgr
?

Yes, it's the klaptop-daemon systray icon I'm speaking about. AFAIK there is no other applet.

If I enable translucency support and relogin (kompmgr is started the next login) the klaptop-daemon systray icon is not show. It's completely missing, no empty space or something like that in system tray. If I disable translucency support I have to relogin again to get the icon back.

Klaptop-daemon systray icon is the only thing that behaves this way, no problems with klipper, kgpg, kmix, licq, akregator, ...

could you please ensure that the klaptop-daemon successfully starts up?
(ps -Af | grep klaptop)
if not (???!), what happens if you start it by hand?

There is no program klaptop (even if the icon is shown):

root@logo:~# ps -Af | grep klaptop
root     11272 11247  0 01:21 pts/2    00:00:00 grep --color=auto klaptop

But kded loads a shared lib:
root@logo:~# lsof | grep klaptop
kded      11200  eworm  mem       REG        3,5  128376    8100106 /usr/kde/3.4/lib/kde3/kded_klaptopdaemon.so

This lib is also loaded if translucency is enabled and the icon is not there.

I can confirm this, also missing are the keyboard tool (layout switching), the knemo icons, and in fact anything which is loaded before kwin and kompmgr (by kcminit or kded, for example).

The problem as far as I can tell, occurs when kompmgr calls XCompositeRedirectSubwindows, which causes an unmap of all windows, then remap with overrideRedirect=true;
KWin, upon receiving UnmapNotify (in Workspace::workspaceEvent), calls removeSystemTrayWin;
It never gets a subsequent MapRequest (because of overrideRedirect), so no addSystemTrayWin is called.

Placing an addSystemTranWin in MapNotify resolves the problem. Not sure it's the right thing to do, though...

Same here.  Klaptop is started but not shown in systray:

quini@quinipt:~$ ps -Af | grep klaptop
quini    10441 10413  0 17:54 pts/3    00:00:00 grep klaptop

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

I have "created" a personal work around.  Started because I want to use the -C switch (which allows my superkaramba apps to be skipped by shadow)  I found that if I start kompmgr from the .kde/Autostart folder with a 5 second delay then I get  the batter manager to problem.  What I did was first go into kcontrol and turn off kompmgr, then go to power section, and uncheck the "show batter manager icon" click apply then recheck it, click apply (so it's displayed.)  Now I created the following mini script in ~/.kde/Autostart 


#!/bin/sh
sleep 5
kompmgr -C -c -x 0x000000 -o .90 -r 6 -l -100 -t -100

Saved it chmod 755'd it logged out logged back in and with the 5 sec delay the icon is displayed and then ..... shadows are created.  

I also noticed this issue with KDE 3.4.1, it can be worked around by going into KControl > Power Control > Laptop Battery and disabling, then enabling "Show Battery Monitor". This only lasts a session though, you'd need to do it every time you log in.

I've noticed this problem in other places on the net; people have some highly detailed information and workarounds on it. Unfortunately I lost my links so I can't be more specific. -_- sorry

I also hear that the battery monitor isn't the only thing to be affected.

It's been over 10 months though, and this bug makes laptops with kompmgr very unusable. Would some kind soul please work on this or at least help debug.

If you look at comment #6, I actually debugged this and had a workaround, but since getting no response and losing interest in kompmgr myself, I didn't pursue it further....
If there's interest, I'll recreate my workaround and post a patch.

Remembering what this bug is about, I saw that the XComposite was just
recently changed, (
http://cvs.freedesktop.org/xorg/xserver/xorg/composite/compalloc.c?rev=1.8&view=log),
which should fix the problem.
If you want an immediate workaround, please try this:

In kdebase/kwin/events.cpp, under Workspace::workspaceEvent(), add the
following line:

case MapNotify:
    addSystemTranWin(e->xmap.window);   <----- Add this line.
  return ( e->xmap.event != e->xmap.window );

Unfortunately I don't have a working dev environment, so I can't attach a
patch. At the time when I was researching this bug, the workaround worked
fine with no adverse effects...
<div>Remembering what this bug is about, I saw that the XComposite was just recently changed, (<a href="http://cvs.freedesktop.org/xorg/xserver/xorg/composite/compalloc.c?rev=1.8&amp;view=log">http://cvs.freedesktop.org/xorg/xserver/xorg/composite/compalloc.c?rev=1.8&amp;view=log
</a>), which should fix the problem. </div>
<div>If you want an immediate workaround, please try this:</div>
<div>&nbsp;</div>
<div>In kdebase/kwin/events.cpp, under Workspace::workspaceEvent(), add the following line:</div>
<div>&nbsp;</div>
<div>case MapNotify:</div>
<div>&nbsp;&nbsp;&nbsp; <font face="Courier New">addSystemTranWin(e-&gt;xmap.window);&nbsp;&nbsp;&nbsp;&lt;----- Add this line.</font></div>
<div><font face="Courier New">&nbsp;&nbsp;return ( e-&gt;xmap.event != e-&gt;xmap.window );</font></div>
<div>&nbsp;</div>
<div>Unfortunately I don't have a working dev environment, so I can't attach a patch. At the time when I was researching this bug, the workaround worked fine with no adverse effects...</div>
<div>&nbsp;</div>

Sorry about the HTML junk, here's what I wrote:

Remembering what this bug is about, I saw that the XComposite was just recently changed, (http://cvs.freedesktop.org/xorg/xserver/xorg/composite/compalloc.c?rev=1.8&view=log ), which should fix the problem. 
If you want an immediate workaround, please try this:
 
In kdebase/kwin/events.cpp, under Workspace::workspaceEvent(), add the following line:
 
case MapNotify:
    addSystemTranWin(e->xmap.window);   <----- Add this line.
  return ( e->xmap.event != e->xmap.window );
 
Unfortunately I don't have a working dev environment, so I can't attach a patch. At the time when I was researching this bug, the workaround worked fine with no adverse effects...
 

SVN commit 499345 by lunakl:

A workaround fixing problem with systray icons when kompmgr is running. Real bug
is in X.org, already fixed in their CVS.
BUG: 100177



 M  +10 -2     events.cpp  


--- branches/KDE/3.5/kdebase/kwin/events.cpp #499344:499345
@@ -323,9 +323,17 @@
             return ( e->xunmap.event != e->xunmap.window ); // hide wm typical event from Qt
             }
         case MapNotify:
-
+            {
+#if KDE_IS_VERSION( 3, 9, 90 )
+#warning Consider dumping this workaround.
+#endif
+            // See bug #100177, especially comments #6 and #14. This workaround shouldn't be
+            // necessary when X.org with that fix becomes available and it's an unnecessary
+            // X roundtrip for an experimental unstable feature.
+            if( addSystemTrayWin( e->xmap.window ))
+                return true;
             return ( e->xmap.event != e->xmap.window ); // hide wm typical event from Qt
-
+            }
         case ReparentNotify:
             {
         //do not confuse Qt with these events. After all, _we_ are the

This seems to cause problems with systray icons under normal conditions.

Reverting patch, get fixed X.org, sorry.