and at my ~/.local/share/applications/  directory there is no writer.desktop file

Looks like the same issue as with Bug 394610 for Virtualbox. Needs a downstream fix or an exception/workaround in taskmanagerrulesrc.

Eike, how should we proceed?

Michail, depending on the TM configuration (e.g. with the defaults) this video seems to show correct behavior. Can you explain what you expect to see instead?

(In reply to Eike Hein from comment #3)
> Michail, depending on the TM configuration (e.g. with the defaults) this
> video seems to show correct behavior. Can you explain what you expect to see
> instead?

In the video is an icon-only plasma taskmanager for which  I havent changed something. So launchInPlace flag is set to true, windows should be shown at the same position with their launchers. In the same taskmanager when we click dolphin then the dolphin window is shown at second index immediately in the place of dolphin launcher, but for Libreoffice this isnt happening, the launcher is removed at it place and the window is shown at the end.

Thanks :) I'm a bit busy these days preparing for travel (Akademy) and writing some other code but will try to look into it before vacation in mid August ...

It looks like the same sort of issue as Bug 394610: StartupWMClass doesn't match WM_CLASS so we need an upstream fix and/or a local workaround in taskmanagerrulesrc.

The problem here is that LibreOffice first maps a generic window with class "libreoffice LibreOffice 6.0" and only after that changes it to "libreoffice libreoffice-writer"

That makes sense - while we can handle the WM_CLASS changing at runtime just fine, we make the filtering/initial-placement decision the first time a new row appears in the model, not when the app id changes.

After thinking about it, I think I have to WONTFIX this. In manual sort mode, it feels wrong to move a window task around just because it changed WM_CLASS (which it could at any time). I don't want to go from a "determine good initial placement" to a "move tasks around on the user" model. This should be changed in LO if it wants to work better with DEs.

Filed a bug for the LibreOffice folks: https://bugs.documentfoundation.org/show_bug.cgi?id=119202

Let's see what they say.

*** Bug 398013 has been marked as a duplicate of this bug. ***

So far they haven't said anything. :(

Something tells me we're going to get a lot of duplicates of this. Distasteful though it may be, we may want to consider a local workaround.

(In reply to Nate Graham from comment #12)
> So far they haven't said anything. :(
> 
> Something tells me we're going to get a lot of duplicates of this.
> Distasteful though it may be, we may want to consider a local workaround.

This upstream issue has more implications. For LibreOffice I am using kwin rules in order for the titlebar to force a specific color palette (that way I can match the titlebar with the libreoffice theme used in it). Even though this was working for LibreOffice 5, it doesnt for LibreOffice 6.

In order to apply that kwin rule I have to re-enter at RightClick TitleBar->More Actions->Special Application Settings and click Ok.

My guess is that it is the exact same thing...

*** Bug 398013 has been marked as a duplicate of this bug. ***

I'm seeing the same issue with other apps, including thunderbird and gimp. This isn't isolated to just libreoffice-writer.

(In reply to Jeff Hodd from comment #15)
> I'm seeing the same issue with other apps, including thunderbird and gimp.
> This isn't isolated to just libreoffice-writer.

for thunderbird possibly is the same issue 
for gimp it might be: https://bugs.kde.org/show_bug.cgi?id=396843

When I run xprop against thunderbird, I'm seeing WM_CLASS(STRING) = "Mail", "Thunderbird", so is this another case of WM_CLASS changing at runtime?

The problem exists with qTransmission as well, btw.

What version of Thunderbird? I see the same with 52.9.1 but for some reason it doesn't trigger this bug for me.

60. but it's been this way for a long while.

Could someone file a seperate ticket for Thunderbird with the following information:

a) xprop output for the Thunderbird window
b) the name and location of its .desktop file
c) the contents of its .desktop file.

I'm currently back from holiday and trying to get back into things, and convoluted multi-app tickets are too much chaos for things not to fall on the floor.

I'm not convinced this is a thunderbird bug or a libre-office bug, or, for that matter, a bug in the dozens of other apps where this issue manifests. This is far more likely to be an issue with plasmashell:taskmanager or some other DE component (windowmanager?) that's not providing the ability to reconcile changes to wm_class - it was indeed pointed out that apps can and do change wm_class, so I doubt this will be viewed as a bug at the app level.

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).

BTW, re-reading your comments on the ticket I think you're confused about the xprop outout. WM_CLASS consists of two strings. I think you thought seeing two strings means it changed. That is not the case. Thunderbird and qTransmission (I use both myself) don't do what LO6 does.

I understand that wm_class contains 2 strings, but, for example, "caprine" and "Caprine" are a different difference than "Mail" and "Thunderbird", or "transmission-qt" and "transmission". I've been using Michail's software for quite some time and I'm seeing fairly consistently that the odd launcher behaviour he describes occurs with apps that have fundamentally differently wm_class strings. Perhaps I'm not fully understanding the issue, but I am contributing my observations.

It's quite OK and expected for the two components of WM_CLASS to be substantially different. In general the relevant one for identification purposes is only the second string, which should match a .desktop file name or the value of a .desktop file's StartupWMClass key (the Task Manager also tries many other things to identify apps beyond that, if apps get this wrong). The issue with LO6 is that this second string changes during startup from something generic no .desktop file exists for (and that doesn't match the launcher) to the eventual one that does.

OK. I understand. Thunderbird and QTransmission do conform to expected behaviour then.

However, both also display the same odd launcher behaviour Michail describes, and they do not appear to fall into the same category as the gimp bug.

Do we have yet a 3rd class of bug here then?

I inserted myself into this thread after emailing Michail about the annoying thunderbird behaviour, which is made more annoying since I run it at all times throughout all my sessions. He pointed me in this direction, but apparently we have a case of same strange behaviour, different bug.

And that's why I wrote comment #21 earlier ...

Yeah, but I don;t think it's a thunderbird bug, either, since the same behaviour crops up in other apps. That was kinda my response to your comment.

That seems to be another misunderstanding then. I want you to open a new ticket on bugs.kde.org.

Will do.

Also... this is not a new problem introduced with LO 6.x

It also affected previous versions.

These bug reports, although marked as resolved fixed

https://bugs.kde.org/show_bug.cgi?id=385619
https://bugs.kde.org/show_bug.cgi?id=385594
https://bugs.kde.org/show_bug.cgi?id=385942

never resolved the issue on my system, the LO icon still 'jumps around'...

... and the last paragraph of this comment on the LO bug tracker also indicates there has been no change in LO's behaviour

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

Here's a mitigation approach to this problem for review: https://phabricator.kde.org/D15410

Git commit b15eaf38b6bf8d5af7fdc0caff05679a063819cf by Eike Hein.
Committed on 12/09/2018 at 15:33.
Pushed by hein into branch 'master'.

Handle clients which change window metadata during early startup

Summary:
Some apps initially show their window with bogus/useless window
metadata and then update to useful metadata during early startup.
For example, LibreOffice sets WM_CLASS to soffice/Soffice and
then updates to libreoffice-writer/libreoffice. This leads to
a poor user experience on particular the Icons-only Task Manager,
but also the regular Task Manager depending on settings.

Depending on its configuration (and Icons-only Task Manager is
a particular set of configuration options, as far as the model
is concerned), TasksModel will try to sort a new window task
adjacent to its launcher task. The appearance of a new window
task also causes matching (in terms of identification) launcher
or startup tasks to be filtered out. To the user, this forms a
lifecycle of the launcher being replaced by the window in-place
(and a startup state inbetween, optionally but by default).

Prior to this patch, this sorting decision was only done once,
when a new window enters the source model stack. This meant the
LibreOffice window would initially be sorted into the "wrong"
spot (the bogus metadata doesn't allow us to relate it to its
launcher) and then, following the metadata change, stick to the
wrong position.

Simply changing the code to sort things again on any metadata
change would not have been good enough: Metadata changes can
occur at any time, and things should not just move around on
the user - this sort mode is called "Manual" for a reason. Also,
the visual result would still be poor: The window would initially
appear at the wrong position, then move to the right one a bit
later.

This patch takes the following approach:
* It adds a new config key to taskmanagerrulesrc for listing
  ids of matching tasks to completely hide, and of course the
  code needed to implement this.
* It adds LibreOffice' bogus initial metadata to this key, so
  the tasks is initially hidden.
* The sort code skips over hidden window tasks in the sort
  insert queue instead of moving them. The queue is marked as
  stale then, and cleared on unrelated windowing system changes.
* It resorts when tasks are unhidden (i.e. once the metadata
  update has occured and the task no longer matches the above
  config key).

The visual result is that the startup notification on the
launcher spins a little bit longer than before, even though the
window has already appeared (although LO lags in filling in its
contents anyway), and then morphs into the window task
representation once the client has completed the window metadata
change. This happens in such a short order as to be more or less
imperceptible.

If startup notifications are turned off it's broadly the same,
minus the spinning.

Reviewers: davidedmundson, broulik, ngraham

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D15410

M  +1    -0    libtaskmanager/taskmanagerrulesrc
M  +105  -52   libtaskmanager/tasksmodel.cpp
M  +27   -1    libtaskmanager/tasktools.cpp
M  +1    -0    libtaskmanager/tasktools.h
M  +4    -3    libtaskmanager/waylandtasksmodel.cpp
M  +6    -3    libtaskmanager/xwindowtasksmodel.cpp

https://commits.kde.org/plasma-workspace/b15eaf38b6bf8d5af7fdc0caff05679a063819cf

*** Bug 396843 has been marked as a duplicate of this bug. ***

*** Bug 395470 has been marked as a duplicate of this bug. ***

This issue has reared it's head once more.

This time possibly(?) due to a  change in LO as I'm guessing there's been no change to Eike's workaround.

See comments number 2 and onward at:

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