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