I feel like this subject needs a lot more internal discussion in VDG before we make a HIG page about it.

For a developer, the central question is, "Should I use a checkbox or a switch"? This page only gives an answer to that question for one context: "use checkboxes for selection in lists." What about on settings pages? The text here seems to indicate that switches are preferred for settings, yet no KDE software that I'm aware of uses them instead of checkboxes.

IMHO, it would be beneficial to first make a decision about standardizing on either checkboxes or switches for on/off settings. Because in terms of functionality, they are identical, and there's rarely a good reason to have two controls that do the exact same thing but look different.

Switches, which typically have their label to the left, fit well into modern Settings UIs where other controls have their labels to the left (which we are trying to encourage in D12961). GNOME and ElementaryOS use switches instead of checkboxes on their settings pages for this reason. Checkboxes are somewhat awkward in this new paradigm that we are trying to adopt. I gave it a go for Dolphin in D12571, and wound up with some less-than-elegant results like Expandable folders: [x] Enable and Confirm: [x] Moving files or folders to the trash. This is also harder to properly localize.

But switches don't fit as well in menus, where it would be a significant departure to have the control be on the right side of the menu (not to mention this would require some code changes to Breeze). I guess we could make that change, but that would take a lot of discussion first.

Also, the actual switch control we have appears to just be a two-position slider that shows its state in a somewhat ambiguous manner. If we're going to endorse the use of switches anywhere, I'd like to first see some work on improving the control's appearance and clarity of state. David's version is nice, assuming it can handle languages where "on" and "off" are very long.

The gist of that article seems to be, "Use a switch for instant-apply settings, and a checkbox for everything else." Fair enough.

So we shouldn't use switches in our settings UIs because we don't use the instant-apply paradigm there. Where should we use them, then? Here are the places where we do currently use instant-apply for checkboxes, which would be candidates for turning into switches:

• In a some plasmoids, e.g. airplane mode in plasma-nm and mute state in plasma-pa
• For toggle actions in menus

If we say "Don't use switches in menus", we're creating a fairly broad exception that cripples the general rule, because menus are where the vast majority of our instant-apply checkboxes live.

If we do say, "Do use switches in menus because they're instant-apply settings", then we need to do some code work in Breeze (or even upstream in Qt?) first or else all of our apps become in violation of the new HIG rule. And we need an actual switch control for both QWidgets and QQC-based interfaces that we can put in the menus (QQC apps can have menus).

In fact, we need to create the switch control and make it available first anyway, or else developers will have to kludge together their own thing which isn't great.

So I still think we need to have those discussions, come to a conclusion, and do the work before we document the result in this HIG page. :)