summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel
Commit message (Collapse)AuthorAgeFilesLines
...
* QDialogButtonBox: Don't set focus in a dialog with StrongFocus childrenAxel Spoerl2024-03-072-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A QDialogButtonBox with the first accept button becoming default, didn't explicitly set focus on such a button in a QDialog. d44413d526ec12ed83acd7343c2005782178c7ad implemented this missing functionality. It set focus to the automatic default button, unless the QDialog had a focusWidget() set. That has caused a regression, in cases where - the QDialog has a QWidget child with a Qt::StrongFocus policy, and - the QDialog is not yet visible, so focusWidget() returns nullptr. Amend d44413d526ec12ed83acd7343c2005782178c7ad: Implement a helper in QWidgetPrivate, that returns true, if a child with a given focus policy is found. Do not set focus to a QDialogButtonBox's automatic default button, when - not located inside a QDialog, or - a focusWidget() exists, or - the dialog has QWidget child with Qt::StrongFocus, that is not a child of the QDialogButtonBox. Add an autotest function. Pick-to: 6.7 6.6 6.5 Fixes: QTBUG-121514 Fixes: QTBUG-120049 Change-Id: I3c65ae36b56657f9af4a3a4b42f9b66e8bc5c534 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Mention QChronoTimer in API docsAhmad Samir2024-03-031-2/+3
| | | | | Change-Id: Iaf9fb31994f1580b2051dbd0b1b8eef2a218aa39 Reviewed-by: Thiago Macieira <[email protected]>
* Disconnect QWindowContainer::focusWindowChanged on destructionTor Arne Vestbø2024-03-031-0/+3
| | | | | | | | | | | | | | | | | | Regression after 9e78256579e8dc704066a98cb4816a1aab0e7e3b. Apparently the string based connection syntax is more lenient, as with PMF-style connects, we (correctly) get: ASSERT failure in QWindowContainer: "Called object is not of the correct type (class destructor may have already run)" when the QWidget destructor closes the QWindow and we get a synchronous callback from the platform that we've lost the focus window. Pick-to: 6.7 Change-Id: I8f25b3b050e11913ec0f0941eaf831c88b4249f9 Reviewed-by: Christian Ehrlicher <[email protected]>
* Add QWidgetPrivate::rhi() helper methodTor Arne Vestbø2024-03-013-8/+11
| | | | | | | | For accessing the RHI managed by the widget compositing machinery. Pick-to: 6.7 6.6 6.5 Change-Id: Ia3c1227cc2d9cfebe95611cad3dbcd7aa6f6f8c7 Reviewed-by: Axel Spoerl <[email protected]>
* Add QWidgetPrivate::closestParentWidgetWithWindowHandle helper methodTor Arne Vestbø2024-03-012-0/+20
| | | | | | | | | In contrast to nativeParentWidget(), we return the closest widget with a QWindow, even if this window has not been created yet. Pick-to: 6.7 6.6 6.5 Change-Id: Icac46297a6052a7a5698d752d4aa871bd5c2bdd8 Reviewed-by: Axel Spoerl <[email protected]>
* Remove QWindowPrivate::compositingTor Arne Vestbø2024-03-011-2/+0
| | | | | | | | | | | It was added for Android in a4f50269f82695fbd0dd344f87b4b355feff4333, for the case of QSurface::RasterGLSurface, but since 6.4 we no longer use QSurface::RasterGLSurface for composition. And the Android usage was removed in 2020ce5fd2478389c56f34742fdeee9cd24ca8a5. Pick-to: 6.7 6.6 6.5 Change-Id: I8dafe959c54e09b3a974253e15d184365141d559 Reviewed-by: Axel Spoerl <[email protected]>
* Fix -Wimplicit-fallthrough for clangTim Blechmann2024-03-012-0/+3
| | | | | | | | | | | | | | | | | | | Clang's `-Wimplicit-fallthrough` warnings are a little stricter than gcc's interpretation: switch (i) { case 0: foo(); case 4: break; } While gcc accepts the implicit fallthrough, if the following statement is a trivial `break`, clang will warn about it. Pick-to: 6.7 Change-Id: I38e0817f1bc034fbb552aeac21de1516edcbcbb0 Reviewed-by: Volker Hilsheimer <[email protected]>
* QApplicationPrivate::dispatchEnterLeave: remove dead codeAxel Spoerl2024-02-291-13/+0
| | | | | | | | | Remove #ifdef 0 section added in 2011. Task-number: QTBUG-121478 Pick-to: 6.7 Change-Id: I2154cd5616e2695af89cf4fc5ec9d1b3ae5572d5 Reviewed-by: Richard Moe Gustavsen <[email protected]>
* QWidgetRepaintManager: Use textureChildSeen to determine deferred updateTor Arne Vestbø2024-02-271-3/+3
| | | | | | | | | | | | We want to get rid of the QWindowPrivate::compositing member, as it is no longer needed for the Android backingstore, which it was first added for in a4f50269f82695fbd0dd344f87b4b355feff4333. We can use textureChildSeen instead to check if we're compositing. Pick-to: 6.7 Change-Id: If85b21f92c8253bf89543a7e81e03730023f8095 Reviewed-by: Axel Spoerl <[email protected]>
* Doc: Use QDOC_PROPERTY for QRhiWidget::autoRenderTargetPaul Wicking2024-02-262-3/+4
| | | | | | | | | | `autoRenderTarget` is a private bool that very much looks like it's used as a Q_PROPERTY. Use QDOC_PROPERTY for it to generate warning- free documentation. Pick-to: 6.7 Change-Id: Ia6255287f139ff23172c4fac96950e1a37eeef83 Reviewed-by: Topi Reiniö <[email protected]>
* Correct license in widget/kernelLucie Gérard2024-02-153-3/+3
| | | | | | | | | | | | | | | | | | According to QUIP-18 [1], all module files should be LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only or LicenseRef-Qt-Commercial OR GPL-3.0-only LGPD and non-LGPL licenses should not be mixed in a given directory. The files in this patch now match the other files in the same directory and QUIP-18 rule. [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: Ied60c775fbae38d6edeabc669f782b39d02c28f4 Reviewed-by: Kai Köhne <[email protected]>
* QRhiWidget: Register cleanup callback also on first RHI initTor Arne Vestbø2024-02-141-13/+15
| | | | | | | | | | | | | | | | | The first time ensureRhi() is called we don't have an RHI yet, and will adopt the top level's repaint manager's RHI. We need to register a cleanup callback for this RHI, so that if it goes away, we will reset our RHI pointer to null, just like when we switch from one top level to another (and get a new potential RHI). Without the reset, we would be working with a stale QRhi pointer, which we in most cases updated via a call to ensureRhi(), that picked up the new QRhi, but for good measure we should reset it if we can. Pick-to: 6.7 Change-Id: Iac6d8787b636675bbcb4358e8f0baad26187b0e2 Reviewed-by: Laszlo Agocs <[email protected]>
* QRhiWidget: Tear down resources before window has changedTor Arne Vestbø2024-02-141-1/+1
| | | | | | | | | | | | | | | | | | | We were handling QEvent::WindowChangeInternal, but based on what the code is doing, what the comments say, and what QQuickWidget does, the right event should be WindowAboutToChangeInternal. This fixes a crash when reparenting a QRhiWidget into another widget, where we could call removeCleanupCallback() on an RHI that was already gone. The fact that we have a stale RHI pointer at WindowChangeInternal time is still problematic, and caused by our call to addCleanupCallback not happening as it should for the first call to ensureRhi(), but this will be fixed in a follow up. Pick-to: 6.7 Change-Id: I054120e97a24a1f74af44b2d251470792f03f7f3 Reviewed-by: Laszlo Agocs <[email protected]>
* Add QPlatformIntegration::BackingStoreStaticContents capabilityTor Arne Vestbø2024-02-131-5/+3
| | | | | | | | | | | | | | This was a feature in Qt 4, but the only platform that carried it over to Qt 5 was Windows, in ab76593f18396e693f24066592244ca95e135ea2, and that's still the situation. As a first step in possibly implementing this on more platforms, lets replace the hard-coded check in QWidgetRepaintManager::hasStaticContents with a proper QPlatformIntegration capability check in the only call site. Pick-to: 6.7 Change-Id: I2067109f45116cd8c62facf7224cd748f19e845b Reviewed-by: Axel Spoerl <[email protected]>
* QWidgetWindow: Don't meddle with WA_WState_{Hidden/ExplicitShowHide}Tor Arne Vestbø2024-02-121-14/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In ccd3bf0871b81dfc09bb469b161f32dfb47ee53e we introduced code that would ensure that our call to QWidgetPrivate::setVisible() from QWidgetWindow would not result in WA_WState_Hidden being set. This code was later modified in 51300566ffe2ece2455e1d0479a556c5dbb3bb8e to apply to widgets that were explicitly shown/hidden. Unfortunately, the reset of the Hidden and ExplicitShowHide attributes would in some cases result in the widget having only ExplicitShowHide after being hidden, which is an invalid state. It also resulted in the widget having both Visible, Hidden, and ExplicitShowHide, if first being hidden via QWidget, and then shown via QWindow, which in turn prevented the widget from being hidden via QWidget::hide(). As we no longer rely on the adjustments to Hidden/ExplicitShowHide to fix QTBUG-73021, we can remove the entire logic. Any setVisible call to QWidgetWindow will either come from outside, in which case we should respect that and set Visible/Hidden via QWidgetPrivate, or the setVisible call is a result of QWidget itself (or its parent) showing the QWidgetWindow, in which case the QWidget visible state is already up to date and we skip the QWidgetPrivate::setVisible call. Task-number: QTBUG-121398 Task-number: QTBUG-73021 Fixes: QTBUG-120316 Pick-to: 6.7 Change-Id: I3174ad66b7e10c55aa99b7cb433267632169ca8f Reviewed-by: Richard Moe Gustavsen <[email protected]> Reviewed-by: Volker Hilsheimer <[email protected]> Reviewed-by: Qt CI Bot <[email protected]>
* Ensure QWidget::destroy() events and attributes match hiding the widgetTor Arne Vestbø2024-02-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When destroying a widget via QWidget::destroy(), we clear WA_WState_Created, and then delete the QWidgetWindow, which in turn hides the widget. But QWidgetPrivate::setVisible(false) skips hide_helper() if the widget has not been created, which leaves out important events such as the hide event, and even more important, fails to clear WA_WState_Visible. As a result, the widget is left visible (and mapped), even if it has been destroyed. This is normally not a big issue for the main use of destroy(), namely destructing the widget, but for cases where destroy() and create() is used to recreate the widget this is important. We now unconditionally call hide_helper() if the widget is not already hidden. As a result, the widget will correctly be visible=false after a destroy(). This in turn means we need to re-apply the visible state after recreating the widget when we detect a mismatch in RHI configuration. Due to our meddling of the Hidden and ExplicitShowHide attributes in QWidgetWindow private, a QWidet::show() will not have any effect after being destroy(). This is okey for now, as destroy() is internal to a widget, and we make sure to either update WA_WState_Visible and WA_WState_Hidden (in QWidgetPrivate::setParent_sys), or use the QWidgetPrivate::setVisible() code path directly, which doesn't have that issue. The root problem will be fixed in a follow up. Pick-to: 6.7 Change-Id: I77cb88d75e57f0d9a31741161fb14d618a653291 Reviewed-by: Volker Hilsheimer <[email protected]> Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Richard Moe Gustavsen <[email protected]>
* Restore window state of recreated top level widget, not closest QWindowTor Arne Vestbø2024-02-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we recreate a top level QWidget due to the RHI config not matching, we need to re-apply the window state, as the state is lost on destroy(). But we should do this on the QWidget we are recreating, not on its closest QWindow. These are usually the same, so it didn't matter in practice for most cases (besides the more convoluted way of getting to the QWidget's window). But if the top level widget does not have a winId yet, the call to find the closest QWindow via QWidgetPrivate::windowHandle() will traverse from the top level widget to its transient parent widget, via nativeParentWidget, which is strange and likely a bug. As a result of that, we would store the window state of the transient parent widget, and then, once we had created() the new top level, we would apply the window state to the top level, which now had a winId. We can simplify all of this by just storing and applying the window state on the widget we are re-creating. There's no need to go via the closest QWindow for this. We do however need to set the window state on the widget's window, as going via QWidget will just bail out since the window state hasn't changed. Amends c88211d1e4ac12eb2ae4990703a4f73c7085d624 Fixes: QTBUG-119795 Pick-to: 6.7 6.6 6.5 Change-Id: I0ad6e7bbac5f29d095cc643e9a7094784e9a2122 Reviewed-by: Volker Hilsheimer <[email protected]> Reviewed-by: Richard Moe Gustavsen <[email protected]>
* Harden WidgetAttributes debug stream operatorTor Arne Vestbø2024-02-021-9/+10
| | | | | | | | The call site may pass in a null-widget, so guard for that. Pick-to: 6.7 Change-Id: I631cb2fc105bad69faf3daaeac4b893457d27cc1 Reviewed-by: Edward Welbourne <[email protected]>
* Don't set ExplicitShowHide on children when showing parent widgetTor Arne Vestbø2024-02-012-23/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As a result of using QWidget::setVisible to show the child widgets we would end up also setting ExplicitShowHide. This is not in line with the intent of ExplicitShowHide, which is to flag a widget as explicitly shown/hidden by the developer, which in turn prevents Qt Widgets from toggling WState_Hidden when the widget is reparented. By using QWidgetPrivate::setVisible instead, we can show the child without setting ExplicitShowHide. As side effect of this is that we no longer reset WA_WState_Hidden from QWidgetWindowPrivate::setVisible(). This is an issue when the setVisible call comes as a result of destroying the QWidgetWindow, as that is an implicit hide, and should not result in the widget having WA_WState_Hidden. QWidget handles this case in hideChildren by not calling QWidgetPrivate::setVisible -- instead doing its own reset of WA_WState_Visible. We don't want to untangle this just yet, so as a workaround we detect that the widget is already !isVisible(), thanks to hideChildren having hidden it, and then skip the call to QWidgetPrivate::setVisible that results from QWindow::destroy(). Task-number: QTBUG-121398 Pick-to: 6.7 Change-Id: Ib5b4d9c84f0569124c5f3ca2169cabff18934e2d Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Axel Spoerl <[email protected]>
* Add logging, clarifications, and tests for QWidget show/hide behaviorTor Arne Vestbø2024-02-013-10/+66
| | | | | | | Task-number: QTBUG-121398 Pick-to: 6.7 Change-Id: I94b4c90c3bd515279417c88497d7b9bd5a362eae Reviewed-by: Axel Spoerl <[email protected]>
* Add QWidgetPrivate::isExplicitlyHidden() helper functionTor Arne Vestbø2024-01-314-5/+14
| | | | | | | | | To aid readability. Task-number: QTBUG-121398 Pick-to: 6.7 Change-Id: I3cb231584c2b7aee72e9f01c669fed1e01fbe475 Reviewed-by: Axel Spoerl <[email protected]>
* qWaitForWindowFocused: Pass timeout as QDeadlineTimerTor Arne Vestbø2024-01-252-5/+5
| | | | | | | | | | | We should avoid int-based timeouts nowadays, and prefer std::chrono, or for timeouts where Forever is a valid state, QDeadlineTimer. Discovered during API header review. Pick-to: 6.7 Change-Id: Ia56a67084c7a2f989951755fed5ffc161ed8f79e Reviewed-by: Marc Mutz <[email protected]>
* QWidget: Clean up state that depends on QWindow from ~QWidgetWindow()Tor Arne Vestbø2024-01-232-27/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were assuming that QWidget was in full control of QWidgetWindow destruction, via deleteTLSysExtra(), and that we could limit any cleanups to that function. But in some situations QWidgetWindow is destructed from other code paths, in which case we were left with dangling pointers to the QWidgetWindow in both QTLWExtra, as well as the backingstore. This can happen if there's a child widget hierarchy where there is not a 1:1 mapping between QWidgets and QWindows, for example if the window attribute WA_DontCreateNativeAncestors has been set. In this situation our normal recursion into children in QWidget::destroy() stops at the first widget without a window handle. When we then delete the top level QWindow, the QWindow destructor will delete any child QWindows, which includes our leaf QWidgetWindow. We should probably fix up QWidget::destroy to continue looking for children, even if we don't destroy the current child. But independently of that we should make sure the QWidgetWindow cleans up when it's being deleted, regardless of how it ended up there. There's further room to clean up the deleteTLSysExtra() function and friends, but that's been left for a later time. Fixes: QTBUG-120509 Pick-to: 6.7 6.6 6.6.2 6.5 Change-Id: Ib691df164d7c9c83cb464c0a6bf3bc2116e8ca43 Reviewed-by: Volker Hilsheimer <[email protected]>
* Do more QRhiWidget cleanups based on API reviewLaszlo Agocs2024-01-222-9/+9
| | | | | | Pick-to: 6.7 Change-Id: I339fb2ac2546b9d7b4b88cba89191e7a4311017f Reviewed-by: Volker Hilsheimer <[email protected]>
* QMetaTypeModuleHelper: mark instances constexprMarc Mutz2024-01-191-1/+1
| | | | | | | | | | Static and thread-local objects should be constexpr or constinit if possible. Task-number: QTBUG-100485 Pick-to: 6.7 6.6 6.5 Change-Id: I29088798a50d6278252c9088e7c191c4214b2e5b Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* QMetaTypeModuleHelper: suppress cppcoreguidelines-virtual-class-destructorMarc Mutz2024-01-181-0/+1
| | | | | | | | | | | | | | | | | | | | Says clang-tidy: destructor of '(unnamed struct at qmetatype.cpp:966:14)' is public and non-virtual in file:src/corelib/kernel/qmetatype.cpp line:966 col:14 static const struct : QMetaTypeModuleHelper Yes, these classes are polymorphic (because the base class is). Yes, the destructor is non-virtual (because the base class' one isn't, but it's also protected, so fine). But these classes are not used as base classes, so suppress the warning. Pick-to: 6.7 6.6 6.5 6.2 Change-Id: I75be86bca36a4a0e93d72acb1a0d2fe0dca1c505 Reviewed-by: Fabian Kosmale <[email protected]>
* Update QRhiWidget API based on review commentsLaszlo Agocs2024-01-183-62/+68
| | | | | | | | | | | | | | | | | | Spell out some API names in enum. Some functions are now protected. Remove property for autoRenderTarget. textureFormat -> colorBufferFormat. Used "fixed" instead of "explicit" and follow the above naming, so that explicitSize becomes fixedColorBufferSize. Pick-to: 6.7 Change-Id: I2fd6ad46033313a3febbb8846146021d5dd11010 Reviewed-by: Volker Hilsheimer <[email protected]>
* Widgets: pass widget to QStyle::pixelMetric()Christian Ehrlicher2024-01-161-1/+1
| | | | | | | | | | | | Make sure to pass the widget to QStyle::pixelMetric() as some styles might use this (e.g. the new windows styles) to determine the correct pixel metric. Pick-to: 6.7 6.6 6.5 6.2 Task-number: QTBUG-1857 Change-Id: I5c32f5af8b284749732b610e56b4e3d8c8ed1946 Reviewed-by: Axel Spoerl <[email protected]> Reviewed-by: David Faure <[email protected]>
* Widgets: Use pmf-style connectsChristian Ehrlicher2023-12-216-15/+15
| | | | | | | | | | Replace some more string-based connects with pmf-style to trigger a compiler error instead a runtime error if a signal or slot does no longer exists. Pick-to: 6.7 Change-Id: Ibc047cc935885a30ea58367fa97e9f962b87ca2c Reviewed-by: Axel Spoerl <[email protected]>
* QWindowContainer: Don't embed a QWidgetAxel Spoerl2023-12-211-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | Embedding a QWidget in a window container (via its windowHandle()) may cause crashes, e.g. during drag & drop and when the application goes out of scope. If a QWidget->windowHandle() is attempted to be embedded in a window container, return the pointer to the widget instead of creating a container. Add an autotest. Update documentation. [ChangeLog][QtWidgets][QWindowContainer] If createWindowContainer() is called with a QWidgetWindow argument, return pointer to the widget instead of new container. Pick-to: 6.7 Fixes: QTBUG-119113 Change-Id: Id052a03be13adce05bbd025d86270d265dfb662e Reviewed-by: Paul Wicking <[email protected]> Reviewed-by: Richard Moe Gustavsen <[email protected]>
* QWidget: deliver DragLeave events symmetricallyVolker Hilsheimer2023-12-201-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | If a widget received a DragEnter event that it didn't accept, then the UnderMouse widget attribute gets set. But the drag manager never got a drag target, so the DragLeave event was never delivered, leaving the UnderMouse attribute set incorrectly. We always need to send DragLeave events to the receiver, even if the DragEnter or DragMove was not accepted. Otherwise we are not in balance, and the UnderMouse attribute will remain set. This is a change of behavior and a very old bug, so only fixing this in unreleased branches. Test case added to verify that explicitly generated drag events result in the correct enter/leave events. [ChangeLog][QtWidgets][QWidget] DragLeave events are now always sent to the widget the mouse is leaving, even if it didn't accept the DragEnter event. Fixes: QTBUG-50403 Pick-to: 6.7 Change-Id: I5eae49da000fb4fea81f1767f0e73a06a6b78975 Reviewed-by: Tor Arne Vestbø <[email protected]> Reviewed-by: Christian Ehrlicher <[email protected]> Reviewed-by: Axel Spoerl <[email protected]>
* Sync QWindow visible state during QWidget destructionTor Arne Vestbø2023-12-201-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | A call to QWidget::destroy() will end up in QWindow::destroy(), which calls QWindow::setVisible(false). A call to QWindow::setVisible(false) on a widget's window will under normal circumstances end up in QWidgetPrivate::setVisible(), which in turn recurses back into QWindowPrivate::setVisible(), via QWidgetPrivate::hide_helper(), ensuring that the QWindow internal state is updated, visibleChanged emitted, and show/hide events sent. Durin QWidget::destroy() we end up in QWindow::destroy(), which calls QWindow::setVisible(false), but in this case the widget no longer has Qt::WA_WState_Created, so the hide_helper() call is skipped, and the corresponding QWindow is not kept in the loop. To work around this we could have checked for windowHandle() instead of Qt::WA_WState_Created before calling hide_helper(), but that had many other side effects, so we opt for a more targeted fix. Pick-to: 6.7 6.6 6.5 Change-Id: I68f80e5f7df9ee811afcd274a7ee4de31a110da5 Reviewed-by: Richard Moe Gustavsen <[email protected]>
* Set correct content size for tool tip labelSanthosh Kumar2023-12-151-3/+5
| | | | | | | | | | | | | | | | The tool tip content size uses an incorrect content margin, when it's constructed. This content margin has been reset to correct value when tool tip is positioned using placeTip(). But after that, the content size not been recalculated. This patch triggers updatesSize() to calculate content size with updated content margin values. Fixes: QTBUG-119752 Pick-to: 6.7 6.6 6.5 Change-Id: I454c8528505686f2724b897e4002f78f3049149a Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Volker Hilsheimer <[email protected]>
* Remove qDeleteInEventHandlerTor Arne Vestbø2023-12-141-3/+1
| | | | | | | | | | It's equivalent to delete these days, and has been for a long time, since 2011 in fact, when the last remnants of QT_JAMBI_BUILD were removed. Change-Id: I7703e41c04204844da4ee75fa251b361e0db4ead Reviewed-by: Fabian Kosmale <[email protected]> Reviewed-by: Volker Hilsheimer <[email protected]>
* Use Qt::WindowNoState for child windows/widgets shown via show()Tor Arne Vestbø2023-12-131-10/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Qt::WindowState enum is documented to specify the current state of top-level windows, and does not make sense for child windows. It's up to the client code to ensure any sizing of child windows/widgets, e.g. via layouts. Many of our QPA backends bail out on QPlatformWindow::setWindowState() for a child window. Ideally we would do this at a higher level, in QWindow, but that's a bigger task, and the semantics of what happens when a window is moved from being top level to child or back are not fully clear. As a first step, we ensure that the default window state when showing the window via show() is Qt::WindowNoState. Unfortunately, the QPlatformIntegration::defaultWindowState() API only takes into account the window flags, which sadly do not have a way to reflect whether the window is a child window or not (Qt::SubWindow is not a child window, see QTBUG-115729). We don't want to pass a QWindow to this API, as it would mean QWidget would need to create a window when requesting the default window state. Instead we hard-code the opt-out for child windows/widgets. [ChangeLog][Gui/Widgets] Child windows and widgets are now always shown in their normal state by show(). Pick-to: 6.7 Change-Id: Ie8caf2df2d854194b9985c9427a9eac1312aba65 Reviewed-by: Assam Boudjelthia <[email protected]>
* Add QTest::qWaitForWindowFocused for checking focus windowTor Arne Vestbø2023-12-092-0/+27
| | | | | | | | | As opposed to QTest::qWaitForWindowActive, which checks if the window is active, which is not a guarantee that the window has focus. Task-number: QTBUG-119287 Change-Id: I9fe65b0474095389f6518ebaaf07c71143b6f459 Reviewed-by: Volker Hilsheimer <[email protected]>
* Don't clear Qt::Window/ForeignWindow of QWidget if window is not top levelTor Arne Vestbø2023-12-061-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic was needed for the old QMacCocoaViewContainer, which was a QWidget, that set Qt::ForeignWindow, and hence Qt::Window, on its windowHandle(). The modern way of embedding a foreign window into a widget hierarchy is via QWindow::fromWinId() and QWidget::createWindowContainer(), which manages the foreign window as a child QWindow of the window container's window handle, instead of replacing or modifying the window container's own window handle. The opposite case is a QWidget embedded into a foreign/non-widget window hierarchy. Ideally, in this case, we should return false for isWindow(), as the function is documented to only return true for "if the widget is an independent window", and "a window is a widget that isn't visually the child of any other widget and that usually has a frame and a window title". This notion is used in many places, including in QApplication::topLevelWidgets(), which in turn affects the quit logic of QApplication to prevent quitting the application as long as the child/embedded widget is visible. Unfortunately, embedding the widget as a non-Qt::Window is not an option at this point, as we have a lot of code paths that assume isWindow() || parentWidget(), and these code paths break down in flames when we end up dereferencing the (non existing) parent widget. As a result of removing the logic, we can now embed a QWidget into a non-widget window hierarchy as a Qt::Window, without the removed logic resetting the widget back to a Qt::Widget on create(), which would send us into into the broken code paths described above. Removing this logic should not cause issues for child widgets backed by a native window, as those are created with Qt::Widget window flags, not Qt::Window, so we never relied on the removed logic to sanitize those window flags. Task-number: QTBUG-119652 Change-Id: Id6b8e5c67bf8f83af8c2f1594806f3419303b1a1 Reviewed-by: Richard Moe Gustavsen <[email protected]>
* QApplicationPrivate: remove unused wheel_scroll_linesChristian Ehrlicher2023-11-271-1/+0
| | | | | | | | | wheel_scroll_lines is no longer used so it should be removed. Superseded by QPA/WheelScrollLines. Pick-to: 6.6 Change-Id: I98fa58d5ad32d26ce3b8b8068b244a5a1789ad4f Reviewed-by: Volker Hilsheimer <[email protected]>
* Make QApplicationPrivate::active_window privateTor Arne Vestbø2023-11-203-12/+6
| | | | | | | | | | The active window of QApplication overlaps largely with the focus window of QGuiApplication. As a first step towards potentially removing the active_window member, make it private so we control access to it. Task-number: QTBUG-119287 Change-Id: I95785fea3ba4444db64063f4e4d3d3004465ef64 Reviewed-by: Volker Hilsheimer <[email protected]>
* Doc: Fix \fn template arguments for Qt WidgetsTopi Reinio2023-11-181-4/+4
| | | | | | | | | Upcoming changes to QDoc require accurate definition for template arguments in \fn commands. Task-number: QTBUG-118080 Change-Id: I3a193ca69a911ee2f62e7663aaf4c032a35ee5dd Reviewed-by: Luca Di Sera <[email protected]>
* QWidgetWindow: pass QPointF to QMouseEventChristian Ehrlicher2023-11-081-6/+6
| | | | | | | | | | | | | QWidgetWindow::handleMouseEvent() passed a QPoint to QMouseEvent which might result in a wrong result on high-dpi displays. Since the incoming event has a correct QPointF coordinate, use this for the QMouseEvent Pick-to: 6.6 Fixes: QTBUG-106262 Change-Id: Idbfdab19220cb06aa0a28eef4e6ab4cab1035d97 Reviewed-by: Richard Moe Gustavsen <[email protected]> Reviewed-by: Tor Arne Vestbø <[email protected]> Reviewed-by: Volker Hilsheimer <[email protected]>
* Restore WindowState when changing SurfaceTypeWladimir Leuschner2023-11-061-0/+2
| | | | | | | | | | Restore the WindowState, when a Window has to be recreated due to changed SurfaceType. Fixes: QTBUG-118194 Pick-to: 6.6 6.5 Change-Id: I40ba552cda9dfc8ab543611595c068f80b8fa1d6 Reviewed-by: Laszlo Agocs <[email protected]>
* Doc: Revise QWidget docsAndreas Eliasson2023-11-011-47/+42
| | | | | | | | | | | | | | Reviewing and improving the docs for QWidget is part of the objectives for the 2023 Q4 OKRs. Most of the work in this patch is fixing grammatical errors and typos. It is tempting to move much, if not all, of the Detailed Description content from the QWidget class reference page (qwidget.cpp) into its own overview/explanation page, which would be more in line with the diátaxis framework. But I think that should be a different patch. Fixes: QTBUG-117758 Pick-to: 6.6 6.5 6.2 5.15 Change-Id: Ibb3f367c4677f7e6615bc0cd39d0ffe921862cb9 Reviewed-by: Safiyyah Moosa <[email protected]> Reviewed-by: Topi Reiniö <[email protected]>
* Add missing timestamp to tablet eventsViktor Arvidsson2023-10-301-0/+1
| | | | | | | | | When copying the event for notify, timestamp was not set as it is for other input events. Pick-to: 6.5 6.6 Change-Id: I81bb89993027c902db2d1113605d6e6a0faf98f1 Reviewed-by: Shawn Rutledge <[email protected]>
* Convert tooltips example to snippetsVolker Hilsheimer2023-10-271-5/+14
| | | | | | | | | The important bits from the example are ~10 lines of code, no need for building a poor-man's version of a graphics or item view. Pick-to: 6.6 Change-Id: I7874c66765c5b46230c92846ee3de1ee83f47e45 Reviewed-by: Oliver Eftevaag <[email protected]>
* QGestureManager: port Q_FOREACH to ranged-for [6/6]Ahmad Samir2023-10-131-4/+2
| | | | | | | | | | | | | | These two QSetS are local to the function, the loop bodies don't modify them but they can't be made const due to the way they're filled. So use std::as_const and ranged-for. Un-blacklist the file, by removing "#undef QT_NO_FOREACH", and removing the source file from NO_PCH_SOURCES. Change-Id: I49b852aa865b0321d3e2f617466557d77143a32b Task-number: QTBUG-115803 Reviewed-by: Christian Ehrlicher <[email protected]> Reviewed-by: Marc Mutz <[email protected]>
* QGestureManager: port Q_FOREACH to ranged-for [5/6]Ahmad Samir2023-10-131-1/+1
| | | | | | | | | getGestureTargets() first parameter is a QSet created locally at the call site in deliverEvents(); and the loop body doesn't change it. Change-Id: I3484f7ecc9d85b22b45a123ccf75316d5316e031 Task-number: QTBUG-115803 Reviewed-by: Marc Mutz <[email protected]>
* QGestureManager: port FOREACH to ranged-for, local const QSets [4/6]Ahmad Samir2023-10-131-11/+11
| | | | | | | | | | Those QSetS are local to the function, make them const, proving that the loop bodies didn't change them, and the copy Q_FOREACH took wasn't needed. Task-number: QTBUG-115803 Change-Id: Iec2fc31fc060c59760a84dc45baf8fa16f62eb6d Reviewed-by: Marc Mutz <[email protected]>
* QGestureManager: port Q_FOREACH to ranged-for [3/6]Ahmad Samir2023-10-131-2/+2
| | | | | | | | | | | | | | | The "conflictedGestures" QHash is local to the function, and the code in the loop body doesn't change it. The "gestures" QList (the value in the QHash key/value pair) isn't changed in the loop (both the enclosing for-loop and the for-loop iterating over the QList itself): - the QGestureEvent constructor takes by const& so it couldn't have changed the QList So use a const QList& instead of a copy. Task-number: QTBUG-115803 Change-Id: I4d7f2f833fe0119b9c1ffa91b0cdba9561025382 Reviewed-by: Marc Mutz <[email protected]>
* QGestureManager: port to ranged-for [2/6]Ahmad Samir2023-10-131-5/+2
| | | | | | | | | | | | | | The enclosing iterator-based loop: the loop body doesn't modify the `m_objectGestures` QMap (the original loop was using const_iterators), so port to ranged-for by using asKeyValueRange(). The foreach loop: the loop body doesn't modify the `gestures` QList, so a simple port to ranged-for. Task-number: QTBUG-115803 Change-Id: I92ba7ff6ef878d7e4b7115a8fab87e95a6d93182 Reviewed-by: Marc Mutz <[email protected]> Reviewed-by: Christian Ehrlicher <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2025-11-03 23:08:37 +0000