<table><tr><td style="">ksmanis added a comment.
</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/D28781">View Revision</a></tr></table><br /><div><div><p>The UI changes absolutely make sense to me, as radio buttons provide a much better explanation of the expected behavior than before. However, I am a bit sceptical about treating the current desktop as a special case (i.e., activating the windows in the current desktop regardless of the config). What's the rationale behind this corner case? Imho, if I want to switch windows in the current desktop I'd use Alt+Tab and inconsistent behavior across desktops would probably throw me off.</p>

<p>The timer bit can be a bit confusing, but it is necessary for the non-activating behavior in order to avoid window flickering (see illustration of the issue at the end of the post), which basically leaves us with two options for the activating behavior:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Follow suit and use the newly introduced timer. This breaks backwards UX behavior only in the following regard: when the user long-clicks (but doesn't move) a window, then the window will be elevated after <tt style="background: #ebebeb; font-size: 13px;">QApplication::startDragTime()</tt> (new) rather than instantly (old).</li>
<li class="remarkup-list-item">Maintain the old behavior of instantly elevating windows when clicked, which would be inconsistent with the non-activating behavior. In other words, if the activating behavior is selected and the user long-clicks (but doesn't move) a window, then it will be instantly elevated, whereas for the non-activating behavior it will be elevated after <tt style="background: #ebebeb; font-size: 13px;">QApplication::startDragTime()</tt>.</li>
</ul>

<p>In either case, clicking and moving behavior is not affected, only when the user long-clicks a window and holds it still. I could go either way to be honest, the UX discrepancy in either case is awfully specific and I doubt anyone would ever notice. Having said that, I would advocate for the uniform timer adoption just for the sake of consistency and keeping things simple. As an extra argument, space-related drag semantics are already present elsewhere in the code (<tt style="background: #ebebeb; font-size: 13px;">QApplication::startDragDistance()</tt>), so it makes sense to me to use the same semantics for timings.</p>

<p>Screencast of windows flickering without an elevation timer (config set to not activate windows):<br />
<a href="https://phabricator.kde.org/F8236892" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">F8236892: 03_desktopgrid-2020-04-14_11.00.31_window_flickering.mp4</a></p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R108 KWin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D28781">https://phabricator.kde.org/D28781</a></div></div><br /><div><strong>To: </strong>ksmanis, KWin, VDG<br /><strong>Cc: </strong>ngraham, apol, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, ahiemstra, mart<br /></div>