[Libreoffice-bugs] [Bug 119202] LibreOffice apps should not change their WM_CLASS values after being launched

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=119202

--- Comment #16 from Jan-Marek Glogowski <glogow at fbihome.de> ---
This is a adapted copy from my brain dump at
https://gerrit.libreoffice.org/#/c/74014 (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 tdf#100158 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 tdf#100158 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190614/5fffdbc2/attachment.html>