D28781: Add 'Activate clicked window' toggle in Desktop Grid effect
Konstantinos Smanis <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kwin |
|---|---|
| Message-ID | <[email protected]> |
ksmanis added a comment. 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. 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: - 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 `QApplication::startDragTime()` (new) rather than instantly (old). - 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 `QApplication::startDragTime()`. 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 (`QApplication::startDragDistance()`), so it makes sense to me to use the same semantics for timings. Screencast of windows flickering without an elevation timer (config set to not activate windows): F8236892: 03_desktopgrid-2020-04-14_11.00.31_window_flickering.mp4 <https://phabricator.kde.org/F8236892> REPOSITORY R108 KWin REVISION DETAIL https://phabricator.kde.org/D28781 To: ksmanis, #kwin, #vdg Cc: 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