Moved to https://invent.kde.org/plasma/kwin/-/merge_requests/70.

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

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

Address review comments:

• Use an enum config to store the click behavior
• Add a kconf_update Python script to migrate existing config files (tested with both Python 2 and 3)

Ping?

Nope, different bugs, similar solutions. I can still reproduce the other bug (I never noticed it before btw). I am not sure if this patch fixes any other regressions other than the Clear History button in the KCM.

Yeah, unfortunately I took notice after submitting the revision.

Is there an ETA for this? Is it worth fixing any bugs in the old applets in the meantime?

It seems to me that this revision does not have the required momentum to move forward. I'll keep it open for another week in case someone else wants to chime in, but unless something changes I'll abandon it and maintain it off tree for personal use.

Bump?

• Make update interval spinbox locale-aware

I am not sure what the proper solution for the i18ncp call is, given that the argument is decimal. Someone more knowledgeable should probably chime in.

I gave it some thought and I would be reluctant to introduce one more fuzzy (as in ambiguous) state.

Accurate analysis. If I might add, as an infrequent user of Plasma Vaults, I am stuck between an (almost) always visible applet (whether I select "Always shown" or "Shown when relevant") and an always hidden applet. A "currently active" relevance would cater for both frequent and infrequent users, with the drawback that frequent users would have to select "Always shown". I'm not particularly ecstatic about the Bluetooth applet taking up unnecessary space 95% of the time, either.

• Add single quotes around the vault name

In D28914#650523, @ngraham wrote:

Can you provide your email address in a comment here so that we can land the patch with the correct git authorship information?

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().

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

• Subsume "Present Windows" toggle into "Switch desktop and activate window"
  • Add tooltip that explains this
• Fix minor issues

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.

Updated UI showing default settings:

Use radio buttons instead of a check box in order to better communicate the expected behavior.

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.

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?

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.