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 level window tray icon" - NOW app maps X; this is actually the moment, in which the systray docking magic takes place - the stuff that I tried to log as mentioned in the previous post, but due to KWin's absence, this doesn't happen; my log code wasn't executed, which made me think, that two different problems exist here; the important thing and also a bit of the design flaw that is the basis of this bug is, that kwins management of the tray icons starts at the first point, but the management of the tray applet in step three; in between KWin disappears so this is basically a communication problem. Thank you for reading -- starting compiz in KDE displaces adept from tray https://bugs.launchpad.net/bugs/131013 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
