<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - LibreOffice apps should not change their WM_CLASS values after being launched" href="https://bugs.documentfoundation.org/show_bug.cgi?id=119202#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - LibreOffice apps should not change their WM_CLASS values after being launched" href="https://bugs.documentfoundation.org/show_bug.cgi?id=119202">bug 119202</a> from <a class="email" href="mailto:glogow@fbihome.de" title="Jan-Marek Glogowski <glogow@fbihome.de>"> Jan-Marek Glogowski</a> <pre>This is a adapted copy from my brain dump at <a href="https://gerrit.libreoffice.org/#/c/74014">https://gerrit.libreoffice.org/#/c/74014</a> (a potential fix), with my current understanding the problem. Normally you have a binary and then multiple "one icon : one WM_CLASS string : one window". That association isn't supposed to change, so the Gtk and KDE developers think / say. If the window is created, it's WM_CLASS metadata shouldn't change (and I guess the icon too?). That's the (paraphrased) title of this bug after all. Now LO has a problem: 1. LO just has one binary but separate icons and brand names for it's modules 2. The loaded document type may change the icon and name / WM_CLASS of the window So the window manager developers assumption of the fixed "one icon + one WM_CLASS string + one window" is broken by LO. Maybe there is some definition / agreement not to do this, but fact is it is allowed by the protocol. It's not that LO is somehow circumventing anything. One suggestion was to change LO to destroy / recreate the window on document / brand change, but that is expensive and would be really disturbing for a user. The first thing that breaks now is the grouping, based on WM_CLASS in general. The 2nd thing the pinning of applications, like Pauls problem. That is actually not easily fixable, as the originally started program, e.g. Writer, might later be an Impress window when pinned. The content always sets name and icon (just imagine --writer as an empty writer document). Actually it's kind of fixable, like <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WORKSFORME - grouping processes doesn't work in gnome-shell/wayland" href="show_bug.cgi?id=100158">tdf#100158</a> did, because you can change the program parameters and names at runtime too. Heck we do this in the qt5 backend when we create our QApplication, because we have to prevent Qt's own session management, as LO handles this itself. And the current patch maybe also isn't a complete fix. gtk3 also changes the WM_CLASS (and should do the same for the icons IMHO) for all child windows. AFAIK the best solution would be to set WM_CLASS, keep the program name but change the parameter. But that would be even more unexpected and I don't think it would work with current WM implementations. And OTOH <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WORKSFORME - grouping processes doesn't work in gnome-shell/wayland" href="show_bug.cgi?id=100158">tdf#100158</a> changes the application name to the icon name to match grouping on Wayland :-) I'm not sure yet, that there is an always working solution, but can imagine a best effort one. I know LO requirements are very uncommon here, but than it's nothing changeable without a massive rewrite how LO is working; not feasible; not even taking any "improvement" vs "time spend" into account.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>