https://bugs.kde.org/show_bug.cgi?id=396871
--- Comment #23 from Eike Hein <h...@kde.org> --- There aren't any "dozens of apps" that do this. What it comes down to is that this is neither a bug in the app nor is it a bug in the Task Manager. Everything is in fact working correctly, it's just that this application behavior is a very bad idea to implement if you want your app to work nicely on a Task Manager. Let's analyze: - LO6 (I can't reproduce this with Thunderbird 60+ on my system BTW) changes WM_CLASS on a window after initially showing it. - We handle this WM_CLASS change just fine. We notice it and react to it and take the appropriate steps. - However: The decision "let's sort this window in where a matching launcher was previously" is only done at the time a new window appears. It's not done when the WM_CLASS changes later. There's good reasos for this: - Even if we decided to re-sort on the WM_CLASS change, the visual result would still be poor (the icon would briefly show at the wrong location, before moving to the right location). - A WM_CLASS change can occur at any time, not just during early startup. Clearly, randomly resorting the Task Manager at any time would not be a very nice thing to for the user. Implementing generic behavior like "do change sorting on the user, but only in the first second" starts to be a brittle system. There's exactly one hacky work-around that's sort of acceptable to implement, and probably what we implement: Extend our rules system to allow writing a rule like "if a new window matches this WM_CLASS, pretend the window doesn't exist until it either changes WM_CLASS for the first time, or a timeout condition is met". The visual result will then be that the launcher spins a little longer until LO6 changes WM_CLASS, making it appear to launch a bit slower (although the window is of course unaffected). But make no mistake, that's yet another concession towars poorly-coded applications that do something that they shouldn't be doing. And it requires whitelisting and therefore manual curation and that makes us sad (at least it's forward-compatible - when LO6 is fixed, the rule doesn't match anymore and the TM can use the usual immediate mode). -- You are receiving this mail because: You are watching all bug changes.
