aboutsummaryrefslogtreecommitdiffstats
path: root/src/quickwidgets
Commit message (Collapse)AuthorAgeFilesLines
* Doc: Use explicit links instead of auto-linkingDavid Boddie2025-11-071-2/+3
| | | | | | | | | This ensures that QDoc will always link to the QML types page and not to the corresponding C++ classes overview. Change-Id: I60cd6475ecf87190101507e8508e5c9403a2ed90 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Doc: add links to the QQuickWidget examples to the submodule pageAlexei Cazacov2025-10-011-0/+9
| | | | | | | | | | This commit adds links to the QQuickWidget examples to the Qt Quick Widgets page. Task-number: QTBUG-134102 Pick-to: 6.10 6.9 6.8 Change-Id: If63d106de76a3150025d8a5bfb91007a15b1d02f Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
* a11y: support attributes for QQuickWidgetVolker Hilsheimer2025-06-162-2/+2
| | | | | | | | | | | | Follow up on the addition of QAccessibleWidgetV2 in qtbase, which also implements the QAccessibleAttributesInterface to report the widget's locale. Pick-to: 6.10 Change-Id: I9704e25342b4ca73c9b6aa6a97194870b4e6212b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: MohammadHossein Qanbari <mohammad.qanbari@qt.io> Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
* fix QQuickWidget memory corruption in setSourceMasoud Jami2025-04-021-2/+2
| | | | | | | | | | | | If the root object of the Qml document is unknown to QQuickWidget, it produces a segmentation fault, since obj is deleted once in the setRootObject method, and once when its unique_ptr goes out of scope. Fixes: QTBUG-133832 Change-Id: I828616b390348762b144f81ed43e1883ecf38584 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* QAccessible: Improve accessibility for QQuickWidget offscreen itemsMohammadHossein Qanbari2025-03-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This commit addresses an issue where the accessible interface (QAccessibleInterface) returned nullptr as the accessible parent for quick items managed by QQuickWidget. The problem arose because the accessible path from the application to the quick items correctly passed through the QQuickWidget, but the reverse path was broken due to the root item's parent returning the QQuickWidget's window instead. To resolve this, the patch implements a check in qaccessiblequickitem.cpp to determine if the item's window is a QQuickWidgetOffscreenWindow. If so, it uses the associated QQuickWidget as the accessible parent. Additionally, in qquickwidget.cpp, we set a "parentWidget" property on the offscreen window when creating its instance, ensuring that it references its corresponding QQuickWidget. The test case creates an instance of QQuickWidget inside the QWidget. Then it verifies that the accessible items can reach to the quick widget. Fixes: QTBUG-130116 Pick-to: 6.8 6.9 Change-Id: I431e7e1aba6f7e64a2d5a0c1273ab7b008b962de Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQuickWidget: Add loadFromModule API's for pairity with QQuickViewAndy Nichols2024-12-083-9/+71
| | | | | | | | Rename the imported module name as "TestModule" since "Test" would clash with uri name "test". This fixes resizeOverlay test failure. Change-Id: I5796d74624f51863b2c6894eeebb6e87783199de Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Replace deprecated QImage::mirror(ed) with flip(ped)Volker Hilsheimer2024-12-021-1/+1
| | | | | | | | Follow up on change in qtbase:577946c1f05aaaa2a3f9682001aeb4144386b26b. Task-number: QTBUG-129575 Change-Id: I5f25e98d8991fae6ddd9cc2d875bba91cdfbdd88 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Alert when we are notifying semi-dead change listenersVolker Hilsheimer2024-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add virtual methods "baseDeleted" and "debugName" to QQuickItemChangeListener that let us report whether the object that implements QQuickItemChangeListener is already being destroyed. Add a "safe" version of QQuickItemChangeListener that overrides that virtual method using CRTP: if the derived class that it is instantiated with has a member "inDestructor" (e.g. a QQuickItemPrivate) or "wasDeleted" (e.g. a QObjectPrivate), then return the value of that variable. If the derived type is a QObject or QQuickItem, access the member via QQmlData::wasDeleted. Ignore calls on listeners that are the same object as the caller. Use that new type in those classes where it isn't immediately obvious that they clean up after themselves: classes that don't implement a destructor are a red flag. In addition, add a list to safe listener version to add/remove each item it's listening on. Issue runtime warnings in developer-builds when listeners are called for which baseDestroyed() returns true, and when listeners are destroyed while they still have items on their list. Task-number: QTBUG-98790 Change-Id: I15ed66a36556caa0e6acf5b768dec2ae92b01d64 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickWidget: resize offscreen window before its content itemVolker Hilsheimer2024-11-211-0/+1
| | | | | | | | | | | | | | | | | | | | Overlays are positioned so that they are centered over the content item within the window. If the window has a null-size when this is computed, then the overlay ends up being misplaced, and overlay-provided services, such as modality or closing popups, stops working for parts of the UI. Fix this by resizing the offscreen window before resizing the content item. Add a second test case that verifies that the overlay geometry is as it should be, both after the initial show, and after resizing the widget. The existing resizeOverlay test doesn't use a proper QQuickOverlay, so it doesn't cover all the relevant code. Fixes: QTBUG-125135 Pick-to: 6.8 6.5 Change-Id: I682d87f07051d213d3bd58c1c2533c84b50a3139 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickWidget: Update initial contentItem sizeDavid Edmundson2024-11-081-0/+1
| | | | | | | | | | | | | | | QQuickwidget manually keeps the window contentItem size in sync with the window whenever the window resizes. This is needed as resizeEvents are not sent for non-platform windows which normally takes care of the sync. The initial setGeometry call changes the window size without the contentItem size. This leads to the wrong contentItem size until the widget resizes later. Fixes: QTBUG-128935 Pick-to: 6.8 Change-Id: Ib184b5d0ced7c3609705abb3ad8e3d621a39a761 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* Add missing includesFabian Kosmale2024-10-241-0/+1
| | | | | | | | | | ...in preparation of trimming down includes in QQuickItem. As a drive-by, remove the superfluous qqml.h include from quick/items/qquicktextutil_p.h. Change-Id: I7ee0f459bcbfdfe07314d1f63433aaa8639870ac Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QQuickWidget: Assign focus to offscreen window when focus chain wrapsMohammadHossein Qanbari2024-10-011-6/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The focus did not move from QQuickWidget to sibling widgets. Additionally, when focus moved to QQuickWidget via tab/backtab key events, the item that was focused before the focus moved out was refocused. This is expected when the focus reason is not tab or backtab. In such cases, it is expected that the first/last item should be focused due to tab/backtab focus reasons. To address this issue, QQuickWidget checks the next/previous candidate in its child items through the focusNextPrevChild() method. If QQuickWidget cannot find any candidates, it should behave like a QWidget. Otherwise, it simulates a tab/backtab focus event for the offscreen window (QQuickWindow) to determine which item should be focused. The test case demonstrates a window containing a QQuickWidget with three rectangle items, a middle widget, and another QQuickWidget with three rectangle items. It then sends some Tab and Backtab events and verifies that the expected order of items and widgets is followed. The expected order varies depending on the direction of focus change (forward if the Tab key is pressed and backward if the Backtab key is pressed). [ChangeLog][QtQuick][QQuickWidget] The first/last item must be focused when QQuickWidget receives a focus-in event due to tab/backtab reasons. In other cases, such as ActiveWindowFocusReason, the item that was focused before will be refocused. Pick-to: 6.8 Change-Id: Ie25e6c2c46e20e15a5db014e0054b8b9da2d8a21 Reviewed-by: Doris Verria <doris.verria@qt.io>
* QQuickWidget: Add setInitialProperties API for pairity with QQuickViewAndy Nichols2024-09-033-5/+31
| | | | | Change-Id: Ie04ff09a950bb98d35d4c2d19e5a205d4a08437a Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QQuickWidget: Clamp texture sizeLaszlo Agocs2024-08-151-1/+11
| | | | | | | | | | | | | | Copy the behavior from QQuickRhiItem, which handles this correctly. The older QQuickWidget seems to lack that logic for some reason. Also add a qWarning to make it clear what is happening, because clamping the texture size may cause unexpected results in the visual output. Pick-to: 6.8 6.7 6.6 6.5 Fixes: QTBUG-123636 Change-Id: I08d4ac23f709c85dc975c030fd198127d7eb4d23 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* QQuickWidgets: Don't recreate root item on window changeOlivier De Cannière2024-06-191-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, QQuickWidgetPrivate::execute() was used in QQuickWidgetPrivate::handleWindowChange to reset the state of the root component and reparent it to the new window. This is only performed if there is a source, presumably to create the new root element from the latest available one. This however doesn't seem necessary as setting a new source already calls execute() meaning the current root element is already based on it. Therefore, it should be sufficient to simply reparent. This change fixes QTBUG-126136. When calling setLayout in MyWidget, the root element is reparented and this leads to qSendWindowChangeToTextureChildrenRecursively() and ultimatly handleWindowChange() being called. There the root element get's deleted and recreated within execute. Back in the user code, this has the visible effect of breaking the connection that had been created as well as leaving the pointer to the deleted root element dangling. This problem was partially hidden in 6.5 and from 6.7.0 onwards by 1bd755465efa27294362925f55306f88f1800936 when it prevented qSendWindowChangeToTextureChildrenRecursively() from being called from QWidget::setParent(). Pick-to: 6.8 6.5 Fixes: QTBUG-126136 Change-Id: Id7c820a88f2c0265ea9a3c1e3f02a045356087d5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Remove the use of GENERATE_CPP_EXPORTS argumentAlexey Edelev2024-06-111-1/+0
| | | | | | | | | The behavior that argument was enabling is the default one now. Pick-to: 6.8 Task-number: QTBUG-90492 Change-Id: I11711d4c794f0b22169abb595b8ffad2eeb1300d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Enable QQuickWidget flushing to native child widgetsTor Arne Vestbø2024-06-041-6/+0
| | | | | | Pick-to: 6.8 Change-Id: Ibfb1c5ef725df154393328e20a4396e8cc1234ce Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Doc: Improve QQuickWidget constructor documentationKai Köhne2024-05-062-11/+10
| | | | | | Pick-to: 6.7 Change-Id: I5fdf9918432c4861ca40158789e0b4e03674b240 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQuickWidget: Set WA_AcceptTouchEvents in all constructorsKai Köhne2024-05-061-22/+21
| | | | | | | | | | | | 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 RHITor Arne Vestbø2024-04-031-17/+12
| | | | | | | | 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 grabbingLaszlo Agocs2024-03-061-1/+7
| | | | | | | | | | | | | | | | | 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 macOSShawn Rutledge2024-03-041-0/+17
| | | | | | | | | | | | | | | | | | | | | | | 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 grabShawn Rutledge2024-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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 feetTor Arne Vestbø2023-12-231-1/+17
| | | | | | | | | | | | | | | | | | | 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 D3D12Laszlo Agocs2023-09-041-0/+2
| | | | | | | | | | | | 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 QEventPointShawn Rutledge2023-07-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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 conceptLaszlo Agocs2023-05-221-1/+1
| | | | | | | | | | | | | | | 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>
* QQuickWindow track changes via DevicePixelRatioChange eventDavid Edmundson2023-05-111-2/+7
| | | | | | | | | | | | | Qt core gained a new event on the window when the dpr changes. This is important as the window DPR can differ from the screen device pixel ratio, it also allows us to get rid of one level of the screen connection tracking. Fixes: QTBUG-113236 Change-Id: I43f50a0ef98653553ea177dc72e1522036452496 Reviewed-by: Aleix Pol Gonzalez <aleixpol@kde.org> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix crashes after 645aaa25b17Michal Klocek2023-04-192-3/+9
| | | | | | | | | | | | | | | WebEngine during page setup can create and delete accessibility interface with QAccessible::deleteAccessibleInterface, which will later on tear down end with a crash as lambda function is called on non existing object. In case accessibility interface is deleted do not try to call repair window. Pick-to: 6.5 Task-number: QTBUG-108226 Change-Id: Ic052d1b6c9c60168fb32f81134263fc484ee654b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQuickWidget: don't crash in accessibility when reparentingVolker Hilsheimer2023-04-182-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QAccessibleQuickWidget delegates all calls to the QAccessibleQuickWindow, which it had as a member that was initialized at construction time to the offscreenWindow backing the QQuickWidget. Both are QAccessibleObject subclasses, and QAccessibleObject stores the object it wraps as a QPointer. The QAccessibleQuickWindow's object becomes null when that offscreen window gets destroyed (for instance, when reparenting). We might get called by the accessibility framework in that situation, as we are clicking a button and the hierarchy changes. To prevent crashes, we need to test for nullptr in QAccessibleQuickWindow. However, that alone would leave us with a useless QAccessibleQuickWindow, and in turn with a useless QAccessibleQuickWidget instance. The QAccessibleQuickWindow is not directly exposed to the accessibility framework, and all calls to it are dispatched through its QAccessibleQuickWidget owner. We can't repair the QAccessibleQuickWindow but we can replace it entirely if we manage it as a heap-allocated object. Use a std::unique_ptr for that, which we can reset with a new instance created from a new offscreen window in order to repair things. We can now either test in all functions whether the window's window is still alive. Or we can handle the destroyed() signal of the offscreen window. The latter solution is a bit more involved, but generally more scalable as we don't have to remember to check, and possibly repair, in each QAccessibleQuickWidget function. Pick-to: 6.5 Fixes: QTBUG-108226 Change-Id: Ib19c07d3679c0af28cb5aab4c80691cc57c4e514 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* Fix problem with subFocusItem on non-OpenGL QSGAllan Sandfeld Jensen2023-04-071-1/+1
| | | | | | | | | | | | | | | The subFocusItem state was forgotten because the old parent was deleted, before its focused child was reparented. The test doesn't pass on Android and makes the test process exit with error. Since it prints warnings that indicate issues further down in the RHI stack, we'll skip it for now on that platform. Task-number: QTBUG-112696 Pick-to: 6.5 6.2 Change-Id: Ibb32a11564ff6fbb2091c241d508f12479b234b0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* qquickwidget: Try to initialize rhi on renderSceneGraphDavid Redondo2023-03-171-6/+4
| | | | | | | | | | While d2f895969938b0a80906e9a91553750bbcb717c9 in qtbase makes sure that everything is reset on device loss, initializeWithRhi is only called on next resize or hide/show, so we set deviceLost so it is recreated on the next frame. Change-Id: I70bcf753d26e2660fd0f86d8c7b37206100d59c9 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix build with -no-feature-graphicsviewTasuku Suzuki2023-01-171-0/+2
| | | | | | Pick-to: 6.5 Change-Id: Ib0e2183362b43869885934a8b5f8dd17f0c4ea71 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQuickWidget: always accept touch events and grabbed event pointsVolker Hilsheimer2022-12-221-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A QQuickWidget contains a Quick UI, which can be expected to handle touch events, and it handles touch events by forwarding them to the QQuickWindow. So set the AcceptTouchEvents attribute and let the Qt Quick delivery machinery deal with the touch-mouse synthesis within the scene. Also, Qt Quick's event delivery might return event points as ignored after setting the exclusive grabber. Qt Widgets touch event delivery logic doesn't care about exclusive grabbers, and relies on the event points being accepted to make the widget that received the TouchBegin an implicit grabber. QQuickWidget needs to translate those states back, so accept all points that come back with a grabber. Add a test that verifies that a button in a popup gets all events, and that those events are translated correctly - without the fix, the "clicked" test fails, as the release is delivered, but with coordinates outside of the button. Also test that we can have two QQuickWidgets where each gets one touch point. Fixes: QTBUG-101736 Pick-to: 6.5 6.4 6.2 Change-Id: I3a2bf05fd297ae4d72b6e236ecd8e5ddac37ce06 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Update QQuickWidget::texture() override because of signature changeKristoffer Skau2022-12-052-4/+4
| | | | | | | | | | | | | To support stereoscopic rendering in QOpenGLWidget using the RHI backend QWidgetPrivate::texture return type was changed to accommodate the extra texture required. This patch fixes the override for QQuickWidget to return the new type, where the second texture is just a nullptr (not used). Change-Id: Ie2d8906ed6c974b1813c7a900e54343db04226aa Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Alessandro Portale <alessandro.portale@qt.io> Reviewed-by: JiDe Zhang <zhangjide@uniontech.com>
* Make the pipeline cache real and move some settings to QGraphicsConfigLaszlo Agocs2022-09-161-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The settings that were previously only controllable via environment variables get now a counterpart in QQuickGraphicsConfiguration. The env.vars. stay since most of them are fully documented so must continue to function as before. Now they just have a way to enable the same from C++, on a per-QQuickWindow basis (if being per-QQuickWindow is applicable, that is) Most importantly, productize and document the pipeline cache save/load feature. This now has support both for specifying a custom filename for saving to or loading from, and in case nothing is set explicitly it has an automatic solution similar to the Qt 5 era GL program binary cache, under the standard CacheLocation of the system. And it works for all the graphics APIs, storing whatever the QRhi returns as the "pipeline cache" blob. With the default threaded loop the new cache control APIs are a grand improvement: instead of having only the global environment variables (QSG_RHI_PIPELINE_CACHE_SAVE/LOAD), one can now control per-QQuickWindow from C++ where the pipeline cache is stored. This allows sophisticated applications to support caching shaders/pipelines for multiple windows in a sane way (i.e. with different cache files, this way no conflicts and overwriting of each others caches happen). It also allows pre-seeding (deploying the cache file to another device, thus accelerating the very first run of the application already) in a simple way: run with saving the cache contents to whatever file is desired (even better, loading can still happen from the standard cache location, so it is not necessary to start revisiting all views and states to get pipelines/shaders compiled if the application was used before), then ship the file and load explicitly from that. (the usual caveats apply: the cache is ignored if the GPU or driver version do not match; the exception being data from D3D11 as that is freely reusable between PCs) It turns out that having a nice API design is not ideal for the 'basic' render loop, but there is nothing we can do about it. While we now have a way to control the pipeline cache storage per-QQuickWindow, it won't actually work on a per-window basis with the basic loop because that uses the same QRhi for all windows, and so the API structure falls apart: having per-window settings that affect the underlying QRhi is actually futile. (but given that QRhi is not public there is no other choice really and for 'threaded' we still want a proper per-window solution) This could be addressed in the future by converting the basic loop to also use dedicated QRhis for everything (which may involve some caveats). For now it is documented that the basic loop will only take one window's settings into account when it comes to the cache. Note that there is no support for QQuickWidget. As the architecture is totally different, with the QRhi infrastructure controlled by widgets and the backingstore, that is out of the scope of Qt Quick to solve. The biggest change is the automatic pipline cache which is on by default, as long as no explicit filenames are given (it can be disabled in some other ways as well (env.vars/app.attribute), but this should rarely be needed in practice) This is expected to give a boost to all applications on all platforms, although the gains will be small on systems where the drivers employ their own persistent caches (which is quite common these days, esp. on Windows and macOS). Nonetheless there will still be small improvements, with milliseconds shaved off of the total time spent on compute/graphics pipeline creation during the lifetime of a QQuickWindow. Big improvements are expected to be visible with D3D and Qt Quick 3D: the cache stores the DX bytecode (Quick 3D's run time material shader building causes HLSL code to be compiled at runtime) so apps using View3D are expected to benefit a lot from this. Task-number: QTBUG-103802 Task-number: QTBUG-106545 Change-Id: I01269424784b02114b88c4a712cf64512ff68ed7 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-09-071-1/+1
| | | | | | | Task-number: QTBUG-105718 Change-Id: Id89ed14990804a5024183e75382cc539d4293da1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Fix non-OpenGL usage of QQuickWidget::setContent(QUrl(), nullptr, root)Allan Sandfeld Jensen2022-08-261-1/+4
| | | | | | | | We should not delete the user given root, but ensure it is reparented. Change-Id: I91dc57482ffa7f7faa91b70016c6369c8dc950ab Pick-to: 6.4 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Add license headers to cmake filesLucie Gérard2022-07-081-0/+3
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I72c89a98c42bbc9234d8495e9e503bec81d11037 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Use SPDX license identifiersLucie Gérard2022-06-119-330/+18
| | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QuickWidgets: includemocsMarc Mutz2022-04-291-0/+2
| | | | | | | | | | | Including moc files directly into their classes' TU tends to improve codegen and enables extended compiler warnings, e.g. about unused private functions or fields. Pick-to: 6.3 6.2 5.15 Task-number: QTBUG-102948 Change-Id: Ifdfd7fd73c3338c9ef66f8e7c9d49a00107594f9 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Add Qt Quick Widgets module landing pageAndreas Eliasson2022-04-041-0/+80
| | | | | | | Fixes: QTBUG-101964 Pick-to: 6.3 6.3.0 Change-Id: Id088bdeff8d266eee0ba241097e8c9d8e1f338fe Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Make QQuickWidget play nicer with the software backendLaszlo Agocs2022-03-252-5/+21
| | | | | | | | | | Launching with QT_QUICK_BACKEND=software should never lead to doing anything QRhi-related, neither in Qt Quick, neither on the Widgets side. Fixes: QTBUG-101884 Change-Id: I0dc47e04a0d32904db04f32a1db109029f8f4b44 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Make QQuickWidget QRhi-basedLaszlo Agocs2022-03-183-306/+292
| | | | | | | | | | | | When it comes to examples, quickwidget has the direct OpenGL usage removed because we want this example to be working with any graphics API. qquickviewcomparison, which features direct OpenGL usage within its Qt Quick scene, is renamed to a more descriptive name and is also getting a doc landing page. It continues to be requesting OpenGL (via QRhi) explicitly. Change-Id: Iae5b835441f3af229e9746e14dedbe9d1a62b2b9 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Make sure all private headers include at least one otherThiago Macieira2022-03-101-0/+1
| | | | | | | | | | See script in qtbase/util/includeprivate for the rules. Since these files are being touched anyway, I also ran the updatecopyright.pl script too. Change-Id: Ib056b47dde3341ef9a52ffff13ef677e471674b6 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Doc: Turn notes into section in QQuickWidget overviewKai Köhne2022-02-181-7/+12
| | | | | | | | | | The extensive use of notes in overview documentation should be avoided. All the notes are concerned with performance considerations, so let's group them together in one section. Pick-to: 6.2 6.3 Change-Id: I4854e078e35190726091b2ef6b7a674abda8b3b7 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Make sure QQuickWidget and its offscreen window's screens are always in syncVlad Zahorodnii2022-02-081-15/+11
| | | | | | | | | | | | | By default, the offscreen window is placed on the primary screen. However, if the parent widget argument is passed to the QQuickWidget's constructor, then QQuickWidget's and the offscreen window's screens can be different and that can create rendering issues, e.g. blurry text if the primary screen and QQuickWidget's screen have different scale factors. Change-Id: I10c62b5635664f943b11828773f14017f198a770 Reviewed-by: David Edmundson <davidedmundson@kde.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix focus for items inside a QQuickWidget in a QGraphicsProxyWidgetPaul Olav Tvete2021-12-071-6/+72
| | | | | | | | | | | | | | | | | | | | | | | | QQuickWidgetRenderControl::renderWindowFor() did not take the proxy widget into account, making it impossible to give focus to items inside a QGraphicsProxyWidget by clicking on the item. This patch is based on a patch by Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>, which fixed renderWindowFor(), but did not handle the case where a proxy widget was in multiple views. This version of the patch adds QQuickRenderControlPrivate::isRenderWindowFor(), which allows all the views of the proxy widget to handle focus. This patch also carefully preserves the non-obvious feature of the previous implementation where all windows are considered to have focus if QGuiApplication::focusWindow() == nullptr. [ChangeLog][QuickWidget][Quick items inside a QuickWidget that is inside a QGraphicsProxyWidget can now get focus by clicking.] Fixes: QTBUG-91479 Pick-to: 6.2 Change-Id: I4a6fbbbeda2d14b5a6d8eb8218d5b14a3404d9c3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Migrate to autogenerated cpp exportsAlexey Edelev2021-11-022-14/+2
| | | | | | | | | Replace the hardcoded cpp exports with a generated one where it's applicable. Task-number: QTBUG-90492 Change-Id: I4af021bf828e05c8d6f3f975befd3b6b2cf63462 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Check for nullptr in QQuickWidgetPrivate::render()Shawn Rutledge2021-06-041-1/+2
| | | | | | | | The static analyzer says offscreeWindow can be null: https://testresults.qt.io/codechecker/daily_analyses/qtdeclarative/dev/qtdeclarative-dev-20210604-1285b67a11/qquickwidget.cpp_clangsa_765c85feff0c596c102ea775bb61e6c7.plist.html#reportHash=be277e8f02c65d088658b2397b335b7c Change-Id: Idfb6b358044f2719157fd85f72538a1e1ad30a34 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-01 20:28:27 +0000