Ensure that styleData.row is initialized in delegates

While we specifically documented that you should not depend on
the value being correct in onCompleted for 5.3, it is not
optimal that the initial value is consistently set to 0 and later
changed to it's appropriate value. This patch ensures that delegates
are not instantiated until after the model model and row values
have been fully initialized.

Task-number: QTBUG-38307
Change-Id: Ib3300539a0283c997ab8b808fb229d3f22ed6324
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Doc: Adding information about how to run the example.

-includes a file from qtbase/doc/global/includes
-added to example pages (\example)

Task-number: QTBUG-33597
Change-Id: I1356e12826a7702b4431f815d6ec42b28e21003c
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Fix tab visibility regression

Division by 0 caused strange behavior and made the tabs not
get a valid size even when the available size changed later.

Task-number: QTBUG-38294
Change-Id: I456e7a0cc244a76c81832fa580377674bcc5a828
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
Dialogs: implementation prop renamed to contentItem; API cleanup

- contentItem is a common name for an item inside something such as a
window or a flickable.  We now consider it adequate API that you can
directly set this to some item which you want to fill the whole dialog
instead of adding an item as a child of the default property and being
subject to the dialog's margins and space reservation for buttons.
- contentItem MUST be an Item.  Allowing the old "implementation"
property to alternatively be a ready-made Window was just a
hypothetical use case, but if anyone made use of that, then it would
be a problem to have that kind of dialog on a GUI that cannot have
windows (such as Android or EGLFS). So there's no point in having
the possibility as long as we cannot emulate windows as items.
- standardButtonsRightModel and standardButtonsLeftModel are
implementation details so they should not be exposed as properties
which Creator can discover; users shouldn't depend on them.

Task-number: QTBUG-38056
Change-Id: Iefa3def314353495cfe8d1ef9f775a8e46d5bcf4
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Docs: fix QtQuick.Controls.Styles import version

Change-Id: I8d3571843302ffb39e7b9f6d53f6eb76e923d3d8
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
Update plugins.qmltypes for QtQuick.Dialogs

Change-Id: I7e12acab9b958533d3065257f507304984f117d2
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
Reviewed-by: Liang Qi <liang.qi@digia.com>
Update plugins.qmltypes for QtQuick.PrivateWidgets

Change-Id: I53236f5698b2430e533d94ebb146beb72ce49c21
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
Reviewed-by: Liang Qi <liang.qi@digia.com>
Update plugins.qmltypes for QtQuick.Controls

Change-Id: I393b926f80e96296df03898fa49fd83140d36460
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
Fix missing tabs in touch example

The only reason that the we calculated the tab count
explicitly before was that we were using an array.
Now that we are using a model there is no longer any
need to keep track of the count independently of the model.

This fix prevents the count from originally showing as 0 and
prevents an extra value change. In addition the count
is now correctly marked as readonly.

Task-number: QTBUG-38421
Change-Id: I53a5d0df3367c850a7c6846729660dd0f63238d5
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Reviewed-by: Jonathan Liu <net147@gmail.com>
Merge remote-tracking branch 'origin/release' into stable

Change-Id: Idab72460ff342ce6df541559c2e853d7c837f595
QtGui and XCB now actually supports modality

However, however, popup windows should still have priority, which is not
yet implemented. It still doesn't explain why this fixes all the
autotest failures.

Task-number: QTBUG-38508
Change-Id: I3f93785b0b6c02b0fa42b1460526ea4b42b6f9a1
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Reviewed-by: Liang Qi <liang.qi@digia.com>
Bump MODULE_VERSION to 5.3.1

Change-Id: Ic5bad1366373f5c3d8bcb67504e651e5668484f8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Test that attached Keys behavior is identical to TextInput/Area

Such composite controls that consist of a TextInput or TextArea should
offer identical behavior for the Keys attached property on the control
itself as it would behave if it was used on the internal editor.

Task-number: QTBUG-38289
Change-Id: I4e6d77d2cc1f3c7202418b9aa21d1f40ddd0eb96
Reviewed-by: Liang Qi <liang.qi@digia.com>
Merge "Merge remote-tracking branch 'origin/release' into stable" into refs/staging/stable