starting compiz in KDE displaces adept from tray

Does restarting these apps make them appear in the correct place?

Ive found that adding "sleep 10" before starting compiz works around this problem.

Restarting adept notifier will fix the problem for me. I tried to add a 20 second delay to compiz and the adept notifier icon will appear in the tray before compiz loads. When compiz loads it will get moved to the taskbar. I am using fiesty instead of gutsy.

I'm having this problem, too using:

Kubuntu Gutsy 32 bit (updated daily)
Nvidia 8600 GT (restricted manager Nvidia driver)
Compiz 1:0.5.2+git20070918-0ubuntu5

Mainly with adept notifier and Kcheckgmail, but occasionally also with Amarok. The systray icons just appear in the top right corner of the workspace instead of the system tray. If you can close them they reopen in the correct place, but this isn't alsways possible.

I have the same problem with the adept_notifier icon, using an up-to-date kubuntu gutsy and a X600 ati card. killing adept_notifier and relaunching it puts it in the systray.

Is this going to de fixed ?

Feel free to ask for any debug info.

No, it's not going to be fixed for gutsy. No one knows what or where the problem is and we're really close to release. Compiz is not enabled by default in Kubuntu anyway.

I am running Kubuntu 7.10 with Intel video card and compiz 0.6.0-git20071004-0ubuntu2 and I have the same problem.
I read this somewhere on the forums so I made added the following script to ~/.kde/Autostart
#!/bin/bash
sleep 20
compiz --replace ccp &

Some start the decoration manager like this:
sleep 10
emerald --replace &

But compiz usually starts it automatically is it is the default decorator.

This mostly solve the issue for me, but sometimes I get a emerald crash and/or no decorations at all or even again icon displacement.
So this issue probably has to do something with when compiz is started since a longer wait usually helps.

This is a problem that has been there since the first days of Compiz and neither the Compiz developers nor the KDE developers have bothered to fix this, so the Kubuntu developers will not fix it either because Compiz is not officially supported by Kubuntu. If you want to have good desktop effects in KDE, wait for KDE 4.0 or switch directly to GNOME since, no matter what the Compiz developers say, it is designed with GNOME and only GNOME in mind and so, most distributions have opted to not support Compiz in KDE at all.

I have the same problem. When compiz starts automatically it disrupt the system tray and also doesn't display the title bars.

To solve it, I manually edit the file $HOME/.kde/share/config/ksmserverrc and remove the lines below:

[LegacySession: saved at previous logout]
clientMachine1=localhost
command1=/usr/bin/compiz.real,--ignore-desktop-hints,--replace,--indirect-rendering,--sm-client-id,1016e1b21a414d000119193455500000066010019,ccp
count=1

I save the file and I restart the X with <ctrl><alt><backspace>.

I login again and it solves my problem.

Cheers

Piga

I have the same problem whit Gusty RC. Compiz work perfectly but it expels the Adept Notifier icon from the system tray.

gp

Beryl does this to the Adept Notifier in Feisty as well. To solve that I used some instructions I found on a website somewhere (sorry, can't remember the reference). I have a script /usr/local/bin/startberyl.sh that contains:

#!/bin/sh
export KDEWM="/usr/bin/beryl-manager"
exec startkde

And I also have created the file /usr/share/xsessions/Beryl.desktop, which contains:

[Desktop Entry]
Encoding=UTF-8
Name=Beryl
Exec=/usr/local/bin/startberyl.sh
Icon=
Type=Application

This creates a new menu session entry on the KDM login screen and allows me to start KDE with Beryl(+emerald/whatever) as the window manager instead of kwin. Because it starts up as the original window manager instead of replacing kwin and starts before most other apps anyway, there are no problems with Adept Notifier with this method. Plus it has the advantage of being able to start KDE with or without special effects in case it goes a bit wrong.

Surely the same startup method can be applied to Compiz? I might upgrade to Gutsy in the next few days so will try this myself.

@Colin Pinkey
your solution looks nice and it's working (at least for me).
only one obvious change is needed in first script: beryl-manager to compiz, and everything is working smoothly.

Thanks,
Damian

It didnt work for me. I did'nt see any compiz at session selector at kdm login menu.

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined. According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With 7.10 now released, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates .

The bug is not being closed as work will continue on fixing it for the next release, Hardy Heron (8.04). To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage and https://wiki.ubuntu.com/DebuggingProcedures .

Colin - thanks for the post, that solution seems to work great. I'm running Compiz + Emerald and for some reason, just changing "/usr/bin/beryl-manager" to "/usr/bin/compiz" started KDE without any window manager, but using "/usr/bin/emerald" fixed everything.

Hello,

wanted to confirm this bug (on Kubuntu 7.10 with all updates until now, graphics card is - if this information is useful - an nVidia 7950 GTX or however it is called...^^") and post some things I found out about this; maybe this is useful to someone... (and hopefully someone can understand this crappy English I'm writing here :P); I didn't know where else to write this (my launchpad profile gives me a "Homepage" inside the Ubuntu wiki - can/may I publish such information there??):

At first: None of the mentioned workarounds really worked for me but I found out, that Adept Notifier getting displaced from the tray when you start compiz AFTER session "restoration" (all tray icons already there) and before or within, are two distinct problems; in the second case, this behavior can also hit other applications as mentioned in this bug report: https://bugs.launchpad.net/adept/+bug/47988. For me, it was mainly kBluetooth, but also Amarok from time to time.

I compiled a test KDE environment so that I could insert logging at the interesting portions (the systray "suff") of kdelibs and kdebase.
What I found out now is, that if you start compiz as part of the session, then the windows, that get "displaced" from the tray, actually never get added to it. I placed a log command inside SystemTrayApplet::embedWindow and it doesn't show up in the log file.
If I start compiz after session initialization, the log says, that Adept Notifier got added - but twice; also logging the removal of tray icons showed, that it was also removed several times (my logs are a bit weired so don't hit me, if these numbers are wrong).

I don't know, whether this behavior is correct (I mean, the adept tray icon is hidden and so on ...) but it made me look into adept_notifiers code and I think I narrow the source of the bug a bit:
I have written a very simple kde app (kdevelops "Hello World in KDE") and added a tray icon to it:
tray = new KSystemTray (NULL, NULL); // tray is a KSystemTray *
tray->hide ();
This is in the constructor of my KApplication derivate, which is approximately what adept does without checking for updates and so on.
If I now start this application and start compiz after it, I get - as with adept - a small window in the upper left screen edge, which also shows up in the taskbar (ADDITIONALY to the applications main window).

My conclusion: KSystemTray::hide (which is actually a method derived from Qt's QLabel, which in turn gets it from QFrame if I remember correctly) does something to tray windows, which makes compiz make them top level windows. Actually this also happens with metacity; now I don't know, how much code compiz and metacity share, so I cannot say whether this is a Qt bug or one in compiz's / metacity's common codebase...

If I talk absolute nonsense here and this behavior is normal then just ignore me or write me some insults via e-Mail, but I think this is what makes adept behave like that and if you call that a bug, than it cannot be wanted behavior.
I hope somebody can do something with this and am sorry for flooding this thread with such a long text oO

OK sorry for double posting (and again a probably long message) but I think I've got it.
I think I've discovered the basic problem and also have a possible workaround (more or less); I cannot give you a patch as my idea didn't work, but what I wanted to do programatically directly in KDE can also be done in a start script; and then it actually works.
So what happens: In the previous post I said, that we are looking at two problems actually here and I want to revise my self in this point: It is the same problem but time plays an important role here;
What happens when a tray icon is hidden (KSystemTray::hide) in KDE is actually a removal of that icon from the tray. It becomes a top level window but an unmapped one so it cannot be seen; but it still holds the _NET_KDE_SYSTEM_TRAY_WINDOW_FOR (or however it is called) property, so that KWin remembers to redock it, if it is shown again.
If now another window manager starts up and begins manage all the top level windows, this manager (which includes as far as I tested compiz, metacity, xfwm4 and wmaker), that manager doesn't care about that property anymore. If NOW the icon is shown again, it becomes a standart, mapped top level window.

Another flaw, that is as far as I understand the situation now not directly related to this problem is, that compiz maps unmapped tray windows (i.e. their unmapped top level windows). metacity also does this. This problem is tray icon specific; I tried to unmap a normal window, then start commpiz and the window didn't get mapped...
but this is the reason, why you see the adept notifier tray window in the top left of your screen; after its start up, it is hidden, then compiz starts, maps it and makes it a toplevel window (as stated above, it actually already is one...)

So now the workaround: As can be read in some forum entries about this problem, adding another tray application (!KDE tray application!) to the tray, adjusts all the others (so mostly adept) as well; why is this?
If there is a window manager running, that doesn't support KDEs tray protocol (e.g. compiz), and a KDE protocol tray window is created (CREATED, not SHOWN, so a new one, not an old one redocked), KDE loads the kdetrayproxy module, which - on its creation - goes through all the top level windows, looks for the above mentioned property and docks these windows accordingly.
So the solution to redock displaced icons directly after window manager replacement is to load this module directly after KWin's exit.
I wanted to do this in the code of the tray applet; it should watch the manager selection of WM_Sn (n=screen number) and load kdetrayproxy, if kwin looses it. This didn't work unfortunately, but as said, one can load the module for example in the compiz startup scirpt:

dcop kded kded loadModule kdetrayproxy

I hope this helps;

FOR INFORMATION ONLY and for those further interested: I said, that the displacement of adept and other apps are two different problems and then took that back; so what happens, if another app gets displaced?
- app _creates_ icon X (doesn't show it up until now)
- compiz starts and doesn't care about X's KDE tray property, maps it due to some unknown reason -> "top leve...

Just another FIY and this time a rather short one :P:
Filed a bug about KWin in KDE's bug tracker as I am now completely convinced that every aspect of the here described behavior is a problem of KWin's handling of "tray icon windows" (or maybe more generally QXEmbed widgets, but see the report linked below) and its communication with the system tray applet; and because I want this one to be fixed ;)
It seems to be not related to adept, ubuntu or any specific window manager like compiz.
Bug report here: http://bugs.kde.org/show_bug.cgi?id=157438

I have this problem too, even if I start compiz after kde starts, I always get the adept-notifier icon sent off the tray.
I am on Kubuntu 7.10 64bits updated at today and using a Nvidia card with privative drivers.

this problem still occurs on Kubuntu 8.04 64bit.

This was fixed in kdebase upstream in r783764, just need to get the patch included in Kubuntu.

Looks like it did not get into Kubuntu Hardy - same problem here :(

Julian Kniephoff: Amazing work! Your skills are outstanding! Thanks for the kded workaround.

Thank you Julian Kniephoff, I think it solved my problem. Could you explain the string you mentioned command by command?

Talking about this one:
dcop kded kded loadModule kdetrayproxy

Regards,
Šarūnas.

I just confirmed that the patch is not in hardies kdebase source package (kdebase_3.5.9-0ubuntu7.3), yet. This is also the case for the 3.5.9 tag of KDEs SVN. This one is till at revision 774532 and thus does not include the fix (783764).

I also experienced the bug again in 8.04, but not as often as in previous releases; the "Deksotp Effects"-Settings stuff somehow seems to have found a way of starting Compiz and KDE in an order that "hides" this bug in most cases.
I also noticed it in KDE4 once or twice but _without_ Compiz (but with KDE(4)s compositing manager). This may or may not be another bug, I haven't looked at the code here, yet, what I did check however is, whether my patch was also applied to KDE4s KWin: It isn't.

If I can help to bring this patch into Ubuntu, please notify me, I just don't know how.

Zaar Hai: Thank you very much.
Šarūnas Rimša: If you still need it: dcop is a command line utility to "speak DCOP", the protocol KDE applications use (until version 4) to communicate with one another. "kded kded" selects the application I want to talk to. I'm not that much into DCOP and don't quite know what exactly these two parameters mean ^^". loadModule is the function of the so selected "module" and kdetrayproxy is the argument to this function. This command thus basically means something like "Hey kded, load the module 'kdetrayproxy' for me, please!" I hope this answers your question.

Ah yes and sorry for the (very oO) late reply.

Still an issue here, and driving me crazy! To whoever it concerns, if this really has been fixed already, then please make that release available! Everybody using KDE and Compiz (ya think that might be more than a couple folk?) would really appreciate it.

Which Kubuntu version do you have?
This bug has been fixed for Kubuntu 8.04.1 :)

Fully updated (dist-upgrade) Kubuntu Hardy Heron. In Adapt, since I noticed that it gives you the ability to pick which mirror you want it to use, I told it to use the one provided by kernel.org since it gave me the fastest pings by quite a huge margin and I figure that they're probably pretty responsible (keep their mirror properly sync'd like they're supposed to).

Just out of curiosity -- how is this supposed to be fixed?
I just double-checked again, whether the patch is in the Ubuntu source package of kdebase (of my up-to-date 8.04.1) and it is not (I didn't check the debian/patches folder the last time I stated this - only the "pure" source files - but there, too, no luck).
While I am at it: Confirming the last "still there" comment. As said in my last post, since the "Visual Effects" stuff (the config dialog and so on) got integrated into Kubuntu, the bug "happens" not so often but I noticed recently, that it almost always shows up after logging out and back in. Only after rebooting (or maybe after restarting the kdm service, didn't test this, yet), it doesn't apper again (that much).

@Julian:

I'll try to answer your question. The status of this bug has been sitting at "Fix Committed" to signify that somebody has made a patch that solves the problem. What the status needs to get to is "Fix Released," which is when the solution actually becomes available (and by available, I mean in the form of a package update). This is how I understand it to work.

OK, thanks for the clarification.
Then let me try to bring it to the "Fix Released" state ;).
As said already and as you may have noticed, I am not that much into Ubuntus packaging infrastructure, so contact me if the following is crap:
I prepared two debdiffs - two because I didn't know whether to use the source packages (or the *.dsc's to be precise) or the binary packages, so I made both ;). They are attatched to this (the one for the source packages) and the following (the binary one) comment (and not marked as patches, I hope this is right...).
I also uploaded the source package, which I made for this, to my PPA, where the binary packages are just being built, so keep an eye on it.

As said, the other debdiff...

I'm just a user, but thanks for your work, Julian! Since there are so many people who use KDE and Compiz, I'm sure that the developers will also be happy to see what you've done. I can't wait until it makes "Fix Released," so hopefully it'll get reviewed really fast so that I can download the update soon!

To any developer that reads this: I'll love you forever if you release the fix really quickly. :P

We currently have KDE 3.5.10 in hardy-backports and I'm working on getting that into the regular updates. Please try with 3.5.10 and if this is still a problem (I don't use compiz) see if the patch works with 3.5.10.

OK, thats good news, thanks Scott.
The patch should already be in KDE 3.5.10 according to the revision number of the kwin files in KDEs SVN (849627). The patch was committed in revision 783764.
So it should work. However, if it doesn't I'll have a look ;).

Then if someone who is having this problem could try KDE 3.5.10 in
hardy-backports and verify the problem is solved, that wouild help make the
case for moving it to hardy-updates.

Hmm. I enabled the backports repository and upgraded everything to try to test this, but now the entire kicker doesn't work, and that's with or without Compiz! The panels appear for a second and then immediately crash, and the KDE Crash Handler pops up. Here's the backport it offers:

http://pastebin.com/f1a16c4fb

I may need disable this repository and revert to 3.5.9 because of this. I'll hold off doing that for a day in the hope that the kicker problem gets fixed. When it does get fixed, I'll let you know if the original bug is indeed solved for me.

Sorry for double posting. The new bug that I experienced is https://bugs.launchpad.net/ubuntu/+source/kicker-taskbar-compiz/+bug/261694 and I was able to solve it by reading what other people did.

So, now that the kicker is working, I can confirm that the KDE system tray seems to be working like it should even with Compiz enabled. Maybe somebody else can confirm that it works for them after upgrading to KDE 3.5.10 in case I'm just lucky.

Just upgraded to the backported 3.5.10 packages:
I cannot say something about bug #261694, Kicker does not crash here.
It seems to work here: I logged in and out several times and all tray icons are in place _except_ when my dcop server (silently) crashes. This however is a seperate problem, as it also happened to me with 3.5.9 (and I think also .8?). This behavior (of the icons, not dcop ;)) is expected though, because the patch -- which is applied in the 3.5.10 source packages, checked -- uses dcop to bring the icons in place. So if dcop crashes for some unrelated reason, this is not in the scope of this bug (and thus this patch).
Seen from this bugs perspective only, the backport thus works for me, too, so go for hardy-updates! ;)