Switch and Checkbox items

Aaron J. Seigo aseigo at kde.org
Thu Dec 13 15:41:58 UTC 2012


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121213/1944fca3/attachment.sig>


More information about the Plasma-devel mailing list