To be honest, I don't really understand why this is a necessary option.
Maybe someone from the VDG can shed some light?

This patch is just scratching a personal itch. I always found it counterintuitive that the underlying window would "steal" the click; I just want to switch Desktop when triggering a Desktop Grid and not tiptoe around windows trying to remember which one was last activated when I left the desktop. I would say it makes more sense if "Present Windows" is off as well.

So in essence you want to use the Desktop Grid effect as a virtual desktop pager, rather than a window picker. But why not just use the pager then?

In D28781#646899, @ngraham wrote:

So in essence you want to use the Desktop Grid effect as a virtual desktop pager, rather than a window picker. But why not just use the pager then?

Indeed, I guess I use the Desktop Grid effect as a fullscreen pager. In my experience, the pager widget is too small to be efficient, selecting the right desktop with the mouse (or even worse with the touchpad) is time-consuming for me.

As a matter of fact, in my workflow, I navigate virtual desktops using the Meta+Left/Right keyboard shortcuts most of the times, but occasionally my hand will be on the mouse, in which case I have assigned the bottom right corner to trigger the Desktop Grid effect and then I just select a desktop. This way, it takes some very generic and easy-to-get mouse gestures to select a different desktop. In this workflow, the default behavior of activating the underlying window gets in the way for me, as I frequently have to pause and determine which window was last active so as not to disrupt it.

That being said, I can see how my perspective is different that the default intended functionality, which is why I maintained backwards compatible behavior in the patch, unless the user explicitly disables it.

Thanks for the explanation, that makes sense to me. I think this could probably work, with an adequate UI to communicate it to the user. See inline comment below.

I'm not sure the new timer behavior makes sense for the status quo. That seems unrelated to the change you're proposing here and would represent a potentially unwelcome UX change for people who are happy with the way it works right now.

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):

Updated UI showing default settings:

Yeah, you're probably right about clicking on windows in the same virtual desktop.

I had another thought: the "Use present windows effect to layout windows" setting now only makes sense when using the "Switch desktop and activate window" effect. Perhaps we could remove that option and invoke its effect automatically when using "Switch desktop and activate window", but then it off when using "Switch desktop only". This would be a visual cue for the interaction mode you're currently using. And we could get rid of a now-redundant setting in the config window, which is always a plus.

What do you think?

I agree for the most part, with some considerations. Indeed, the "Present Windows" toggle does not make much sense coupled with the "Switch desktop only" setting, since the point of the "Present Windows" effect is to actually select one. Nevertheless, users that currently have the "Present Windows" setting turned off, will be surprised when they are suddenly greeted with the Present Windows effect upon upgrading. Perhaps the "Present Windows" toggle could be a substate of "Switch desktop and activate window" setting, but that's the extent of my personal opinion as a user, the rest is a UX choice I guess.

Personally I think it would be fine to remove that existing setting and make it entirely controlled by your new one. This is a really esoteric config UI; I very much doubt that the number of users who have deliberately used that setting can be counted on the fingers of two hands. :)

Great, that part works now! However when using the new setting, clicking on a window still brings that window forward in addition to switching the virtual desktop. Seems like a regression in that part of the patch.

Apologies, I hadn't updated the test plan screencasts; it is now fixed.

But you didn't update the patch. :) The problem I'm seeing is that selecting "Switch desktop only" still activates the clicked-on window, even though it doesn't activate the present windows effect.

How are you getting this result? As shown in the second screencast, once the "Switch desktop only" option is selected, the clicked window is not activated, unless moved or long-clicked for QApplication::startDragTime().

Bump?

Ping?

KWin @zzag @davidedmundson ping.

Also we have since moved to GitLab; you might get a better response at this point by abandoning this revision and moving ir to a GitLab Merge Request at https://invent.kde.org/plasma/kwin/-/merge_requests.

See documentation at https://community.kde.org/Infrastructure/GitLab

You can update users' config filed with a kconf update script (see https://techbase.kde.org/Development/Tools/Using_kconf_update) or avoid changing the config file key names in the first place.

I am in favor of merging this. @davidedmundson or @zzag any thoughts ?

Before merging, ti needs a kconf update script to migrate existing config files, or else it needs to not rename config file key names.

Please review my radio button wiring in effects/desktopgrid/desktopgrid_config.cpp. Is there a way to automate this mapping (i.e., have the framework manage the widgets)? One downside of this wiring is that the Defaults button is not properly updated when a radio button is clicked. The same issue occurs in the Desktop name alignment combo box (unrelated to the patch).

Apparently QButtonGroups are not supported by KConfigDialogManager (i.e., they cannot be managed automatically). I guess the manual wiring would have to do, otherwise a separate QGroupBox is warranted (as it is supported by the framework).

Thanks ! Any chance you could submit this as a merge request on https://invent.kde.org/plasma/kwin/? It will probably get more review eyeballs now that we have moved patch review over there.