Version: (using KDE 3.5.8) Installed from: Ubuntu Packages OS: Linux Hello, I've noticed some odd behavior in kwin; at first I thought, that it was a bug in compiz or _maybe_ kicker / it's tray applet because the main symptom of this bug is the displacement of adept notifiers (kubuntus update manager) tray icon from the tray when starting compiz (so the icon is - after starting compiz - a top level window in the upper left of the screen; with decorations and all the stuff). Some of you might have heard about that; it can be read in diverse forums about kubuntu and also on launchpad: https://bugs.launchpad.net/bugs/131013 While investigating on this bug, I also found a comment in a forum, that this bug will never be fixed because nobody knows whose fault (KDE's or Compiz') it is and Compiz is designed for GNOME anyway, but I investigated further and am now mostly sure, that it is a KDE bug. So I'm posting this bug here to draw KDE developers attention to this problem to 1. proof the above person wrong and 2. to get this fixed eventually ;) SOO, parts of my thoughts can be read on that launchpad report but I'm gonna summarize the main issues here again: Adept Notifier has a KSystemTray; after it's creation, the app shows this icon, checks for updates and then hides it (KSystemTray::hide). For the tray applet this means, that it removes it's QXEmbed widget, that was holding the icon until then; the consequence is, that the icon is now a top level window but unmapped, so it cannot be seen. To get it back to the systray when it is shown again, the window still holds the _KDE_SYSTEM_TRAY_WINDOW_FOR property. BUT if now another window manager is started, that does not support KDE's tray protocol - e.g. compiz, but also metacity, xfwm4, wmaker - it doesn't care about that property any more; on KSystemTray::show, the icon is just displayed as a top level window. If now another program with a KSystemTray is started, it's icon gets docked correctly and also the displaced one gets "back home"; this is because constructor of KSystemTray calls KWin::systemTrayWindowFor, which in turn checks, whether the currently running WM supports the KDE tray protocol and loads the kded module "kdetrayproxy" if it doesn't, which then checks all top level windows for the above mentioned property and redocks them accordingly. One solution to this problem is to load this module directly after kwin's death; As mentioned, I couldn't get that to work inside KDE's code, so here for example I would need some help from the developers ;); but the solution works if executed from a script with the dcop program. There is another problem more or less related to this one; Above I said "If the icon is then shown again" (after hiding it and starting another window manager) but this is actually not needed; It is already shown BEFORE e.g. compiz startup; I don't know whether this is wanted behavior but I found out, that kwin - on it's exit - maps hidden tray icons; One cannot see them if one just kills kwin (as one can when starting compiz right after that), but they definitely get mapped; they recieve a MapNotify event and xwininfo states a map state of IsViewable. This behavior seems to be somewhat tray icon specific; I think it has something to do with QXEmbed; I wrote a small test application which embedded one window into another and then hides that embedeed window; after killing kwin, the embedded window was again visible INSIDE the embedder, so this case is still different to that of the tray icons, which actually get UNembedded, when hidden; reproducing that behavior with my test app didn't work... another point, where developers could help as they know the behavior of QXEmbed and KWin way better than me ;) That's it I think, sorry for a text of the length of nearly four textboxes (on my screen) ^^" but at least there are many information in and not just "compiz doesn't work" ;) Thanks to everybody in advance.
Well, the reality is that you are supposed to use KDEWM to launch a window manager in KDE (as said e.g. in https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/131013/comments/12) and not use any ugly autostart hacks that cause such trouble.
OK first: Sorry for the late reply. Another very long text is following so sorry in advance for that; for those not interested in an argument about whether this is a bug or not just read the summary at the end ;) OK, at first I think in the world where KDE comes from - namely the free software world - no user is _supposed_ to use software in a specific way; isn't that part of the basic philosophy of that world? Of course, a user acting against the developers' advice has to come along with the consequences, but that's actually what I'm trying to do here. But I want to remain factually here and not argue about philosophy ;) I mean: Fortunately there are rules for the interaction of window managers, even if NOT started and killed at session beginning/end and WITHOUT an environment variable... If kwin cares about being replaced by another window manager (which it does as several parts of its code are dedicated to such cleanup work), it should do it correctly, so that another WM can do its work unconcerned about tray icons which are actually top level windows... And if it can be pointed out, that kwin is the source of this problem (or as in this case rather a communication problem with kwin and the tray applet...), then this is a bug in that program which should be fixed and not worked around with another "specifity" (can you say that in English? oO). And as far as I know now THIS is reality and not the "ugly [compiz] autostart hack that cause[s] such trouble" but I may be wrong so please falsify and/or correct the theory above; this is nevertheless the reason why I post here. BUT BACK TO FACTS: You pointed me back to the launchpad report and please be sure that I read that one completely; and as you also may have read, none of the mentioned workarounds really worked for me. Concerning your specific "KDEWM-trick": Yes, this one really seems to work now (after some more hours of testing) but it also seems to summon some other bugs but that's not the topic of this bug report; two other things keep me from being satisfied with this solution: First, as mentioned before this is just a workaround for what seems to be a bug to me; switching window managers during the session will probably still make problems. Second, in the special case of compiz (I didn't test it with other WMs), when logging out, compiz gets written into ksmserverrc as a restartProgram so when logging back in again, compiz gets started twice, which can make the problem of displaced tray icons happen again (which is a behavior that I cannot really explain with my hypothesis). Even after putting compiz and /usr/bin/compiz.real into the excludeApps of ksmserverrc AND passing --sm-disable to compiz in its start script, this happens from time to time. This may or may not be another bug or a configuration mistake on my side but again, this is not topic here, I just wanted to show what happens when working around a bug instead of fixing it. SUMMARY: I still think that the described behavior is a bug and also still think that it is on KDEs "side". Juat working around it is no acceptable long term solution. So please KDE developers help me get this fixed. Thank you.
I probably wasn't clear enough, so let me explain better: KDEWM is the ONLY supported way of switching window managers in KDE. It is no trick or anything, it is the only proper solution. And sorry, but I really don't feel responsible for the fact that Compiz developers don't know how to properly (re)start it. If you switch a window manager while in KDE, you're suggested to restart KDE in order to avoid any possible problems caused by things suddenly being different (or, alternatively, since you mentioned free software world, feel free to send patches to handle all the relevant issues). So, if you want this fixed, report the problem to Compiz developers and tell them to fix the starting (namely, the usage of KDEWM instead of autostart, and the broken session restore).
Created attachment 23808 [details] Patch for KWin to stop the system tray icons to behave oddly without KWin (and KDEWM) OK if you say KDEWM is the only supported method then I can't say anything against that but only appeal to the developers to support other ways and in this special case of handling tray icons, this turned out to be actually really easy, but more on that later. If switching WMs within a session is not supported by KDE, then you are right, the described behavior isn't a bug then and its correction is not your responsibility, but you can't blame Compiz on this, too, because 1. it is not the only WM to act that way (as I already pointed out) and 2. starting KDE with another WM becomes basically a configuration issue without the "switching support" and is thus more or less in the hand of the user or the distrubutor. But that only as a side note. The session restore may or may not be compiz' fault and I will investigate on that in the future. You "motivated" me to write a patch on my own which is what I wanted to do since I got this bug and thus I asked for help here, but now I've come up with one on my own which I want to propose here: The first change loads kdetrayproxy on kwin's exit. This ensures, that there is always "someone" who looks out for tray windows that are hidden which means "undocked", so unmapped top level windows with the KDE Tray property on them. The problem was that if they were shown AFTER KWins exit, they didn't land in the tray because without this change, kdetrayproxy is only loaded on tray icon creation. If somebody needs further explanation, please ask, I'm afraid I cannot really express this complex process properly with my English... I'm also not sure whether the loading of kdetrayproxy at tray icon creation time is still necessary then... The second change removes tray icons from KWins (X)SaveSet when they are unmapped (and thus undocked and removed from KWins internal list of tray icons). This works araound the behavior that on KWins exit hidden tray icons get mapped which is in turn because of the SaveSet, which maps the windows in it when the owning client (KWin) exits. The patch is written against the standard 3.5.8 release tarball of kdebase, because this is the version it was reported for (actually it was reported for the Ubuntu packages but I couldn't get the source packages to compile...^^"). If you want me to port it to another version, please contact me. If something speaks against one of these changes, please inform me about that as well, else I hope that this patch gets accepted and that I could help. (Ah and a last question: should I reopen this bug when attaching a patch?) Thank you.
Committed, r783764. Yes, when attaching a patch it's better to reopen to make sure it doesn't go unnoticed forever because of the status. That doesn't mean the bugreport can't get closed again though.