Several of the styles offers a Menu with a drop shadow. And the shadow
is drawn on the outside of the Menu. This works fine when the menu
is shown as an item in the scene, since Quick allows controls to
draw out-of-bounds. But when we now place the Menus inside native
windows, this will no longer be the case, as the windows will be
resized to fit the Menus, shadows excluded.

To solve this, this patch will make the Menus bigger, without
touching the size of the background, so that they include the
drop shadows. This is easily done by pushing the background items
a bit in, using insets.

The next issue is that when the application, or the MenuBar,
requests a Menu to open at at specific position, we want the
top left corner of the menu frame to be placed at this position.
But since the Menu background is now shifted into the Menu, we
need to teach QQuickPopup and and QQuickMenu to take insets into
account when positioning a popup/menu. Taking the insets into
account like this should be fine, since they're documented to be
used for this exact purpose, of adding drop shadow effects.

Change-Id: I2e5f0bcf14100d92dc4cd3c2cb7630601c0c1320
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>

As mentioned in the comments of QTBUG-68434, popups always inherit
their attributes from the parent window (unless they are explicitly
bound like in ComboBox). However, ComboBox was made an exception,
because the popup is an integral part of the control.

This means that although the following snippet shouldn't change the
background color of a Popup, it should do so for ComboBox's popup:

    Rectangle {
        Material.theme: Material.Dark

        ComboBox {
            model: 5
        }
    }

However, this didn't work.
Before 3ec6d04d976249d162f6ec92666d9008f4c21c34, material/ComboBox.qml
had the following binding in the popup's background Rectangle:

    color: control.popup.Material.dialogColor

That patch changed it in order to get deferred execution working:

    color: parent.Material.dialogColor

This causes the color to come from the window rather than the popup.
This would have almost been caught in test_comboBox, had we checked the
actual color when setting the theme.

To fix the bug without reverting to the previous QML and breaking
deferred execution, we modify findAttachedParent to return the popup's
attached object if the item passed to it is a QQuickPopupItem.

Doing this causes test_inheritance_popup to fail, so we fix that by
passing the attached object target (which can be a popup) to
findAttachedParent, rather than the item whose parent or window changed
(which is coincidentally what was already being done in initialize()).

The patch also adds categorised logging to help debug such issues in
the future. Conveniently, this will also help users who want to debug
their own QQuickAttachedPropertyPropagator subclasses, without them
needing to modify Qt itself.

Fixes: QTBUG-115322
Pick-to: 6.5 6.6
Change-Id: Idc0495023a058bcb033c4002fb6ad233bae9feae
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

QQuickItemPrivate::accessibleRole is virtual and called by the framework
to determine the role of an item. The default implementation checks and
respects a possible Accessible attached object. However, subclasses that
override the virtual don't, so the attached properties are ignored, and
the class-specific implementation wins. This makes it impossible to
change the role of e.g. a checkable button.

To fix that, move the code respecting the attached object into a non-
virtual function that the framework calls instead, and only call the
virtual member if there is no attached object, or if that object is not
initialized with a role. Replace calls to the virtual from the
framework with calls to the non-virtual wrapper.

Do this for both QQuickItem and for QQuickPopup, and adjust the logic
in QQuickControl types that create an attached object and initialize
it's role when accessibility becomes active. Use the non-overridable
effective role value for that as well.

Add a test case, and to avoid any new framework calls to the virtual,
make it private.

Fixes: QTBUG-110114
Pick-to: 6.5 6.2
Change-Id: Ia709cecbd181b6d8ee3297a4af60c1e7db9a2c51
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>

They cause clashes in CMake Unity (Jumbo) builds.

Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I2f1b6a7421f66d3d731d5a273242c2b27a882354
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>

Qt Quick Controls 2 was named that way because it was a follow-up to
Qt Quick Controls 1.x. Now that Qt Quick Controls 1 is no longer
supported, we don't need to have "2" in the name. Work on this was
already started for the documentation in
1abdfe5d5a052f2298b7bf657513dfa7e0c66a56.

By doing this renaming a few weeks before feature freeze, it won't
affect the release but still results in as little time possible spent
manually fixing conflicts in cherry-picks from non-LTS releases as a
result of the renaming.

This patch does the following:

- Renames directories.
- Adapts CMakeLists.txt and other files to account for the new paths.

A follow-up patch will handle documentation.

It does not touch library names or other user-facing stuff, as that
will have to be done in Qt 7.

Task-number: QTBUG-95413
Change-Id: I170d8db19033ee71e495ff0c5c1a517a41ed7634
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>