<table><tr><td style="">hein created this revision.<br />hein added reviewers: davidedmundson, broulik.<br />Herald added a project: Plasma.<br />hein requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D15410">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Some apps initially show their window with bogus/useless window<br />
metadata and then update to useful metadata during early startup.<br />
For example, LibreOffice sets WM_CLASS to soffice/Soffice and<br />
then updates to libreoffice-writer/libreoffice. This leads to<br />
a poor user experience on particular the Icons-only Task Manager,<br />
but also the regular Task Manager depending on settings.</p>

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

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

<p>Simply changing the code to sort things again on any metadata<br />
change would not have been good enough: Metadata changes can<br />
occur at any time, and things shouldn't move around on the user</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">this sort mode is called "Manual" for a reason. Also, the</li>
</ul>

<p>visual result would still be poor: The window would initially<br />
appear at the wrong position, then move into the right one a<br />
short moment later.</p>

<p>This patch takes the following approach:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">It adds a new config key to taskmanagerrulesrc that allows listing ids used to completely hide tasks if they match, and of course the code needed to implement this.</li>
<li class="remarkup-list-item">It adds LibreOffice' bogus initial metadata to this key, so the tasks is initially hidden.</li>
<li class="remarkup-list-item">It skips over hidden tasks in the sort insert queue instead of moving them.</li>
<li class="remarkup-list-item">It resorts when tasks are unhidden (i.e. once the metadata update has occured and the task no longer matches the above config key).</li>
</ul>

<p>BUG:396871</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R120 Plasma Workspace</div></div></div><br /><div><strong>BRANCH</strong><div><div>master</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D15410">https://phabricator.kde.org/D15410</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>libtaskmanager/taskmanagerrulesrc<br />
libtaskmanager/tasksmodel.cpp<br />
libtaskmanager/tasktools.cpp<br />
libtaskmanager/tasktools.h<br />
libtaskmanager/waylandtasksmodel.cpp<br />
libtaskmanager/xwindowtasksmodel.cpp</div></div></div><br /><div><strong>To: </strong>hein, davidedmundson, broulik<br /><strong>Cc: </strong>plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart<br /></div>