Summary: | system tray icons get mapped, undocked, ... on kwin exit | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Julian Kniephoff <me> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Patch for KWin to stop the system tray icons to behave oddly without KWin (and KDEWM) |
Description
Julian Kniephoff
2008-02-08 17:48:01 UTC
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. |