SplitView: calculate implicit size

Set the implicit size of the SplitView based on the sizes of the
split items.

Change-Id: I775b938215216831d10cb50868e4c6733e157eeb
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
SplitView: update code to use 'clampedMinMax' function

This function was added in a previous patch, so reuse it
for already existing code.

Change-Id: Icd5daf195af7e249d4273bbc32a290bed5f0eaa5
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
SplitView: rename 'expanding' to 'fillWidth'

Rename variables to the new Layout terminology, to ease
future maintenance/understanding of the code.

Change-Id: I619f62a0280238fafefe261fae3f00eb575bb699
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
SplitView: always respect min/max

If the user sets Layout.maximumWidth on the fillWidth item, we now
respect it. This can potentially make the splitview look buggy, since
the fillWidth item might then be restrained from filling out remaining
space. The same with the height of each item; you can now control the
maximum height. This means that each item can end up with a different
height. The upshot is that if you add items to a splitview that
cannot grow, splitview will not try to resize it.

Change-Id: If1cc82aefa939898a3b159da6b006f95af42599f
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
disable horizontal flick in TableView

Change-Id: I416febce983b44528611d46adc1aac8ce25507ac
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
TableView: remove unused property backgroundColor

Change-Id: Iff2eb9f6083dbb4e3f49a1a099b0c4c2f004f02d
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
Doc: Create documentation for Qt Quick Controls examples

Create an initial set of documentation for the examples - brief
descriptions and screenshots.

Change-Id: I29939ab4ab81b78d1c83718a696d56932a3a285c
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Examples: Update stackview example

Change-Id: Ia73015655ea75ee24cd1f2761df705c42894d12e
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Fix TabView not to insert duplicate tabs

There are three ways to add tabs:
- declare 'static' Tab { } child elements
- call addTab() / insertTab()
- Component::createObject(tabView)

=> Do not rely on the calling order of Component.onCompleted()
and make sure that the same tabs are not accidentally re-inserted.

Task-number: QTBUG-30873
Change-Id: Ib30cfb676debbb302c5e9f7d757f66aab6fcc684
Reviewed-by: Caroline Chao <caroline.chao@digia.com>
TableView: Fix activated() not emitted

The mousearea in TableView has to accept mouse event in onPressed to
receive upcoming double click event.

Regression introduced by Iff3e5c1.

Instead of not accepting the event in onPressed, set the MouseArea
property propagateComposedEvents to true and does not accept the onClicked
event.

Also uses QStyle::SH_ItemView_ActivateItemOnSingleClick to check if the
table is activated on single or double-clicking. By default, it is activated
on double-clicking.

Change-Id: I744174d7b31efebfae5e8db4db7b99a544ecf50f
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
TableView: Expose positionViewAtIndex() method

Task-number: QTBUG-29893

Change-Id: I7c80a68d9d45c3df3e0bf691b69c4510ccd1649d
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Autotests: Remove expectfail for test addRemoveItemsInModel

The bug QTBUG_30379 has been fixed.

Change-Id: Ic05f70e3dec528cacefba44d14a76952b5636315
Reviewed-by: Liang Qi <liang.qi@digia.com>
Refactor and clean up public style API

Change-Id: I10271c860abd9b45a262e3548628e6a3026e1a4f
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Revert "TableView: remove unused property backgroundColor"

This reverts commit 390c6fa663a824b348b3fb9c5459ce75cb4b83f1.

We actually do use this to set the background color.

Change-Id: I498b3695dfb9667d8d63983576eb16ad324ea798
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Ensure that a layout won't shrink the GroupBox..

..to be smaller than the GroupBox' implicit size.

Change-Id: I5dda34de6a55a511516f528e4b6e1bc8db10a86b
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
Fix basiclayouts example so that the window can be smaller..

..than the implicit size of the layout.

Change-Id: I89ad1d91c7e492ba498acd50e2ddde9cc8e84581
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
Layouts implicit sizes was not propagated up properly.

When a layout did not have an implicit size nor any of the
Layout.preferred* properties set, the size hint calculation would
fall back to retrieving the width and the height properties of the
item. It would then store that value in the Layout.preferred*
property. This was wrong.

This could be a problem when an item was later added to the layout,
and consequently the implicit size of the layout got updated.
However, since the layout now had a preferred size set, a parent
layout would ignore the implicit size it had since it would settle
with the Layout.preferred* property (that's the rules the
effectiveSizeHint_helper work with).

The fix is to set the implicit width/height instead of the
Layout.preferred{width|height} property.

The compare in the test was actually by accident wrong, which can be
easily verified.

Change-Id: Ib9110dec7988a547441748698348227d1b8a077f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Return infinity instead of -1 as a default value for max sizes

This was a bit inconsistent, because in the case of a Rectangle its
Layout.maximumWidth would return -1 by default (which was supposed to
be interpreted as infinity) However, since the maximumWidth propagated
up to the layout, the layout.Layout.maximumWidth would return
1000000000. Adding two Rectangles to the layout would make
layout.Layout.maximumWidth return 2000000000, and adding a third item
with Layout.maximumWidth:1 would make layout.Layout.maximumWidth
return 2000000001

With this change, since infinity + number = infinity, everything
that can grow to infinity will just return infinity.

In addition a developer can now more intuitively do comparisons
like this:

if (value > Layout.minimumWidth && value < Layout.maximumWidth)

instead of

if ((value == -1 || value > Layout.minimumWidth) &&
    (value != -1 && value < Layout.maximumWidth))

Now, as a bonus, it becomes less consistent to set an attached
(min,max) property to -1 in order to reset it to its implicit value.

This also fixes a documentation issue with regards to the attached
Layout.{min|max}imum{Width|Height} properties. It only told the story
correct if the item was not a layout, and updates the docs for the max
sizes to mention that it returns Number.POSITIVE_INFINITY

Change-Id: Ia638064fd3ed5614d7e496a9b5e4aa8fcb7307f7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Doc: Add a screenshot for Stack View example

Having a screenshot will make the example appear in Creator Welcome
mode as well.

Change-Id: I6ac810d4baeb6e3866138baaf2eb727168055b72
Reviewed-by: Caroline Chao <caroline.chao@digia.com>
Remove unneeded checks for -1 (infinity) in SplitView

With commit 16558ac71509fe51a4cf18f238e4f61b37323fe4
Layout.maximumWidth and Layout.maximumHeight now returns
Number.POSITIVE_INFINITY instead of -1.
As described in that commit, comparisons against those properties
does not need any special handling for -1 anymore.

Change-Id: I8d4bba0fa87f9c67ac30dd40a8be8cb99abba283
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>