Look-and-feel

User accidentally doubleclicks item and all their look-related settings are gone. Has to configure everything again.

Splash Screen

User accidentally doubleclicks item, nothing visible happens, gets suprised on next login.

Since the feature is "secret" and unintuitive (as the apply button suggests "click what you want, except action buttons"), this probably can't be even called "accidental doubleclick".

Generally +1, but let's disable it for destructive kcms.

From the old review:

pino:

-1 for this:

    hidden feature
    it does not make sense when the general paradigm is OK/Apply/Cancel, so we are teaching users that options are applied only when OK/Apply is pressed (and thus they are left free to play with options as they fit)
    if an user accidentally double-clicks, then the options are saved a) against the user choice b) with no feedback at all

marco:

>also, as the principle of the feature i agree with Pino

We've never used double click in our UIs, it seems extremely odd to bring it in as an action now.

In D22102#486968, @davidedmundson wrote:

From the old review:

pino:

-1 for this:

    hidden feature
    it does not make sense when the general paradigm is OK/Apply/Cancel, so we are teaching users that options are applied only when OK/Apply is pressed (and thus they are left free to play with options as they fit)
    if an user accidentally double-clicks, then the options are saved a) against the user choice b) with no feedback at all

Indeed, thanks for quoting arguments that were (purposefully?) ignored...

Maybe I should move back and examine the rationale for the proposal.

Right now, I find it *extremely* annoying, slow, and frustrating to test new themes, colors, icons, wallpapers, etc. The workflow is to click on the delegate, and then click on the Apply button in the corner of the window, or use its hidden Alt accelerator. If I want to see 5 items, I do this five times. If I want to look through 20 items, I do this 20 times. Every time I do this, I get frustrated and feel like it should be doable in a faster way.

This proposal is one way to resolve the issue. I don't personally see a problem with the hidden double-click accelerator (obviously, or else I wouldn't have submitted the patch :) ), but if people don't like this approach, I hope we can have a conversation about alternative approaches to resolve the underlying issue of the test-multiple-items-in-a-grid-view-KCM workflow being quite slow. I can think of a few:

• Move to the instant apply paradigm
• Add Preview buttons to all delegates that "virtually" apply the item to everything visible on screen
• Do the above, but on hover or selection, with a visible message that says "this is just a preview", click Apply to apply these settings"
• Probably way more

In D22102#487806, @ngraham wrote:

Right now, I find it *extremely* annoying, slow, and frustrating to test new themes, colors, icons, wallpapers, etc. The workflow is to click on the delegate, and then click on the Apply button in the corner of the window, or use its hidden Alt accelerator. If I want to see 5 items, I do this five times. If I want to look through 20 items, I do this 20 times. Every time I do this, I get frustrated and feel like it should be doable in a faster way.

While I can understand that clicking can be "annoying", OTOH I consider all the KCMs you mentioned as "mostly once" configuration items: you generally configure the color/wallpaper/icons/etc when you start using Plasma, and then you almost never go back to change these configurations again. Maybe my perspective is limited, however I do not see e.g. an icon KCM used more than once per month (even stretching things a bit), so using them often is not a "common case".
Sure, I agree that 20 clicks for trying a wallpaper might be "slow", although most probably you have configured it within 10 minutes...

This proposal is one way to resolve the issue. I don't personally see a problem with the hidden double-click accelerator (obviously, or else I wouldn't have submitted the patch :) ),

As I wrote already, this is problematic on its own:

• the general paradigm is OK/Apply/Cancel, so having "pieces" of the instant-apply one mixed in (with not even the possibility to disable it) IMHO adds more confusion than anything else; I can imagine an user thinking "here I can double click to apply instantly" "hmm but here not"
• corollary of the above: IMHO choosing *one* paradigm and following it is the coherent way of doing things; switching to instant-apply (which I don't agree with) would require a massive amount of work
• mis-clicking, even mis-double-clicking happens, and if the user does that, they cannot go back to the previous setting, as the action was the equivalent of pressing the Apply button

Also, the original proposal mentioned that this would not need explicit documentation. This is very bad, as the user faces some hidden behaviour on their configuration modules, and they have no way to know that this is actually wanted unless they "google it". I do not think our users need to be left in the dark about features.

but if people don't like this approach, I hope we can have a conversation about alternative approaches to resolve the underlying issue of the test-multiple-items-in-a-grid-view-KCM workflow being quite slow.

Surely I do not want to undermine your own PoV, however how is this a issue even? Do we have user reports that point out that this complicates the workflow so much?
From what I can see, the original D18571: Add "apply on double-click" feature to most other recent ported KCMs was done by Nate Graham, based on the RFE #398303 requested by Nate Graham, with only a later #403384 requested by a single user.

I can think of a few:

• Move to the instant apply paradigm

-1

• Add Preview buttons to all delegates that "virtually" apply the item to everything visible on screen

What would this Preview button do?

• Do the above, but on hover or selection, with a visible message that says "this is just a preview", click Apply to apply these settings"
• Probably way more

Or probably leave things as they are.

Alternatively you can add message widget that explore double click functionality, when double click is applied it can change its message that save is applied. But rater OK/Apply became a bit pointless.

In D22102#488388, @pino wrote:

While I can understand that clicking can be "annoying", OTOH I consider all the KCMs you mentioned as "mostly once" configuration items: you generally configure the color/wallpaper/icons/etc when you start using Plasma, and then you almost never go back to change these configurations again. Maybe my perspective is limited, however I do not see e.g. an icon KCM used more than once per month (even stretching things a bit), so using them often is not a "common case".
Sure, I agree that 20 clicks for trying a wallpaper might be "slow", although most probably you have configured it within 10 minutes...

Sure, if your mental model of the Appearance configuration KCMs is "set it once and forget about it forever", then having a slightly slow workflow isn't a problem. But if your workflow is different, then it is a problem. Some people like trying out new things and change the appearance settings regularly. Some people like to manually change their wallpapers every few days. Some people are Plasma developers and need to test patches with multiple color schemes/widget themes/wallpapers/etc on a regular basis. Etc.

Right now these KCMs are not catering very well to people with these workflows. These people may not be the common case, but the common case is a person who never looks in these KCMs at all because they are satisfied with the defaults. The people who use this configurability at all are probably likely to adjust the settings quite a bit and on a semi-regular basis.

In D22102#488447, @ngraham wrote:

In D22102#488388, @pino wrote:

While I can understand that clicking can be "annoying", OTOH I consider all the KCMs you mentioned as "mostly once" configuration items: you generally configure the color/wallpaper/icons/etc when you start using Plasma, and then you almost never go back to change these configurations again. Maybe my perspective is limited, however I do not see e.g. an icon KCM used more than once per month (even stretching things a bit), so using them often is not a "common case".
Sure, I agree that 20 clicks for trying a wallpaper might be "slow", although most probably you have configured it within 10 minutes...

Sure, if your mental model of the Appearance configuration KCMs is "set it once and forget about it forever", then having a slightly slow workflow isn't a problem.

I said something else than what you wrote above:

• "mostly once", not "once and never forever"
• even when you change, it might is not so often

Right now these KCMs are not catering very well to people with these workflows.

I do not think it is worth to provide interface to adapt also to people with less common workflows without making it too messy.
There are many applications that do not perfor greatly for less common (or even rare workflows) -- I do not see it problematic, as long as these workflows are still doable. After all, we are talking about one click for a wallpaper change (the same in any situation), not something else in addition to what is required already.

The people who use this configurability at all are probably likely to adjust the settings quite a bit and on a semi-regular basis.

likely is [citation required].

Again, how big is the demand for this?

In D22102#487806, @ngraham wrote:

Maybe I should move back and examine the rationale for the proposal.

Right now, I find it *extremely* annoying, slow, and frustrating to test new themes, colors, icons, wallpapers, etc. The workflow is to click on the delegate, and then click on the Apply button in the corner of the window, or use its hidden Alt accelerator. If I want to see 5 items, I do this five times. If I want to look through 20 items, I do this 20 times. Every time I do this, I get frustrated and feel like it should be doable in a faster way.

This proposal is one way to resolve the issue. I don't personally see a problem with the hidden double-click accelerator (obviously, or else I wouldn't have submitted the patch :) ), but if people don't like this approach, I hope we can have a conversation about alternative approaches to resolve the underlying issue of the test-multiple-items-in-a-grid-view-KCM workflow being quite slow. I can think of a few:

• Move to the instant apply paradigm
• Add Preview buttons to all delegates that "virtually" apply the item to everything visible on screen
• Do the above, but on hover or selection, with a visible message that says "this is just a preview", click Apply to apply these settings"
• Probably way more

Exposing the options through a simple command line interface would be another option.

I don't really know what else to say. The current workflow is annoying and slow for me and I want to improve it. Maybe this isn't the best way, but it's rather frustrating to come up against a wall of opposition doubting whether it's a problem at all, or if it is, whether it's worth fixing.

In D22102#487806, @ngraham wrote:

use its hidden Alt accelerator.

Looks like already working solution for the problem. Whats wrong with alt accelerator?

Exposing the options through a simple command line interface would be another option.

At the risk of getting offtopic, it's the reason I started the KConfigWatcher class. The intention being for "kwriteconfig" to be used generically and then anything that needs to update will be automagic.

In D22102#488774, @mglb wrote:

In D22102#487806, @ngraham wrote:

use its hidden Alt accelerator.

Looks like already working solution for the problem. Whats wrong with alt accelerator?

If your hand is already on the mouse or touchpad because you just clicked on something to select it, you need to move that hand to the keyboard, or move your other hand there. It's slower than just double-clicking on it.