Qt 6.5.10-lts release

Conflicts solved:
	dependencies.yaml

Change-Id: I30aa1cd656455861044ba1c3c8075f52d20dc2e8

Qt 6.5.9-lts release

Conflicts solved:
	dependencies.yaml

Change-Id: I6f892bad653449a1dd0e0c6e66cc74eee8657cda

Qt 6.5.8-lts release

Conflicts solved:
	dependencies.yaml

Change-Id: Id2eeb915139bdd1943ffc498173db540f22ca2f3

Qt 6.5.7-lts release

Conflicts solved:
	dependencies.yaml

Change-Id: I8fbe9c1606825b726adf95e69a4fa86e2196f4e8

The documentation incorrectly stated that setting a parent Item's `enabled`
property to false directly modifies the `enabled` values of its child items.

This is not the case — the effective enabled state of children depends on
their own `enabled` value combined with their parents', and their property
bindings are preserved.

This change updates the documentation to reflect the correct behavior,
avoiding confusion about binding removal or value resetting.

Fixes: QTBUG-136699
Change-Id: I605024ca216f3bb50015f2ac8641f2e28b3973fa
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 5b17c03634dcf8f9da6e6570f579f5c2fa280830)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit c1683afa5bfb23a3cd947267514e074e91d75ec0)
(cherry picked from commit 560f63bbe31e483a7476535095d2cfd6500e1bb8)

Qt 6.5.6-lts release

Conflicts solved:
	dependencies.yaml

Change-Id: I9ee692350de5ba94eb25021b6246c2b397570e76

When building Qt with a non-double qreal type, i.e.
QT_COORD_TYPE=float, explicit template specialization like:
    qBound<qreal>(0.0, qreal(0.5), 1.0);

is ambiguous because the double literals conflict with qreal (float).
This creates ambiguity when resolving between overloads such as:

    qBound<T>(const T&, const T&, const T&)
    qBound<T, U>(const T&, const U&, const T&)

Fix this by porting to std::clamp(), which ensures consistent types and
avoids the implicit conversions that made such ambiguities possible.

Change-Id: I45b430dd26a90fd0289111f1b336d40533c74841
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit e4c899716568386d12344f2398c3412765f58d02)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit a60b51e213ec3ccd0e230e0c4167ade5d7609385)
(cherry picked from commit b190139a29594f084323b801bfebc5c7d4cfc08a)

Qt 6.5.5-lts release

Conflicts solved:
	dependencies.yaml
	src/quick/doc/snippets/qml/treeview/qml-customdelegate.qml

Change-Id: Ifa297315fa0e6e70d9f26312f9183da4769d18fc

This reverts commit da5933f22c00270ac9083a089686e5c54e0057da.

Revert of commercial SPDX license identifiers is required for the
Qt 6.5.x opensource releases, Qt 6.5.4 onwards.

Change-Id: Ic056fb761f242af0ec4c883ecb35d50804c1c67c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

On macOS, readOnly/non-editable text controls don't accept tab
focus. This behavior is also respected in Qt since
c1d2bcff3dededa5b560713f4fd4874a023c43a2 .
Since this behavior is particular to macOS and not to other
platforms, in Qt we have tabFocusBehavior() in
qGuiApp->styleHints() which represents the system setting.
For all platforms other than macOS this always returns
Qt::TabFocusAllControls, which hints that all enabled controls
should receive tab focus no matter if editable or not. On
macOS if this true, all controls will accept tab focus, and if not,
it means that only editable text inputs and lists will.

The problem was that on macOS readOnly text edits were receivng
tab focus even if tabFocusBehaviour was not
Qt::TabFocusAllControls. This was because they have an
EditableText accessible role, which took precedence over their
editable status. To fix, if tabFocusBehaviour allows,
non-editable/readOnly properties should not receive tab focus no
matter the accessible role.
While at it, move the tabFocusBehaviour check inside
QQuickItem::canAcceptTabFocus.
Remove expect_fail in test covering case.

Note that this patch assumes that if tabFocusBehaviour ==
Qt::TabFocusAllControls readOnly text inputs will receive tab
focus on macOS too, even if this is never the case on a native
application: such inputs never get tab focus on Mac. We could
introduce a new enum value for tabFocusBehaviour that more
accurately depicts the readOnly text input focus behavior.

Change-Id: I098f75eb118b04f73dae3deec0c798f18870a202
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit aa7eb60a703cdc076115a45c2ac39e4965da2b87)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 2a0e0fac0ff6672431d6b2e6dc5bc81d27e0ae85)