summaryrefslogtreecommitdiffstats
path: root/src/widgets/kernel
Commit message (Collapse)AuthorAgeFilesLines
* Centralize maybeLastWindowClosed checking in QWindowTor Arne Vestbø2021-10-203-16/+17
| | | | | | | | | | | | | | | | | Instead of plumbing QWidgetWindow close events via handleCloseEvent, we just implement closeEvent directly. This allows QWindow do save the state of the window/widget before the close event, so that we know whether we should trigger lastWindowClosed handling, even if the window was deleted as a result of the close event. This also relieves QGuiApplication and QApplication from dealing with the close logic in their notify functions, so that these functions can focus on the propagation of events -- not how the event is handled. Change-Id: I8b586b53a53b1df1d8630c1acb635c60f191bb4b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't render widget to backing store if its parent has graphics effectAntti Määttä2021-10-191-1/+14
| | | | | | | | | | | | If widget parent has graphics effect, it can't render directly to the backing store, because the backing store needs to be updated from the parents effect drawing instead of the widget drawing. Pick-to: 6.2 5.15 Fixes: QTBUG-96240 Change-Id: Ib9b55547f9e5538f32837ec9df45d29fa68d7c1b Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QtWidgets: remove set-but-unused variablesThiago Macieira2021-10-161-2/+0
| | | | | | | | | Found by clang 13: qlayoutengine.cpp:80:9: warning: variable 'cMax' set but not used [-Wunused-but-set-variable] Change-Id: Iea05060bc2c046928536fffd16adf54d1527e657 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Deduplicate lastWindowClosed handlingTor Arne Vestbø2021-10-163-47/+9
| | | | | | | | | | | | | | | | | | | | | | | Whenever a window was closed, we had logic to check if it was the last window, and if so emitted lastWindowClosed and then tried to quit the application. But the automatic quit process also checked if there were any remaining windows, as this process could be triggered as a result of a QEventLoopLocker going out of scope. The two paths now share the same logic for determining if there are any remaining windows. The docs have been updated to reflect the original intent of the logic, dealing only with primary windows (top levels without a transient parent). This was how both the original code paths implemented their logic. For historical reasons the Qt::WA_QuitOnClose attribute is closely tied to the lastWindowClosed signal, and isn't merely limited to controlling whether we try an automatic quit when the last window closes. For now this behavior has been kept, but the docs have been updated to clarify how the attribute is handled in practice. Change-Id: If3d06b065236aad2e59e9091cac3146bc4cf79f6 Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove unused parentWidget variable in QWidgetPrivate::handleCloseTor Arne Vestbø2021-10-161-1/+0
| | | | | | | | | It was a leftover from when the quitOnClose logic was duplicated in the handleClose function. Change-Id: I38903b7e30ef1cf1d0dce87f61097a83259aea8e Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* widgets: Fix typos in source code commentsJonas Kvinge2021-10-153-3/+3
| | | | | | Pick-to: 6.2 Change-Id: I22f71a53b0f7f0698450123343e25548c889c3e2 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Clarify QWidget::normalGeometry documentationTor Arne Vestbø2021-10-151-13/+14
| | | | | | | | | | The property reflects the widget's current geometry if it is not in a full screen or maximized state. Pick-to: 6.2 Change-Id: I5816687119500995654a926aef952d788ad74886 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QWidget: Don't rely on topextra to determine if window is top levelTor Arne Vestbø2021-10-141-1/+1
| | | | | | | | | | Doing so results in bailing out early for a widget that hasn't been shown yet, or otherwise resulted in creating extra and topextra, which means the normalGeometry will not reflect the widget's geometry. Pick-to: 6.2 Change-Id: Ieb85e9a6109ae34fe20d79e3c12f4517f827a590 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Call QWidget close handling in QWidget::close for non-toplevel native widgetsDoris Verria2021-10-141-2/+4
| | | | | | | | | | | | | | Since commit 7ba75d0 we close the QWindow in QWidget::close for native widgets and trigger the closeEvent in QWidgetWindow. However, if the widget's window handle is not a top level window, QWindow::close() will not close the window, failing in this way to deliver the closeEvent and call the close handling in QWidgetPrivate::handleClose. To fix, call handleClose() from QWidget::close for such widgets. Task-number: QTBUG-74606 Pick-to: 6.2 Change-Id: Ied342eced3340aaf19b5443762935b1a5fc5c27b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix references to QGuiApplication::lastWindowClosedTor Arne Vestbø2021-10-131-1/+1
| | | | | | | | | The signal is emitted from QGuiApplication these days. Pick-to: 6.2 Change-Id: I7423cd4808e8df86960f225fd6e4a12a1a4f11f3 Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* macOS: fix window activation when popup is openVolker Hilsheimer2021-10-121-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On macOS, it is possible to right-click-open a context menu for a window that is not active. This does not activate the window. When then clicking into the window to activate it, the popup is closed, but only after the WindowActivate events has been sent. This blocks the event delivery, as QApplication (since commit 78264f333eb7c2623807) interpreted activation changes while popups are open to be just delayed focus events. The UI ends up in a broken state where focus cannot be set on the widgets in the window. To fix this, don't ignore such activation events on macOS. As a drive-by, give the variables more meaningful names. Note: We cannot call closeAllPopups before delivering WindowActivate, as that would close the popup before the mouse event is delivered, making it impossible to select any of the actions from the menu. Ideally, clicking into a popup of an otherwise inactive application would not activate that application (that is the default behavior for native macOS applications), but that's out of scope for this patch. Fixes: QTBUG-78750 Task-number: QTBUG-69710 Task-number: QTBUG-66513 Pick-to: 6.2 Change-Id: I6344370ae7be31630e37514e04918b2d6cb8b69a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* widgets: Fix typos in documentationJonas Kvinge2021-10-124-6/+6
| | | | | | Pick-to: 5.15 6.2 Change-Id: I6b77f0ec043d08da3b7958d780dce9595daf97a6 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Fix closing and showing a window with a native childVolker Hilsheimer2021-10-071-2/+5
| | | | | | | | | | | | | | | | | | | Closing a window with a native child results in the native child's QWidgetWindow being closed. That explicitly calls setVisible(false) on the child, which will still have the ExplicitShowHide attribute set from the initial (explicit) show. Even though we then reset the ExplicitShowHide, the WState_Hidden attribute will still be set, so Qt considers the window to have been hidden, and not show it again when the parent becomes visible. Add a test case. Fixes: QTBUG-96286 Fixes: QTBUG-79012 Fixes: QTBUG-71519 Change-Id: I482e6d5236c959d82ce66798176b259a3176972c Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Silence static analyzer warningVolker Hilsheimer2021-10-071-1/+1
| | | | | | | | | | | | | The static analyzer can't see that the QPointer not being null implies that the QWidget pointer is still valid. Since we reset the widget pointer to nullptr earlier on if the QPointer is null, just test for the widget pointer instead. Amends f6befd3e63fba32ae3f8329630e3ee4af3babbdc and fixes report 020fbdde70065e8de370537304d13d21. Change-Id: I715764956a02b1300766a3cea2d427f840f1cec8 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Clean up QApplication::notify codeVolker Hilsheimer2021-09-301-242/+197
| | | | | | | | | | | | | | | | | | | | Store isWidgetType and isWindowType once to avoid multiple tests, and use a single QWidget* variable for widget receivers once we handle those explicitly, rather than separate declarations for each event type. Fix indentation to make it more obvious that the entire switch statement is only executed for widget receivers. Remove unreachable code for QGraphicsWidget key handling. At that point, we already know that the receiver is a widget, which QGraphicsWidget is not, so this code was never executed anyway. Minor clean-ups, coding style improvements, and standardisations of repeating patterns. Change-Id: Idfe944f041ae82372b17082a5ffc4df13802359b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Don't clear focus if setParent doesn't change the parentVolker Hilsheimer2021-09-281-5/+7
| | | | | | | | | | | | | | | | | | | | QWidget::setParent might be called to change the window flags, without changing the parent. For those cases, we don't have to clear the focus. Decouple the newParent state from the wasCreated flag. In most places where newParent was tested, wasCreated was either tested previously and can't be false anyway, or the code executed is irrelevant for widgets that are not yet created (there can't be a paint manager). In the remaining case, test wasCreated explicitly to maintain existing logic. Add test for the cases where the previous code broke the focus, both for QWidget and QDialog. Fixes: QTBUG-93005 Pick-to: 6.2 Change-Id: I39dc179c2d348054de3927aa8b69eecef4935511 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Doris Verria <doris.verria@qt.io>
* Fix crash if receiver destroys itself in closeEventVolker Hilsheimer2021-09-271-5/+6
| | | | | | | | | | | | | | | | | | We allow QWidget::closeEvent to "delete this", and verify that this works in the tst_QWidget::testDeletionInEventHandlers test function. Sadly, that test didn't reliably catch the issue introduced in 28b14b966fe8535d7a81914b70759546b694e31b, where the receiver is accessed after the delivery of QEvent::Close. Handle the QWindow event delivery explicitly so that we don't need to access the receiver after the event has been delivered. There's nothing we can do to make the test fail more reliably in CI. A QWindow deleting itself in closeEvent will still crash; perhaps we don't want to allow that anyway. Change-Id: I2b5c2d11ded71c4f22ae9862cdc459e1f93b3374 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Remove special cases in enter/leave event handlingVolker Hilsheimer2021-09-241-4/+2
| | | | | | | | | | The Cocoa QPA plugin no longer tracks popups, but dispatches enter/leave events when popups show and hide. So the special handling in tests and QWidgetWindow can go away now. Change-Id: Ib6ef00689de231996e5e57ecdd8fd0d4c861d68b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Deduplicate maybeQuitOnLastWindowClosed handlingTor Arne Vestbø2021-09-173-26/+38
| | | | | | | | | | | | | | | | | | The functionality now lives in QGuiApplication, and is triggered by QGuiApplication and QApplication after dispatching the close event to the window. The slight difference between how a Qt GUI and Qt Widget app determines if a window should contribute to the close-on-quit behavior has been abstracted into a QWindowPrivate helper. The additional checks that were in place for skipping out of the whole maybeQuitOnLastWindowClosed machinery have been kept. Task-number: QTBUG-53286 Change-Id: I81bd474755f9adb3a2b082621e5ecaa1c4726808 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Always reset close-status of QWidget when trying to closeTor Arne Vestbø2021-09-151-5/+7
| | | | | | | | | | | | | | | | | Move the status setting and resetting back into handleClose so that we don't end up with it being set if handleClose is never called in response to a close attempt. This can happen when QWindow's platform window has already been destroyed. Since QWindow::close handles that case gracefully and returns true, we can safely call it multiple times. Add test coverage to verify that we get exactly those close event calls that we want. Change-Id: Ica77bf17c26d923c3b79b1e5a688addbc88a6277 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Make the closeAllPopup helper virtual in QGuiApplicationVolker Hilsheimer2021-09-152-11/+13
| | | | | | | | | | | | | | QPA plugins might have to close popups for events that are not delivered to QWindow or QWidget instances. For instance, the Cocoa plugin has to explicilty close popups when the user clicks into the window frame. Expose this functionality through a virtual in QGuiApplicationPrivate, and move the QApplication implementation from a static helper into the override. Task-number: QTBUG-96450 Change-Id: I52be5710c8d7515b9ae2e4bbadb069df4b3ed546 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* macOS: Compute NSWindow background color without checking styleMaskTor Arne Vestbø2021-09-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The check for styleMask == NSWindowStyleMaskBorderless to decide whether to clear the NSWindow background was broken, as NSWindowStyleMaskBorderless has the value 0, but is only supposed to be compared to its companion NSWindowStyleMaskTitled (with value 1). A window can perfectly well be NSWindowStyleMaskBorderless and NSWindowStyleMaskMiniaturizable e.g., so by comparing directly to NSWindowStyleMaskBorderless instead of masking to the first bit first we ended up making miniaturizable windows non-translucent. We now check the Qt::FramelessWindowHint directly, and also whether the window is opaque. Ideally we'd have QWindow flags that could plumb WA_NoSystemBackground from Qt Widgets, as well as a background color property on QWindow to control the system background, but in the meantime we'll have to use the FramelessWindowHint heuristic. The QWidget docs have been updated to reflect this. Task-number: QTBUG-95042 Pick-to: 6.2 Change-Id: I0d40eecace60883c205ebb8c76cef1092cdf1144 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Close QWidget during destruction via QWindowTor Arne Vestbø2021-09-131-1/+5
| | | | | | | | | Ensures that the QWindow and platform machinery is involved in closing the widget. Change-Id: I4ca4ed0b1b31b835d62d2fc0a2158e34e15d710e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't hide QToolTip automatically when another window is closedTor Arne Vestbø2021-09-131-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QTipLabel has a global application event filter, looking for reasons to close the tooltip. To fix QTBUG-55523 an additional condition was added in 7c18cb4f83c4907b40abc0bf40c1573b02243b57 to also close the tooltip when intercepting QEvent::Close, but this was unnecessary, as the fix in 29205c53e46fb2fc9f8063a46fd5ef5e9be532db was sufficient. Furthermore, hiding the tooltip on close events turned out to cause issues when the closing widget/window was the tooltip itself, causing recursion. This was fixed by 24239aef35f856c4c06428077e3428cbfdc51775. (which unintentionally also changed behavior for WindowActivate, WindowDeactivate, FocusIn, and FocusOut due to the case fallthrough). As it turns out, there is another case that will close the tooltip prematurely, and that's when the Qt::UI_AnimateTooltip effect is enabled, which is the case on e.g. Windows. In that situation a QRollEffect widget is created for the duration of the effect, which is then closed after the effect finishes. When closing the effect via QWidget close, we'll end up with a close event, triggering QTipLabel to hide itself. Since the logic of hiding the tooltip when other windows close was never needed to fix the original issue in QTBUG-55523, we opt to remove it completely, instead of adding even more heuristics to the code. Task-number: QTBUG-55523 Change-Id: I8d341262c85fd2e8cf9c496974e46ae0e9245e5c Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't exclude WA_DontShowOnScreen widgets for QWidgetWindow event processingTor Arne Vestbø2021-09-131-8/+8
| | | | | | | | | | | | | | | | | | The Qt::WA_DontShowOnScreen widget attribute does not limit whether a widget will be created (have a QWindow and corresponding QPlatformWindow). It only limits whether the widget will be shown. As a result, we need to respect and process incoming events on a QWindow level, just as any other window. Any considerations that may apply because of WA_DontShowOnScreen should happen further down in the event delivery. For example for the issue in 74aae00a4e8e70845e8092abbefa7830c386e66b, where QWidgetWindow::handleExposeEvent() cleared the WA_Mapped flag which was set by QWidgetPrivate::show_sys(). Change-Id: I187ebe14ea84538a3715f1d09fb1ba1ce93fcc82 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Set Qt::SubWindow on windows embedded by QWidget::createWindowContainerTor Arne Vestbø2021-09-101-0/+2
| | | | | | | | | | | | | | | The embedded window is parented into the containing QWindowContainer widget, which may either have a window handle itself, or is a child of a widget that has one (typically the top level). By setting Qt::SubWindow we inform clients about the embedded window's place in the world, allowing e.g. QPlatformIntegration::defaultWindowState to choose the correct state (Qt::WindowNoState) for the window instead of making it Qt::WindowMaximized on iOS. Pick-to: 6.2 6.2.0 Change-Id: Icf834192d99fee455aaba3c57bee1a4f1fde5025 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Split up close handling in QWidget into a pre and post stepTor Arne Vestbø2021-09-073-21/+30
| | | | | | | | | | If we are the one initiating the close (from Qt Widget land), we want to mark the widget as closing as early as possible. Clarified the role of close_helper by renaming it to handleClose. Change-Id: Iae250a0ae1583d743c59e99fcb99fdf18d2a1882 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Forward touchEvents to children inside QGraphicsProxyWidgetVolker Hilsheimer2021-09-061-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies the fix from 1ecf2212fae176b78c9951a37df9e33eb24d4f2d, using QApplication::translateRawTouchEvent to dispatch the touch event received by the QGraphicsProxyWidget to the relevant child widgets under each touch point. In addition, limit the implicit grabbing of each touch point before sending the event to those cases where we have to: touch pads, and if the target widget comes from a closest-widget matching. And don't call the QTouchEvent override of QEvent::setAccepted() on QTouchEvent instances in QGraphicsView classes, as this will override each event point's acceptance state. This way, we can identify which touch points have been accepted after event delivery, any only implicitly grab those points that were. Otherwise, touch points not accepted by a proxied widget hierarchy will still be part of an accepted event, and be grabbed by the viewport of the QGraphicsView. This would then lead to infinite recursion when the QGraphicsProxyWidget passes the TouchUpdate event on to each touch point's grabber. Re-activate the test case, and extend it with more combinations. Refactor touch-event recording to make it easier to test multi-touch scenarios. Task-number: QTBUG-45737 Fixes: QTBUG-67819 Pick-to: 6.2 Change-Id: Id5611f4feecb43b9367d9c2c71ad863b117efbcb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Doc: add more notes about full screen windows on macOSVolker Hilsheimer2021-09-031-3/+10
| | | | | | | Fixes: QTBUG-68069 Pick-to: 6.2 5.15 Change-Id: I8fc99f708cfa19a9c8cc8d13f6889549c79dd3b3 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Doc: fix qdoc warnings from wrong parameter typeVolker Hilsheimer2021-09-031-2/+2
| | | | | | | QWidget::addAction takes a QKeySequence, not a QShortcut. Change-Id: Ia10adcf50133b306d484a122ed17dddcf94372a6 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QWidget: close the QWindow in QWidget::closeVolker Hilsheimer2021-09-022-1/+28
| | | | | | | | | | | | | | | | | | | | | | | | | We want to close the window, end full screen mode on macOS, and free platform resources. This is all done by QWindow::close. QWindow::close closes the platform window, triggering a closeEvent to QWidgetWindow, which then calls QWidgetPrivate::close_helper. This way, closing a window via QWidget::close, QWindow::close, or interactively by the user are all equivalent. The QCloseEvent generated by the widget needs to be spontaneous for window-system generated events (i.e. the user clicked the close button), and non-spontaneous if the window closes because of a call to QWindow::close. To keep track of whether the event originated in an explicit call to QWindow::close, add a boolean to the QWindowPrivate. Add a test case that verifies that the window resources is destroyed, and that events are delivered as they should. Done-with: Morten Johan Sørvig <morten.sorvig@qt.io> Fixes: QTBUG-46701 Pick-to: 6.2 Change-Id: Iacb6a2c8d5e880b16b0c8f0c9257ed94bed36f5b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Revert "Forward touchEvents to children inside QGraphicsProxyWidget"Volker Hilsheimer2021-08-301-6/+2
| | | | | | | | | | | | | | | | | | | | | | This reverts commit 1ecf2212fae176b78c9951a37df9e33eb24d4f2d. The fix is not correct after all. TouchBegin goes to the correct widget with the fix, but following TouchUpdate and TouchEnd events now go to the viewport, as QApplication::translateRawTouchEvent always gives precedence to the widget that Qt recorded to be the touch grabber, which is the viewport. This results in infinite recursion, as the proxy widget trying to send the touch events to the embedded widget (expecting that translateRawTouchEvent will split it up) ends up sending the events back to the viewport. Leave the added test case as QEXPECT_FAIL, reactivate the (never run, hence unnoticed) test that the fix broke. Pick-to: 6.2 6.1 Task-number: QTBUG-45737 Task-number: QTBUG-67819 Change-Id: I4810affb3cd066743ae94ab7beb2f0c06b60d211 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Refactor QApplication::translateRawTouchEvent to take a QTouchEvent*Volker Hilsheimer2021-08-263-18/+10
| | | | | | | | | | | | Both call sites just pass the data from an existing QTouchEvent through, so just pass the QTouchEvent through instead. Amends 20d4f45a132606f7a910050d468519108486e9cf. Pick-to: 6.2 Change-Id: If3b9508b83311889b58e109e7f64743985b8b178 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Forward touchEvents to children inside QGraphicsProxyWidgetVolker Hilsheimer2021-08-262-4/+10
| | | | | | | | | | | | | | | | | | | | Just sending the event to the embedded widget is not enough, we have to perform hit-testing for the different touch points, and send the event to the child widget under the point. Fortunately, QApplicationPrivate::translateRawTouchEvent provides the logic that generates multiple events for groups of touch points. Since that helper always sent events spontaneously, add an optional parameter to allow sending of non-spontaneous events. Add a test case that simulates touch events to different widget configurations inside a QGraphicsProxyWidget. Fixes: QTBUG-67819 Task-number: QTBUG-45737 Pick-to: 6.2 6.1 5.15 Change-Id: Iffd5c84c64ee2ceadc7e31863675fdf227582c81 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QGraphicsProxyWidget: fix propagation of high-precision eventsVolker Hilsheimer2021-08-161-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | In order to fix QTBUG-95552 properly we have to add APIs to QGraphicsSceneWheelEvent that informs QGraphicsProxyWidget about whether the event is a high-precision event where Qt grabs the wheel. If it is, then the wheel grabber will be the QGraphicsView's viewport, and any wheel event sent to any widget will be grabbed by it. This results in infinite recoursion, partly fixed in change I78400ceae8da7a4e22a988c06ed58f99f1a979f4. The proper fix is to re-grab the wheel by the embedded widget if it (or any of its children) accepts the ScrollBegin event (and if not, return the grab to the QGraphicsView). This fixes the scenarios that failed in the test case, so now scrolling through nested widgets and scrolling in nested widgets works as the user would expect. Fixes: QTBUG-95552 Pick-to: 6.2 Change-Id: I3e1f31cbff999c70f8c63c034f77cd2ae567d7e3 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Don't crash in high-precision wheel scrolls on a QGraphicsProxyWidgetVolker Hilsheimer2021-08-161-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For high-precision wheel scrolling sequences, the widget that gets the first (typically ScrollBegin) event grabs the wheel. Qt directs all future wheel events within the same sequence (i.e. until ScrollEnd) to that widget. QGraphicsView passes wheel events through to the item under the mouse, and QGraphicsProxyWidget implements wheelEvent to forward a synthesized QWheelEvent to the embedded widget. Since QGraphicsView's viewport has already grabbed the wheel, any forwarded event would end up back in QGraphicsView, resulting in infinite recursion (if the assert doesn't fail first in debug builds). The correct fix requires that QGraphicsProxyWidget knows that this is a high-precision wheel event, allowing it to adjust the wheel grabber temporarily to the embedded widget. However, QGraphicsSceneWheelEvent doesn't provide this information. To fix the infinite recursion, mark the generated event as synthesized by Qt (but still send it spontaneously to enable propagarion within the proxy widget hierarchy). In QApplication's notification routine, interpret such events then to override the wheel grabber. Add a test case for the various scenarios. This 6.1 compatible fix does not pass all situations. A follow up commit that introduces the missing APIs to QGraphicsSceneWheelEvent then fixes those as well. Task-number: QTBUG-95552 Pick-to: 6.1 6.2 Change-Id: I78400ceae8da7a4e22a988c06ed58f99f1a979f4 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Accept the QWheelEvent before each propagation stepVolker Hilsheimer2021-08-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | Input events in Qt are accepted when constructed, and ignored by the default event handler (so overriding the event handler is enough to accept an event). Since we use the same QWheelEvent instance for each propagation step, we need to reset the event to be accepted before each delivery so that an earlier child ignoring the event doesn't result in the event being ignored without explicit acceptance. Amends the refactoring of wheel event delivery in 92df790f46b3a8b17aec2f385d6472fd3f8647f6. Task-number: QTBUG-95552 Task-number: QTBUG-79102 Task-number: QTBUG-67032 Pick-to: 6.1 6.2 Change-Id: Ib3f99792518364cf6e635cf4c6fda088051a7848 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Close all popup windows when the screen is rotatedTang Haixiang2021-08-121-0/+2
| | | | | | | | | | | | | Changing the screen orientation will cause the menu position to be displayed incorrectly. When the screen is rotated, the geometry of the application changes. We can refer to the handling of the menu on Android or IOS. Close the popup window when the screen orientation changes. Fixes: QTBUG-95607 Pick-to: 6.2 Change-Id: I55e1cd6a8b89e375c6714a9163dfb1902d52f101 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Doc: Minor cleanup in QWidget docsPaul Wicking2021-07-261-2/+3
| | | | | | | | | | | * Add missing . in \brief to silence warning. * Move relevant text about behavior change since 4.7 from the end to the start of the documentation block. Task-number: QTBUG-85839 Pick-to: 6.2 5.15 Change-Id: Id3671413f17d06023035c15fc7d5badbde59c5a6 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* QWidget: cope with QObject::connect()'s incomplete SFINAE-friendlinessMarc Mutz2021-07-241-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The plan for QObject::connect() (perfect) forwarders, such as QWidget::addAction(), was to just use a variant of the Detection Idiom to see whether QObject::connect() with the arguments as given would compile and SFINAE out the forwarder otherwise. It turns out that the "functor" overload of QObject::connect(), in particular, is severly underconstrained and accepts e.g. QKeySequence as a function object, only erroring out via a static_assert() in the body of the function, and thus at instantiation time and not, as needed, at overload resolution time. At the same time, we don't really want QObject::connect() to SFINAE out on argument mismatches between signal and slot, because the resulting error messages would be ... unkind to users of the API. We would like to keep the static_assert()s for easier error reporting. Reconciling these two contradicting requirements has so far eluded this author, so for now, to unblock progress, we explicitly black- and, in one case, white-list possible arguments. Because QKeySequence, in particular, is implicitly constructible from int(!), and therefore any enum type(!), incl. Qt::ConnectionType, we need to do way too much coding in the addAction() constraints. Hopefully, we'll be able to fix the issue at the root cause, in QObject, before Qt 6.3 is out, but until then, this is an ok-ish stop-gap measure. Add thorough overload set checks (positive ones only, for now) to tst_qwidget and tst_qmenu. Change-Id: Ia05233df818bc82ecc924fc44c1b349af41cbbf1 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use member function instead of template function to resolve native interfaceTor Arne Vestbø2021-07-171-3/+2
| | | | | | | | | | | | | | The use of a freestanding function is not needed now that the name doesn't alias the nativeInterface accessor function, and was just adding complexity to the machinery. People not familiar with the code will have an easier time following the flow through the helper member function, and we no longer need to declare our own export macros. Pick-to: 6.2 Change-Id: I17530b7e89939cfc19ab8ffaa076b7129ae02dcf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Improve error reporting when requesting unsupported native interfaceTor Arne Vestbø2021-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By switching out the static_assert for an enable_if we end up producing a clearer error, at the call site: /qt/qtbase/examples/gui/rasterwindow/main.cpp:69:9: error: no matching member function for call to 'nativeInterface' app.nativeInterface<QNativeInterface::QCocoaGLContext>(); ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /qt/qtbase/src/gui/kernel/qguiapplication.h:176:5: note: candidate template ignored: requirement 'NativeInterface<QNativeInterface::QCocoaGLContext>::isCompatibleWith<QGuiApplication>' was not satisfied [with NativeInterface = QNativeInterface::QCocoaGLContext, TypeInfo = QNativeInterface::Private::NativeInterface<QNativeInterface::QCocoaGLContext>, BaseType = QGuiApplication] QT_DECLARE_NATIVE_INTERFACE_ACCESSOR(QGuiApplication) ^ By using SFINAE for the TypeInfo we can also ensure that it works for types that are not native interfaces, such as if the user tries to call nativeInterface<QString>(). Since we can no longer use decltype(*this) to resolve the base type we need to change QT_DECLARE_NATIVE_INTERFACE_ACCESSOR to take the type as an argument, as we do for other QT_DECLARE_FOO macros. Pick-to: 6.2 Change-Id: Ie3f7e01ab7c3eb3dcc2ef730834f268bb9e81e0c Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QWidget: copy Q{Menu,ToolBar}::addActions() functionsMarc Mutz2021-07-132-1/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since any QWidget can have actions since at least Qt 5.0, it makes no sense to keep the addActions(text) etc. convenience functions that have traditionally existed in QMenu and QToolBar only in these two classes, where, to add insult to injury, they were just copies of each other, increasing library size for no real reason. So, add them to QWidget, too. This will allow us to de-duplicate the code between QMenu and QToolBar, too, which will be done in a follow-up patch, subject to BC constraints. [ChangeLog][QtWidgets][QWidget] Added the same addAction(text) overloads that previously existed only on QMenu and QToolBar, with the following two differences: First, the QKeySequence object, if any, is now available on all overloads, not just the ones taking a slot, but has changed position to allow, secondly, passing an optional Qt::ConnectionType parameter which will be passed to the QObject::connect() call. In addition, the function template overloads are now properly constrained so that they exist if and only if the corresponding QObject::connect() call does, too. Change-Id: Ifc3c2789600cf603192de8224fecbf9c88d91970 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Repolish child widgets when parent style sheet changesVolker Hilsheimer2021-07-051-1/+10
| | | | | | | | | | | | | | | | | | | If a child widget that is affected by the parent's style sheet is polished (because it's been shown explicitly, for instance by a layout), then it must be repolished when the parent's style sheet changes, even if the parent itself has not been polished yet. Since the style sheet is set on the parent widget, we must repolish the parent (which will repolish the entire widget tree), not just the individual children and grand children. Fixes: QTBUG-76945 Task-number: QTBUG-39427 Task-number: QTBUG-18958 Change-Id: I7bca9ee1badc07202fa05dc97f440f4ca6c9517d Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* Migrate to autogenerated cpp exportsAlexey Edelev2021-06-252-14/+2
| | | | | | | | | Replace the hardcoded cpp exports with a generated one where it's applicable. Task-number: QTBUG-90492 Change-Id: Idc160b594987b2c765e75bd669aae851b4366282 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Consistent indentation for all Q_PROPERTYsAndreas Buhr2021-06-244-10/+20
| | | | | | | | Task-number: QTBUG-94407 Pick-to: 6.2 Change-Id: I8c97a0b2de2bed78456322be271724fc47479d83 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Do not alter a widget's backing window's format once createdLaszlo Agocs2021-06-181-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changing anything on a QWindow's QSurfaceFormat has zero and null effects once the underlying native window has been created. Letting QWidget update the format is wrong in this case, because we always expect that the value returned from QWindow::format() reflects reality. (reality being the settings with which the underlying native resource was created, which is typically frozen after QWindow::create(), not the state of some QWidget attribute. There are certain exceptions to this, such as when preparing to recreate the underlying native window, in which case one will want to update all relevant fields of the format based on the current values of the widget attributes, which is exactly what QWidgetPrivate::create() implements, and that's good.) Such a mismatch can have fatal consequences when OpenGL and friends are involved, but this always depends heavily on the platform and windowing system. For example, claiming that the alpha buffer size is 0 when the native window was created with 8, or vice versa, can break OpenGL-related code (both in Qt itself and in applications), that tries to create a QOpengGLContext configured based on what QWindow::format() returns. If that format describes settings that are incompatible with the actual underlying native window, we end up with the classic Invalid pixel format, EGL_BAD_MATCH, and alike errors. This is exactly what is happening when a QOpenGLWidget (or QQuickWidget) is placed in a QDockWidget where one of the ancestors is forced to native (winId() was called or WA_NativeWindow was set). When undocking, various code paths in QWidget will try to update the opaque flag of the widget, which in turn calls updateIsTranslucent. Now, if this function unconditionally changes the alphaBufferSize in the QWindow's QSurfaceFormat (even though this is completely futile to do, it has no visible effect in practice), we get the problem described above: rendering breaking down due to OpenGL contexts created with a pixel format incompatible with the native window. Prevent all this by not touching the format once the QWindow has a QPlatformWindow. This is the right thing to do, regardless of the bug in question: a window's (or context's or any other native resource wrapping class's) format must describe the underlying native resource and must never deviate, unless we are preparing to create a new native resource underneath. When it comes to the autotest, this changes the test added in 555661b625c40f21a6a3e4c73e928a6e8a46db20: the autotest logic is inverted because what we should test for is that the QSurfaceFormat stays untouched once the application makes a - futile - attribute change on the widget. Fixes: QTBUG-85714 Pick-to: 6.2 6.1 Change-Id: I7bf90711867e8a0fd474895625bf9530a7821fd5 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Deliver WindowActivate/Deactivate events to QWindowVolker Hilsheimer2021-06-111-0/+1
| | | | | | | | | | We need those events to trigger palette color group changes in QQuickItem without having to connect every item to yet another QWindow signal. Task-number: QTBUG-93752 Pick-to: 6.2 Change-Id: I8534808cdaab828e5876f8fda31567aeb1b4272a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Partially modified to use C++11 standard nullptrXiao YaoBing2021-05-272-2/+2
| | | | | Change-Id: Ibfd76357ceb56b347afe7122fc252b866b21cb11 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Doc: Use \deprecated instead of \obsoletePaul Wicking2021-05-262-5/+5
| | | | | | Task-number: QTBUG-93990 Change-Id: I4e512354a49dde6678ca89cabc56bc76ba666bb3 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 11:30:17 +0000