aboutsummaryrefslogtreecommitdiffstats
path: root/src/quickwidgets/qquickwidget.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Enable QQuickWidget flushing to native child widgetsTor Arne Vestbø13 days1-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-061-10/+9
| | | | | | 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>
* 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 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-051-3/+3
| | | | | | | | | | | | | 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>
* 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>
* Use SPDX license identifiersLucie Gérard2022-06-111-38/+2
| | | | | | | | | | | | 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>
* Make QQuickWidget play nicer with the software backendLaszlo Agocs2022-03-251-5/+20
| | | | | | | | | | 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-181-281/+277
| | | | | | | | | | | | 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>
* 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>
* 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>
* Implement accessibility for QQuickWidgetMorten Johan Sørvig2021-06-011-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | The accessibility tree for the Qt Quick content should be rooted at the QQuickWidget, and not at the offscreen QQuickWindow. For this to be the case, several things must happen: - QQuickWindow must not report the child interfaces - QQuickWidget must report the child interfaces - The child interfaces must report the QQuickWidget as the parent Create accessibility interfaces for QQuickWidget and and QQuickWigetOffscreenWindow (which now gets a proper subclass), where the QQuickWidget interface reports the child interfaces and the QQuickWigetOffscreenWindow reports no children Change the code in QAccessibleQuickItem to use the true (visible) window, where needed. Fixes: QTBUG-67290 Change-Id: I387d0ef711138d248a8dd16eefc9839499b35eeb Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move event delivery from QQWindow to QQuickDeliveryAgentShawn Rutledge2021-02-241-3/+9
| | | | | | | | | | | | | | | | | | | | QQuickWindow owns QQuickRootItem which owns QQuickDeliveryAgent, so for every window there's an object responsible for event delivery, while the window itself is mainly responsible for rendering (separation of concerns). However, QQuickRootItem and QQuickDeliveryAgent can now be used in cases where the scene doesn't directly belong to a window, such as when a Qt Quick sub-scene is mapped somewhere into a Qt Quick 3D scene. In that case, we must remember which delivery agent was in use at the time when a QEventPoint is grabbed and deliver subsequent updates via the same DA. There's also a QQuickDeliveryAgent::Transform abstraction which subscene-management code (such as QQuick3DViewport) can implement, to provide a formula to map the window's scene coordinates to subscene coordinates; if defined, it will be used during delivery of subsequent updates to existing grabbers. Task-number: QTBUG-84870 Change-Id: I70b433f7ebb05d2e60214ff3192e05da0aa84a42 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* QQuickWidget/Documentation: Mention the need to set the graphics APIFriedemann Kleint2021-02-111-3/+7
| | | | | | Pick-to: 6.0 Change-Id: I3b60586604003e360070a0d481e1a3df2e087e5c Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* quickwidgets: fix build with -no-feature-messageboxNick Shaforostov2021-02-011-1/+3
| | | | | Change-Id: I51fb3064f12a0740434091ba696924090deaf839 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* fixs wayland qtwebeneine application webpage close crashMa Aiguo2021-01-151-2/+2
| | | | | | | | | change surface and buffer deleted order Fixes: QTBUG-88677 Change-Id: I4512c0c2f32f3240288bf640394644f2cc01ab80 Reviewed-by: Ma Aiguo <648709566@qq.com> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Port from devicePixelRatioF() to devicePixelRatio()Morten Johan Sørvig2020-09-281-6/+6
| | | | | | | This ports all of QtDeclarative. Change-Id: Ie6eb4d96b4d49fbed1e8be514d03e331549cd712 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix additional warnings from usage of deprecated APIsVolker Hilsheimer2020-09-161-3/+3
| | | | | | | | | | Replace more QLibaryInfo::location with QLibraryInfo::path Replace old event accessors APIs, including relevant comments. Change-Id: Ie205fc93b6e1c0dfb3dca9100fbde417ab68fc9f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Propagate focusObjectChanged signal (second attempt)Eskil Abrahamsen Blomfeldt2020-09-081-0/+13
| | | | | | | | | | | | | | | | When the focus object is updated from inside the Qt Quick scene, the signal needs to be propagated from the offscreen window to the widget's window, otherwise the input methods will not react to it. Also, we need to propagate the FocusAboutToChange event, otherwise the contents of the editor will not be committed when the focus object changes, and the input method can get into an invalid state. Fixes: QTBUG-61475 Change-Id: I44ba171c0e78ef8b2e0127cba8991f1f1cf13571 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Revert "QQuickWidget: Propagate focusObjectChanged"Eskil Abrahamsen Blomfeldt2020-09-021-1/+0
| | | | | | | | | | | | | | | | This reverts commit 9bfa722bc0b67e01f35d78e1165602e174ae3b02. During clean up of the patch, a bug was introduced which actually causes it to have no effect (except print out a warning), because the focusObjectChanged() signature is wrong. When the bug is fixed, it turns out that it actually breaks the QQuickWidget autotest. So this may have been a bit hasty. Reverting it and returning to the drawing board. Task-number: QTBUG-61475 Change-Id: Iac4507ee4c92d94b0db5b996dfa2206be564cfb3 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QQuickWidget: Propagate focusObjectChangedEskil Abrahamsen Blomfeldt2020-08-311-0/+1
| | | | | | | | | | | | | | | When the offscreen window focuses an item, make sure we set keyboard focus to the QQuickWidget in the widget chain. [ChangeLog][QQuickWidget] Fixed an issue where virtual keyboards and other input methods would not react to input fields inside a QQuickWidget. Fixes: QTBUG-61475 Pick-to: 5.15 Change-Id: Ice2905a33ab0f4669622367ddae2c0ed3a1f841c Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Revive QQuickWidget renderingLaszlo Agocs2020-08-311-0/+5
| | | | | | | | | | | Follows 3d03f4e989e0ae53569a1a2e390d71c41d91f329. After that patch nothing guaranteed that qt_registerDefaultPlatformBackingStoreOpenGLSupport() got called in QQuickWidget applications (unless they also use QOpenGLWidget, which is rare). This is now corrected. Fixes: QTBUG-86335 Change-Id: I0420bbf97ca6c72227aa58a1d083fef04f86a1f8 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Doc: Capitalize "GUI" correctlySze Howe Koh2020-08-301-1/+1
| | | | | | Pick-to: 5.15 Change-Id: I2230e2dcb7bc2497b5dbe71a22c21d84176b5e57 Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
* Fix more deprecated accessorsShawn Rutledge2020-07-291-3/+3
| | | | | | | Amends 212c2bffbb041aee0e3c9a7f0551ef151ed2d3ad Change-Id: I93b073c88af24ce6535371bb279c660799568297 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc:Update docs with cmake package informationNico Vertriest2020-07-021-0/+1
| | | | | | Task-number: QTBUG-85179 Change-Id: I14a1d01c8e983021461f72c5108383f4b277478b Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Follow QQuickGraphicsDevice changes in QQuickRenderTargetLaszlo Agocs2020-06-261-1/+1
| | | | | | | | | They are not strictly related of course, but the API pattern should be kept. We can also move away from the QSGTexture dependency which is good since that was never directly related. Change-Id: I9aedff5918443bda3d6e3ee1ea389071222d1ad7 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Rename setSceneGraphBackend to setGraphicsApiLaszlo Agocs2020-06-221-1/+1
| | | | | | | | | | | | | | | | ...and fix up the docs. The string-based setSceneGraphBackend() stays of course (the docs have been enhanced, however). The GraphicsApi enum-based overload is now renamed to setGraphicsApi(). Using the same name for both functions is a historical artifact, reflecting the evolution (5.0 - 5.8 - 5.14). In 6.0 we can give it a more appropriate name, since it does not have much to do with "backends" from the user's perspective. Change-Id: Id75dbf81f50a148797e5b5de9be4000153737473 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* QQuickWidget: do not crash when failing to make context currentLaszlo Agocs2020-06-221-1/+5
| | | | | | | | | | | | | | | ...in createFramebufferObject(), e.g. upon resizing. Certain systems have a problem with OpenGL contexts during resizing, according to user reports. We do not know why makeCurrent() would fail, so we cannot prevent the failure, but we can check the result of makeCurrent() and not go on doing GL stuff (which would almost certainly crash) without a valid context. Task-number: QTBUG-83319 Pick-to: 5.15 Change-Id: I50a4f4e06d636fa0ee41fb9b80e720500711854f Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove the GL/ANGLE-ish QQuickWindowPrivate::contextCreationFailureMessageLaszlo Agocs2020-06-161-2/+2
| | | | | | | | Not called in practice anymore, remove the corresponding condition in the basic render loop as well. Change-Id: I22d6091c900ce36665b9e7f6dc91cc9276528ff6 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Replace calls to deprecated QEvent accessor functionsShawn Rutledge2020-06-111-6/+6
| | | | | | | | | | | | | | | | | | | | Several event accessors were deprecated in qtbase/24e52c10deedbaef833c0e2c3ee7bee03eacc4f5. Replacements were generated by clazy using the new qevent-accessors check: $ export CLAZY_CHECKS=qevent-accessors $ export CLAZY_EXPORT_FIXES=1 $ ../qt6/configure -platform linux-clang -developer-build -debug -no-optimize-debug -opensource -confirm-license -no-pch QMAKE_CXX=clazy $ make $ cd ../../qt6/qtdeclarative $ find . -name "*.clazy.yaml" $ clang-apply-replacements . Task-number: QTBUG-20885 Task-number: QTBUG-84775 Change-Id: I1be5819506fd5039e86b4494223acbe193e6b0c9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Make render loops OpenGL cleanLaszlo Agocs2020-06-081-6/+5
| | | | | | | Task-number: QTBUG-84718 Task-number: QTBUG-84623 Change-Id: I14392c365a52ecc410362500bbe29b4dd7953007 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Remove winrtOliver Wolff2020-06-041-2/+2
| | | | | | | | | Task-number: QTBUG-84434 Change-Id: If8f57f00726868a3540c877d07fca761618e4f08 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix build without openglSamuli Piippo2020-06-021-2/+7
| | | | | | | ifdef code that is not available without opengl. Change-Id: I200e95e4bcf1ee361e84819454eade0bbcbd6669 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Fix QQuickWidget when RHI is disabledPeter Varga2020-06-021-1/+4
| | | | | | | | | Without this, scenegraph would still use RHI code path even if QSG_NO_RHI=1 is set. Task-number: QTBUG-79268 Change-Id: I189d1da1345c94cf53ba9cc2b15a506c06fff9b1 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Enable QQuickWidget with OpenGL over RHILaszlo Agocs2020-05-271-39/+81
| | | | | | | | | | | | | | | | | Also adapts to new NativeTexture format, where the actual handle is passed around instead of a pointer to it. [ChangeLog][QQuickWidget][Important Behavioral Changes] In earlier versions, the returned value from QQuickWidget::quickWindow() would persist for the life time of the widget. This is no longer the case, so if you are connecting to its signals, make sure you also connect to its destroyed() signal and update the connections when it is destroyed. Fixes: QTBUG-78638 Change-Id: I33cee8543ef1ff5d31555ed3ac18ba78c9c45102 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-17 21:23:35 +0000