qt/qtdeclarative.git/src/quickwidgets, branch wip/nativemenus Qt Declarative (Quick 2) Doc: Improve QQuickWidget constructor documentation 2024-05-06T11:15:47+00:00 Kai Köhne kai.koehne@qt.io 2024-05-02T15:31:54+00:00 f85d3f950a046d768d7644931ed8167d614ad19c Pick-to: 6.7 Change-Id: I5fdf9918432c4861ca40158789e0b4e03674b240 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 
Pick-to: 6.7
Change-Id: I5fdf9918432c4861ca40158789e0b4e03674b240
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QQuickWidget: Set WA_AcceptTouchEvents in all constructors 2024-05-06T11:15:47+00:00 Kai Köhne kai.koehne@qt.io 2024-05-02T15:28:30+00:00 b85ec1cab47e8cdc5383fc0c681cee8a9f453366 So far this was set only in two of the three constructors. But all of them call init(). Amends 2f1be4c51a1655697933468c10ba53316306d207. Task-number: QTBUG-113384 Pick-to: 6.7 Change-Id: Ie15cad40164e6faea626c005fddbf54bedaf3ffe Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 
So far this was set only in two of the three constructors.
But all of them call init().

Amends 2f1be4c51a1655697933468c10ba53316306d207.

Task-number: QTBUG-113384
Pick-to: 6.7
Change-Id: Ie15cad40164e6faea626c005fddbf54bedaf3ffe
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use new QWidgetPrivate::rhi() helper method for accessing QWidget RHI 2024-04-03T21:08:44+00:00 Tor Arne Vestbø tor.arne.vestbo@qt.io 2024-03-05T15:45:54+00:00 c630895bc300489de80c421a2bf315e9b7125f57 Added in qtbase/f451b01791536fede40c8d4fb90799c2e23e9386. Pick-to: 6.7 6.6 6.5 Change-Id: I3c82e3b12c83a3d2b4a5f35bf7f71c283f59c621 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> 
Added in qtbase/f451b01791536fede40c8d4fb90799c2e23e9386.

Pick-to: 6.7 6.6 6.5
Change-Id: I3c82e3b12c83a3d2b4a5f35bf7f71c283f59c621
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
QQuickWidget: Play nice with Vulkan and offscreen grabbing 2024-03-06T18:12:33+00:00 Laszlo Agocs laszlo.agocs@qt.io 2024-02-14T11:10:30+00:00 b676c3fbc7117fbf0b3580c16a1173f9c383d54c The texture does not have the UsedAsTransferSource flag set. With Vulkan this results in a validation layer warning (if that is enabled) when issuing the VkImage -> buffer copy during the grab. Add the flag. We also need to ensure there is a QVulkanInstance (VkInstance). Normally we do not care about this and just forward what the toplevel/backingstore use, but this is not there when trying to grab with a not-yet-shown widget. Use the helper singleton (QVulkanDefaultInstance) to get a QVulkanInstance. (this is also what the backingstore and Qt Quick uses) Pick-to: 6.7 Change-Id: I9f5b4a67a1a7862e6b89e76f2a6d55c8a2be1972 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> 
The texture does not have the UsedAsTransferSource flag set. With
Vulkan this results in a validation layer warning (if that is enabled)
when issuing the VkImage -> buffer copy during the grab. Add the flag.

We also need to ensure there is a QVulkanInstance
(VkInstance). Normally we do not care about this and just forward what
the toplevel/backingstore use, but this is not there when trying to
grab with a not-yet-shown widget.  Use the helper singleton
(QVulkanDefaultInstance) to get a QVulkanInstance. (this is also what
the backingstore and Qt Quick uses)

Pick-to: 6.7
Change-Id: I9f5b4a67a1a7862e6b89e76f2a6d55c8a2be1972
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QQuickWidget: don't set WA_AcceptTouchEvents on macOS 2024-03-04T15:55:25+00:00 Shawn Rutledge shawn.rutledge@qt.io 2024-02-29T23:22:49+00:00 2f1be4c51a1655697933468c10ba53316306d207 Usually, a QTouchEvent comes from a touchscreen, and we want those touch events in Qt Quick. But on macOS, there are no touchscreens, and WA_AcceptTouchEvents has a different meaning: since qtbase 03d057ff01332333b98f5298c3d0bd85b5604ac9, QApplication::notify() calls the native-integration function registertouchwindow() to change NSView::allowedTouchTypes to include NSTouchTypeMaskIndirect when the trackpad cursor enters the window, and removes that mask when the cursor exits. In other words, WA_AcceptTouchEvents enables getting discrete touchpoints from the trackpad. We rather prefer to get mouse, wheel and native gesture events from the trackpad (because those provide more of a "native feel"). The only exception is for MultiPointTouchArea, and it takes care of that for itself. So don't automatically set WA_AcceptTouchEvents on macOS. The user can still do it, but we don't recommend it. Amends dc8f44b14501ecd4acc196f5138aeff3f7502d0a Fixes: QTBUG-113384 Pick-to: 6.2 6.5 6.6 6.7 Change-Id: I8b0e1d247adfc95f1c9a0881a6020eab1a42b0ab Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> 
Usually, a QTouchEvent comes from a touchscreen, and we want those touch
events in Qt Quick. But on macOS, there are no touchscreens, and
WA_AcceptTouchEvents has a different meaning: since qtbase
03d057ff01332333b98f5298c3d0bd85b5604ac9, QApplication::notify()
calls the native-integration function registertouchwindow() to change
NSView::allowedTouchTypes to include NSTouchTypeMaskIndirect when the
trackpad cursor enters the window, and removes that mask when the cursor
exits. In other words, WA_AcceptTouchEvents enables getting discrete
touchpoints from the trackpad. We rather prefer to get mouse, wheel and
native gesture events from the trackpad (because those provide more of a
"native feel"). The only exception is for MultiPointTouchArea, and it
takes care of that for itself. So don't automatically set
WA_AcceptTouchEvents on macOS. The user can still do it, but we don't
recommend it. Amends dc8f44b14501ecd4acc196f5138aeff3f7502d0a

Fixes: QTBUG-113384
Pick-to: 6.2 6.5 6.6 6.7
Change-Id: I8b0e1d247adfc95f1c9a0881a6020eab1a42b0ab
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QQuickWidget: accept touchpoint even if it has a passive grab 2024-01-20T17:18:24+00:00 Shawn Rutledge shawn.rutledge@qt.io 2024-01-04T07:07:05+00:00 59b0b59090e2ff3f04bd15120720ee6a5b0c3f4b In the test case from QTBUG-113558, a QQuickWidget's only event-handling object is a TapHandler with its default gesturePolicy, so that on touch press, it gets pressed; but it was missing the touch release and getting stuck in pressed state. As explained in dc8f44b14501ecd4acc196f5138aeff3f7502d0a, widgets don't care about (exclusive or passive) grabbers, and rely on points being accepted to make the widget that received the TouchBegin an implicit grabber. If the only thing that happened in the Qt Quick scene in the QQuickWidget is that the touchpoint got a passive grab, it's still a kind of interaction, and we want to ensure that the TapHandler will see the release too, to avoid getting stuck. (This means that passive grabs are not passive from the perspective of widget event delivery: the TapHandler ends up excluding delivery of the touchpoint to other widgets, even though it didn't mean to. But hopefully nobody expects cooperation with touch-handling widgets underneath the Quick scene.) Fixes: QTBUG-113558 Pick-to: 6.5 6.6 6.7 Change-Id: Ided6247b43a2405dbfdf9d195bb45ceae4cf58fd Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 
In the test case from QTBUG-113558, a QQuickWidget's only event-handling
object is a TapHandler with its default gesturePolicy, so that on touch
press, it gets pressed; but it was missing the touch release and getting
stuck in pressed state.

As explained in dc8f44b14501ecd4acc196f5138aeff3f7502d0a, widgets don't
care about (exclusive or passive) grabbers, and rely on points being
accepted to make the widget that received the TouchBegin an implicit
grabber. If the only thing that happened in the Qt Quick scene in the
QQuickWidget is that the touchpoint got a passive grab, it's still a
kind of interaction, and we want to ensure that the TapHandler will see
the release too, to avoid getting stuck. (This means that passive grabs
are not passive from the perspective of widget event delivery: the
TapHandler ends up excluding delivery of the touchpoint to other
widgets, even though it didn't mean to. But hopefully nobody expects
cooperation with touch-handling widgets underneath the Quick scene.)

Fixes: QTBUG-113558
Pick-to: 6.5 6.6 6.7
Change-Id: Ided6247b43a2405dbfdf9d195bb45ceae4cf58fd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QQuickWidget: Clean up if RHI goes away under our feet 2023-12-22T23:10:50+00:00 Tor Arne Vestbø tor.arne.vestbo@qt.io 2023-12-19T20:52:05+00:00 0d342e83123b27befde95fc35760a358dbff0b16 The QQuickWidget doesn't normally own the RHI; the QWidgetRepaintManager does, via QBackingStoreRhiSupport. If the top level widget is destroyed, so is its QBackingStore, and the corresponding RHI. But the QQuickWidget may outlive its top level parent, in which case it needs to update its cached reference to the RHI, and do proper cleanup before it goes away. QRhiWidget already does the same thing, for the same use-case. This was observed when recreating the top level QWidget via destroy/create as part of the RHI widget compositor logic. Fixes: QTBUG-119760 Pick-to: 6.7 6.6 6.5 Change-Id: Ic44449abcfe4271660a3ac4e132d0c4a71a21b65 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 
The QQuickWidget doesn't normally own the RHI; the QWidgetRepaintManager
does, via QBackingStoreRhiSupport. If the top level widget is destroyed,
so is its QBackingStore, and the corresponding RHI. But the QQuickWidget
may outlive its top level parent, in which case it needs to update its
cached reference to the RHI, and do proper cleanup before it goes away.

QRhiWidget already does the same thing, for the same use-case.

This was observed when recreating the top level QWidget via destroy/create
as part of the RHI widget compositor logic.

Fixes: QTBUG-119760
Pick-to: 6.7 6.6 6.5
Change-Id: Ic44449abcfe4271660a3ac4e132d0c4a71a21b65
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Fix QQuickWidget rendering API mapping for D3D12 2023-09-04T12:55:03+00:00 Laszlo Agocs laszlo.agocs@qt.io 2023-08-28T15:42:34+00:00 76ae3dd78335b39d89b78480b6e9bf7364b3bd2c Right now requesting d3d12 via QSG_RHI_BACKEND or the C++ API maps to the Null backend of QRhi. That is not ideal. QRhiWidget has this logic, but the already existing QQuickWidget was not yet adjusted in 6.6 it seems. Pick-to: 6.6 Change-Id: I12301e815d525c14584b01dcd0caa787d1c79ad0 Reviewed-by: Andy Nichols <andy.nichols@qt.io> 
Right now requesting d3d12 via QSG_RHI_BACKEND or the C++
API maps to the Null backend of QRhi. That is not ideal.

QRhiWidget has this logic, but the already existing
QQuickWidget was not yet adjusted in 6.6 it seems.

Pick-to: 6.6
Change-Id: I12301e815d525c14584b01dcd0caa787d1c79ad0
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
QQuickWidget: give each mapped mouse event the same QEventPoint 2023-07-28T18:24:28+00:00 Shawn Rutledge shawn.rutledge@qt.io 2023-07-27T20:07:37+00:00 7ae07f49c1f7f86f37512c74bf0a49244ae46e1f Counter-intuitively, this is done by setting the timestamp. Every time you construct a new mouse event, you always need to call setTimestamp() for the obvious reason: the timestamp is not a ctor argument, but it's important for some event receivers. But the non-obvious reason is that QMutableEventPoint::setTimestamp() has other useful side effects: the velocity calculation is done there, sensibly enough. But to make that possible, it also looks up the persistent QEventPoint with the same ID as the one in the QMouseEvent, and that's the most important to fix QTBUG-114258 specifically. QQuickFlickablePrivate::handleMoveEvent() calculates delta as QEventPoint::position() - mapFromGlobal(globalPressPosition()) and then QQuickFlickablePrivate::drag() does the drag threshold check. If globalPressPosition() is 0,0 because the persistent QEventPoint was not passed along in the mapped QMouseEvent, that delta is nearly always over the drag threshold. So Flickable took the exclusive grab at the first possible opportunity: the second move after press. Fixes: QTBUG-114258 Pick-to: 6.2 6.5 6.6 Change-Id: Icaf7fb8fde0ef01b486ccf16852ef0f6cfb6a64c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> 
Counter-intuitively, this is done by setting the timestamp. Every time
you construct a new mouse event, you always need to call setTimestamp()
for the obvious reason: the timestamp is not a ctor argument, but it's
important for some event receivers. But the non-obvious reason is that
QMutableEventPoint::setTimestamp() has other useful side effects:
the velocity calculation is done there, sensibly enough. But to make
that possible, it also looks up the persistent QEventPoint with the same
ID as the one in the QMouseEvent, and that's the most important to fix
QTBUG-114258 specifically.

QQuickFlickablePrivate::handleMoveEvent() calculates delta as
QEventPoint::position() - mapFromGlobal(globalPressPosition())
and then QQuickFlickablePrivate::drag() does the drag threshold check.
If globalPressPosition() is 0,0 because the persistent QEventPoint
was not passed along in the mapped QMouseEvent, that delta is nearly
always over the drag threshold. So Flickable took the exclusive grab
at the first possible opportunity: the second move after press.

Fixes: QTBUG-114258
Pick-to: 6.2 6.5 6.6
Change-Id: Icaf7fb8fde0ef01b486ccf16852ef0f6cfb6a64c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Adapt to the RHI API concept 2023-05-22T10:08:08+00:00 Laszlo Agocs laszlo.agocs@qt.io 2023-04-27T12:32:59+00:00 ace43e1db17d1bfbf549a5c4c6ef49c3ccaf10fc Besides following the header naming changes, make the obvious API changes that are based on data that is already there but was hidden previously due to not wanting anything QRhi to shine through in the public API. This kind of hiding is no longer needed, even if qrhi.h and similar still cannot be included from a public header. Forward declarations are now perfectly fine however. Task-number: QTBUG-113331 Change-Id: I9a114082cf9218edc487df50956f5793d6b8bdb4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> 
Besides following the header naming changes, make the obvious API
changes that are based on data that is already there but was hidden
previously due to not wanting anything QRhi to shine through in the
public API.

This kind of hiding is no longer needed, even if qrhi.h and similar
still cannot be included from a public header. Forward declarations
are now perfectly fine however.

Task-number: QTBUG-113331
Change-Id: I9a114082cf9218edc487df50956f5793d6b8bdb4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>