hi ... so we have both Switch and Checkbox items in the QML. we have discussed previously and decided to keep using Checkbox on desktop (for consistency with the rest of the desktop UI if nothing else), though we favour Switch on touch.
i'm already noticing incosistencies creeping in, however, with Switches appearing on desktop bound software where checkboxes would normally be used. there are a few different options to head this off at the pass: * decide that Switch is prefered in the desktop shell and repleace all usage of Checkbox with Switch in all Plasma components. Pros: it's easy to make such a decision. Cons: it means a fair amount of (boring, but easy) work; it means the UI of the desktop shell will be different from the rest of the desktop. * implement Switch in the desktop components as a checkbox. Pros: this is very easy to do (API compatible; just need to move Switch.qml to touch components and make a new Switch.qml in the default desktop components that simply creates a Checkbox); people can use Switch if they want and things remain consistent Cons: it means you can never have a Switch element on a desktop app, even if you really want to (and use Checkboxes elsewhere in your UI). however, this is perhaps a weak con, as it implies there is a valid use case for switches on the desktop. as we've lived without them until now ... perhaps there aren't. * simply put "don't use Switch on desktop" into our HIG and then require that all UIs that use Switch move that QML to the appropriate platformcomponents subdir and use Checkbox instead in the main UI Pros: you can still use Switch on the desktop and get an actual switch Cons: Much more work for developers; relies on people caring about and implementing HIG-compliant UIs; if we change our mind in the future, all that work needs to be re-done I currently favour the second solution (making Switch a Checkbox on desktop), but would like to hear your thoughts so we can make the best decision possible together. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
