<table><tr><td style="">hein created this revision.<br />hein added reviewers: Plasma, mart.<br />hein added a subscriber: plasma-devel.<br />Restricted Application added a project: Plasma.</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/D2347" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Different versions of Qt (or maybe it's the position of Jupiter-vs-<br />
Saturn) seem to behave differently with regard to whether delegates<br />
in a Repeater+Flow package initially appear at 0,0 and then get moved<br />
into position, or directly appear at target geometry. This is despite<br />
the fact that we already layout before changing delegate visibility<br />
to true.</p>

<p>The former behavior causes various problems. One of them is that after<br />
clicking a launcher, a new task delegate can be under the mouse cursor<br />
initially (even though it never shows up in a rendered frame - this<br />
only matters for event checks) causing containsMouse to be true and<br />
then never to go false as the item is moved from under the cursor<br />
(which Qt Quick's hover handling famously can't handle). Another is<br />
that we export delegate geometry in global coordinates to kwin so it<br />
knows where to animate window minimization to, and this needs to be<br />
the correct (i.e. 'final-initial') geometry.</p>

<p>Previously, we tried to handle this by only enabling hover event<br />
handling and doing the initial geometry export on two triggers:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">onVisibleChanged(true) && index == 0 + boolean fence=false</li>
<li class="remarkup-list-item">onXChanged + boolean fence=false</li>
</ul>

<p>This worked, but breaks the case where an item actually appears at<br />
the desired final-initial geometry directly, so not causing an<br />
onXChanged.</p>

<p>After brainstorming we couldn't come up with a better alternative<br />
than a trigger. Exploiting Flow's add transition seems to error-<br />
prone given various gotchas mentioned in the docs, and delaying<br />
things by one event loop iteration is too brittle, since we don't<br />
know exactly how this interacts with scene graph positioning.</p>

<p>So this changes things to a singleshot timer, which is created and<br />
started whenever a task is completed or changes its type to window<br />
(the latter for the geo export). The duration matches what the<br />
Flow move animation is set to (now ported to units) to make sure<br />
it can't interfere.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>rPLASMADESKTOP Plasma Desktop</div></div></div><br /><div><strong>BRANCH</strong><div><div>Plasma/5.7</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D2347" rel="noreferrer">https://phabricator.kde.org/D2347</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>applets/taskmanager/package/contents/ui/Task.qml<br />
applets/taskmanager/package/contents/ui/TaskList.qml</div></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>hein, Plasma, mart<br /><strong>Cc: </strong>plasma-devel, ali-mohamed, jensreuterberg, abetts, sebas<br /></div>