We want to handle menus special compared to other popups.
For menus, we want all open parent menus and sub menus that
belong together to almost act as a single popup WRT event
delivery. This will allow the user to hover and highlight
MenuItems inside all of them, and not just the leaf menu.

This patch will therefore forward all relevant pointer events
that goes to a leaf menu to the actual menu, or menu bar,
under the mouse. But note that this forwarding will happen
in parallel with normal event delivery (we don't eat the
events), as we don't want to break the delivery to e.g
grabbers, and other DA logic in general.

Change-Id: If87756e59c08ff73cb75a21fafab6cf39e4c94b6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>

The application attribute approach has some weaknesses which makes it
less suitable, than simply having a property which can be set per
instance of Popup. In addition, given just how many of our own tests
that are failing, when changing the default behavior of popup, it`s a
much safer approach to introduce this feature as an opt-in, in the
beginning. We can instead potentially modify the behavior of
PopupType::Default in the future, when we feel that it's less risky
to do so.

To give more context to why the AA approach is bad:
- The AA is too grandiose of a solution, which adds an arbitrary
  limitation of not allowing mixing of in-scene popups and popup windows.
  This also affects 3rd party libraries.

- It causes inconveniences when styling the various popup types.
  Dialog, for instance, has a title property, which should be shown in
  the window title, and not inside the popup window.

- It also makes it less flexible for potential future changes. We've
  learned that this change is riskier, than initially expected, since
  the qobject and visual hierarchy of popup objects are different when
  using popup windows, and tests that simulate events,
  will need to send the events to a different window.

The introduction of the PopupType::Default value, allows us to, for
instance, add a property later in ApplicationWindow, or somewhere else,
to change the behavior of PopupType::Default. Meaning that we can still
add a more grandiose API, that affects the behavior of multiple popup
instances, if we think it's too cumbersome for developers to add
`popupType: Popup.Window` to all popup instances.

Task-number: QTBUG-121363
Change-Id: I544da820261607621a9b9ad5c4c9679e676e44a0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>

QQuickDeliveryAgent doesn't allow an item to see a pointer release event
unless the item has already grabbed; that's usually done on press.
But during the drag-press-release gesture, we don't know which menu item
the user will choose until the release. QQuickMenu isn't doing all the
event handling on its own, and thus isn't the grabber: QQuickMenuItem
inherits QQuickAbstractButton, and if that "button" didn't get grabbed,
it's not going to react to the release. So we need a workaround.

Given that the popup window did not see the mouse/touch/tablet press
but just some moves and a release, there will not be a grabber within
the popup window. In that case, on release, call virtual
QQuickPopupPrivate::handleReleaseWithoutGrab(), which is overridden in
QQuickMenuPrivate to programmatically "click" the currently-hovered menu
item. Then propagation continues, to allow the component that opened
the menu to also see the release, and exit from its "pressed" state.

Task-number: QTBUG-68080
Change-Id: I3280ffe722560726003522bb33e5152302cb8cbc
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>

[ChangeLog][Controls][AbstractButton] Added click() and
animateClick() functions to allow programmatically clicking a button
with or without visual changes.

Fixes: QTBUG-96784
Task-number: QTBUG-69558
Change-Id: I53cdccd90e2e4b831105e90e2541cbc674760c0b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>

Add the properties "implicitTextPadding" and "textPadding"
to MenuItem. They can be used by the style to ensure that
all MenuItems inside the same Menu end up left-aligned
WRT text.

Each MenuItem should set implicitTextPadding to be the
needed space from the left edge of the contentItem to
the text label. QQuickMenu will then iterate over all
the MenuItems inside the same Menu, and set textPadding
to be the maximum implicitTextPadding found.

All MenuItems should then use textPadding (which will end
up the same for all MenuItems) to position the text.

This API is meant to solve the problem that MenuItems
inside a single Menu can have different contents. Some
can be checkable, some can have an icon, some are just
plain text. And for several of our styles (e.g macOS and
Windows), we want the text to be left-aligned regardless
of that. Without this API, The checkmark inside a
checkable MenuItem would be left-aligned with the text
inside a plain MenuItem etc.

[ChangeLog][Controls][MenuItem] A MenuItem now has two
new properties (implicitTextPadding and textPadding)
that can be used for aligning the text across all
MenuItems inside a Menu.

Change-Id: I1f2248b31c63d6b9780d8fc77229a8b902362f70
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>

Popup windows will never become the focus window of the application.
Meaning that window system events will be send directly to the "main"
window, and then forwarded to any potential popup windows, if any.

But since popup windows don't become "active", they won't receive the
focus in event, and thus never call setFocus on their contentItem.

This could cause setFocusInScope() to skip assigning the activeFocusItem
to be the new focus item. Effectively breaking keyboard navigation for
things like menus that are inside a menubar.

Change-Id: Id1345aee09ed4dd31017781f5e0e6f5f925551e6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>

Add a note explaining that a native menu bar will be used
on macOS from Qt 6.8, and that it can be disabled by
using AA_DontUseNativeMenuBar.

Change-Id: I4fff1d6e05bbd274a77d0fe145bde5089277f5bc
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>

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>

Desktop users typically expect dialogs to be top level windows,
but there can also be advantages to having other types of popups,
such as Menus, and ToolTips, be top level windows as well.

Currently the QQuickPopup class is tightly coupled with the
QQuickPopupItem which it creates, and forwards a bunch of properties
to. But we want Popup to seamlessly create a new window, which renders
the popup item. This should serve as a new feature, which is primarily
targeted for desktop users, and should not replace the old behavior,
since having the popup item in the same window will likely be preferred
for mobile and embedded users.

The default behavior will now be to create a popup window, when the QML
application is running on a desktop system (determined by the
platformIntegrations capabilities). It's also possible to opt out of
this new behavior, by setting the AA_DontUsePopupWindows application
attribute flag.

The dialogs in QtQuick.Dialogs should now also appear in their own
dedicated window, since they were using QQuickDialog behind the scenes.

The combobox popup, will also appear in its own window.

Some changes, such as modality, won't take effect until the window is
reopened, since the window is destroyed/recreated on visibility changes.

Done-with: Ed Cooke <ed.cooke@qt.io>
Task-number: QTBUG-121363
Change-Id: I21f4fd1f922219359d3258854bdcdc9be6980f4f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>

Change-Id: I4dbf262105ab7bfd2ae9288acd0f9ef4306e8d48