This KCM needs to be merged into some other KCM.

In T7242#115477, @subdiff wrote:

This KCM needs to be merged into some other KCM.

+1

+1

@ngraham and I decided to put the Mouse double/single click setting here, because on Wayland the Mouse KCM is device-dependent and communicates directly with KWin only and on X/Libinput it's missing at the moment.

I.e. we won't remove this KCM but will put more "general" options here affecting the overall Plasma / Workspace experience. Another candidate is the animation speed setting, which is currently in the Compositor KCM.

@furkantokac did a QML rewrite of the current KCM: D12936

The fact that this only controls Plasma options is IMHO a leaky implementation detail. As a user, I actually have no idea what "Workspace" means. Isn't my whole computer a workspace?

I propose making the names and purpose more user-centric:

• Rename the global "Workspace" category name to "Behavior"
• Rename the "Workspace" KCM (this one) to "General", move it to the top level of navigation (Under the new "Behavior" top-level category) and use it as a general options page where we can put things that are globally applicable but don't really fit anywhere else. The click settings are one example, but I could also see room for KIO settings that currently live in Dolphin or have no visible UI.

Thoughts?

That sounds like a very slippery slope to just being a dumping ground of completely random things. I don't think that's a sustainable long term plan. There needs to be some grouping.

That's a very good point, and "General" pages often suffer that fate. However, the alternative is lots of small pages with only one or two options in them, like the Workspace KCM already is...

Also there's the danger of leaking implementation details again. For example if we make a KIO KCM to control the KIO options, we'll need to avoid using the term KIO to avoid confusing users ("Huh? What's a KIO?").

Basically I think we should focus more on the user perspective than the developer perspective here. Users usually don't understand the technical implementation details well enough to benefit from extremely fine-grained grouping.

I fully support grouping things by user-viewed functionality rather than tech details. That's fine as long as there's a deliberate grouping.

It's still a world apart from having a dumping ground where we arbitrarily link how the mouse behaves with how remote files work.

In T7242#142472, @davidedmundson wrote:

how the mouse behaves

Single-click/double-click isn't a mouse setting. It's a behavior setting that affects all input devices, not just a mouse. I use a laptop with no mouse, and the setting affects how many clicks are required with my touchpad. It also affects how many taps are required with a touchscreen (though whether it should is another matter, as double-click is a UI metaphor that makes no sense with a touchsceen since it's practically impossible to execute).

This is why I think it makes more sense to have it here rather than in the mouse KCM, which otherwise has only settings that are mouse-specific. The click setting is not mouse specific.

Anyway, it sounds like we're in agreement. I also don't want this KCM to turn into a dumping ground, and agree that some grouping is a good idea for whatever else we decided to add to it down the road.