Handle clients which change window metadata during early startup
ClosedPublic

Authored by hein on Sep 10 2018, 4:18 PM.

Details

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.

BUG:396871

Diff Detail

Repository
R120 Plasma Workspace
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 2692
Build 2710: arc lint + arc unit
hein created this revision.Sep 10 2018, 4:18 PM
Restricted Application added a project: Plasma. · View Herald TranscriptSep 10 2018, 4:18 PM
hein requested review of this revision.Sep 10 2018, 4:18 PM
hein updated this revision to Diff 41353.Sep 10 2018, 4:20 PM
hein edited the summary of this revision. (Show Details)
hein removed a reviewer: ngraham.

Fix typo in description.

hein updated this revision to Diff 41354.Sep 10 2018, 4:24 PM
hein edited the summary of this revision. (Show Details)

Improve description further.

hein updated this revision to Diff 41355.Sep 10 2018, 4:25 PM
hein added a reviewer: ngraham.

Add back Nate. Now I'm committed to using arc diff --verbatim, sorry. :P

hein updated this revision to Diff 41356.Sep 10 2018, 4:32 PM
hein edited the summary of this revision. (Show Details)

Add conclusion to description. Done now, promise.

I just want to point out that such applications are not ICCCM compliant: This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state, but there should be no need for a client to change its state dynamically.

KWin doesn't support updates to wm_class and e.g. window rules are broken.

hein added a comment.EditedSep 10 2018, 6:25 PM

I just want to point out that such applications are not ICCCM compliant: This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state, but there should be no need for a client to change its state dynamically.

KWin doesn't support updates to wm_class and e.g. window rules are broken.

Preaching to the choir I'm afraid :(. I consider this bad application behavior and called it a concession to badly written apps on Bugzilla (where we get regular user reports about this problem). Unfortunately a lot of the code in libtaskmanager falls into this category.

The upstream bug report has been ignored, and there's a large installed base as this is long-standing LibreOffice behavior. I am eventually considering a backport to the LTS branch of this.

Also, on Wayland the appid can change at runtime in theory (and people hooked this up in Mutter and Weston, so I guess it's been encountered), and the affected code is mostly generic over the two windowing systems.

Ah well. At least this takes the shape of a generic "allow hiding tasks matching some id" feature. It's in practice only needed to handle this app misbehavior, but at least it's not brittle weird code to catch class changes specifically/explicitly.

ngraham accepted this revision.Sep 12 2018, 4:02 AM

Seems to work with LO 5.1.6 for me!

This revision is now accepted and ready to land.Sep 12 2018, 4:02 AM
broulik accepted this revision.Sep 12 2018, 3:39 PM
This revision was automatically updated to reflect the committed changes.