[ChangeLog][Controls] TextField and TextArea now provide a ContextMenu
by default. If you already have a custom context menu for these types,
ContextMenu will not open its own on e.g. right click.
Fixes: QTBUG-35598
Pick-to: 6.9
Change-Id: I0897a7ba5e1b5b6d5425c80cbc6f2550c904605b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
This is an attached type that provides a way to open a context menu
in a platform-appropriate manner.
[ChangeLog][Controls] Added ContextMenu. ContextMenu can be attached
to any item in order to show a context menu upon a platform-specific
event, such as a right click or the context menu key.
Fixes: QTBUG-67331
Pick-to: 6.9
Change-Id: I225a8f498cc5bc18d36c3dc4cf481ef5ef95cd88
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Now that we enable native menus by default for the macOS
style, we also need to make sure that we actually respect
the Qt::AA_DontUseNativeMenuWindows.
Pick-to: 6.8
Change-Id: I2a02b5528110a4e0514fb53c0673653f0086dfe8
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.8
Task-number: QTBUG-121787
Change-Id: I50964da74d6360bb88fc468765f6362ad39d20d1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Its nice to be able to test that you can still
e.g hover the root menu, even when a subsub menu
is the active popup.
Pick-to: 6.8
Change-Id: Ibf76770a13c41f4712187daeb793439c83730db9
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Update the manual test to reflect that we no longer
have a Popup.Default option. Also, after seeing some
warnings, add a popupType() function, to improve
type safety.
Pick-to: 6.8
Change-Id: I70c4a52d776522541251bb0b2ab260b735d49171
Reviewed-by: Mitch Curtis <mitch.curtis@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>
Now that Popup has a popupType API, use it in favor
of AA_DontUseNativeMenuWindows.
Change-Id: I6b666e9c36f5d8b95701ac6a94c29ac3d7a6d206
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Changing whether or not to use a native menu bar requires
setting AA_DontUseNativeMenuBar. But this will only take
effect the next time the app is started. So inform about
this, since it can otherwise be quite confusing for the
"tester".
Change-Id: Ie37b9ec0cc66660548ea13cb383440536e6fd707
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
It seems the Quit menu bar item steals the shortcut, so we have to do
something with it.
Change-Id: I3831c8bc99728773e22284232d7ab54ba6eb117f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This enables testing the drag-press-release gesture.
Change-Id: I953fee1f891b2ac907a5a69ca98f720496e7ed91
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Add more logic to the manual test to test:
1. changing the delegate
2. changing the title of a menu in the menu bar
3. using sub menus
3. using checkable menu items in the menu bar menus
Change-Id: I6a7256fb368a3557837c0448a6ddc895bb24924d
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
It was decided that we'll have two attributes:
- AA_DontUseNativeMenuBar
- AA_DontUseNativeMenuWindows
Setting AA_DontUseNativeMenuWindows only affects windows we create
(context menus, combobox menus, menus of non-native menu bars).
So, setting AA_DontUseNativeMenuWindows restores Qt to today's behavior.
But we can't control the windows of native menu bars, so if you don't
want those to be native, you have to set AA_DontUseNativeMenuBar just
like today.
By removing requestNative, we also effectively default to native menus
and menu bars, as the attributes are not set by default.
[ChangeLog][Controls][Important Behavior Changes] Menu and MenuBar
now use native menus by default on platforms where they're supported.
Task-number: QTBUG-69558
Change-Id: Ia917c2f820634def0cf815aa8ca8895ca79db75d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Mitch Curtis
Richard Moe Gustavsen
Lucie Gérard
Oliver Eftevaag
Shawn Rutledge