Define QML Item's that expose properties and other metaobject information, which form the common API that Qt Quick component styles should implement. For these common APIs on the first phase we are not focusing on styling neither on layouting parts, as these will be provided by the respective style implementations.
|1st Priority Common API||Task||API Plan|
|Page and PageStack||
|Priority, candidate for common API|
|ToolButton / ToolIcon||QTCOMPONENTS-599||Beta|
The initial API design assumes only non-visible properties. Visual aspects of the widgets will be encapsulated in the Style. Platform-specific components like IconButton, SwitchButton and so forth should be possible to build on top of this but is not part of the common API - but should be based on a common abstract button. They should be exposed under a platform-specific import.
Expose only bare minimum from the MouseArea that will be inside a Button implementation.
obs: tri-state is not a common feature on the mobile, so will not be added now (could be added
later for the desktop use case). switchbutton has a similar behavior as checkbox, but is a separate component.
obs: stepSize represents valid values for the widget (onValueChanged will be emitted only on 'stepSize' offsets),
snapping behavior is up to the slider style implementation. Leaving the progress feature out from the components.
we changed the type to float because it is more generic. Integer is a subcase of float (can be achieved by using a stepSize == 1.0).
another argument is that if we want to show float types in the slider label (or for the minimum/maximum values), we need to be able to set those float values through the api.
Avoid changing the 'value' of the Slider while dragging (behavior in this case is undefined).
obs: the behavior on how to switch from indeterminate to determinate is style dependent.
obs: spinner name was wrong, spinner is a spinbox in android, sencha and jquery.
For use around a Flickable (which is the QML equivalent of a ScrollArea)
obs: there should be a separate component for an interactive scrollbar.
obs 2: see comment for explanation
Arranges buttons in a row or a column. Adds mutual exclusion for RadioButtons and checkable Buttons.
When using Buttons, these will be stylized as parts of a 'segmented button'.
Any item with the checked property is supported.
When the exclusive property is set to true, the following algorithm is used to determine which button will be checked from start.
1. If checkedButton is set, this will be the one. All the other buttons will be unchecked.
2. Else, if any button's checked property is set to true, the first one will be the one, and all the others will be unchecked.
3. Else, if no button has its checked property set to true, the first button will be the one.
When adding, removing, hiding, or showing buttons in ButtonRow, ButtonColumn, the same algorithm as above applies. If checkedButton is now hidden or has been removed, then it stands as undefined.
The checkedButton property is read-write. Setting it during runtime is equivalent to clicking on that button.
Although it's not a use-case we would encourage, changing the exclusive property during runtime is defined, too. When changing from true to false, the currently checked button remains checked. When changing from false to true, the checkedButton value is preserved as much as possible, or as much as it makes sense.
obs: should this be used in the toolbar? are there relevant cases for button row in other contexts?
|Define Common Widget API||Resolved||Unassigned||
|Write API base items||Closed||Unassigned||
|Build conformance test suite for common widget API||Resolved||
|Migrate MeeGo style to common Widget API||Resolved||Unassigned||
|Migrate Symbian style to common Widget API||Resolved||Unassigned||
|Update Docs to Common API||Resolved|
|Common API set 2010w48||Resolved||Unassigned|