summaryrefslogtreecommitdiffstats
path: root/tests/auto/widgets
Commit message (Collapse)AuthorAgeFilesLines
* macOS: Remove special cases in enter/leave event handlingVolker Hilsheimer2021-09-241-4/+0
| | | | | | | | | | 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>
* macOS: send enter/leave when a window opens/closesVolker Hilsheimer2021-09-241-3/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | Since macOS doesn't give us any event when a modal window opens, we need to do so ourselves explicitly so that the current mouse window gets a leave event when e.g. a popup opens, and an enter event when the popup closes again. The case for modal dialogs is partially handled by QGuiApplication already. Note: We cannot rely on the transientParent of the opening/closing window, as it's nullptr for QMenu windows even if the QMenu has a widget parent. Add a test for enter/leave events when a secondary window opens, covering both the dialog and the popup case. For the dialog case, we sometimes get two Enter events when the dailog closes, which we have to tolerate for now. To make the test pass on b2qt platforms, fix the offscreen plugin to explicitly send enter/leave events in the same way as Cocoa now does. Fixes: QTBUG-78970 Pick-to: 6.2 Change-Id: If45e43e625e8362c3502c740154f6a6a8962b9e9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QWidgetWindow: Stabilize test on XcbVolker Hilsheimer2021-09-201-0/+1
| | | | | | | | | | | | | | | | | Showing, hiding, and showing a window can result in the Xcb QPA plugin warning about qt.qpa.xcb: internal error: void QXcbWindow::setNetWmStateOnUnmappedWindow() called on mapped window The point of the test is to verify that we get a paint event on a window that is shown again after having been hidden, not to verify that async windowing systems can handle a show/hide/show sequence. So wait for the window being exposed before we hide it. Pick-to: 6.2 5.15 Change-Id: If91a9926613645e78e332dacff34bd57e4034b6f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Blacklist flaky testDimitrios Apostolou2021-09-201-0/+3
| | | | | | | Task-number: QTBUG-96270 Pick-to: 6.2 5.15 Change-Id: I3feb604c0c2f394b2915b3d98d3b02f469331a18 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Activate test of enter event delivery on macOSVolker Hilsheimer2021-09-171-3/+0
| | | | | | | | The test passes consistently in local test runs on macOS 10.15. Change-Id: I6f05b27d3cbf930475a435c41db267a00b1726b0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Remove conditioning on Android embeddedEdward Welbourne2021-09-174-12/+11
| | | | | | | | It is no longer handled separately from Android. This effectively reverts commit 6d50f746fe05a7008b63818e77784dd0c99270a1 Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Close QDialog via QWidget::close()Tor Arne Vestbø2021-09-161-2/+4
| | | | | | | | | | | | | | | By going via QWidget::close() we ensure that if there's a QWidgetWindow backing the dialog (which is almost always the case), we will plumb down to QWindow::close(), resulting in QEvent::Close events to the QWindow. Since we don't want QDialog subclasses to receive a call to a closeEvent override that they didn't receive before (and which they might interpret as rejection or cancellation), install a temporary event filter that eats the QCloseEvent resulting from the call to close(). Task-number: QTBUG-53286 Change-Id: Ie8f6f0cb3160acfd5865dc74f0a7b6d87f838724 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Always reset close-status of QWidget when trying to closeTor Arne Vestbø2021-09-151-0/+30
| | | | | | | | | | | | | | | | | 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>
* Unskip QToolTip::keyEvent test on macOSTor Arne Vestbø2021-09-091-15/+18
| | | | | | | | | The test was failing because it didn't account for the platform behavior. Task-number: QTBUG-30040 Pick-to: 6.2 Change-Id: I7c523c06f0bfa459c1532cee721718bebc1858c4 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Don't show QMessageBox::about(Qt) as modal windowsTor Arne Vestbø2021-09-091-2/+11
| | | | | | | | | | | | | | | | The system behavior is to not show these kinds of dialogs as modal, and we've documented that for QMessageBox. However, calling show() instead of exec() is not enough, as the default constructor of QMessageBox will set the modality of the widget to application-modal. We need to explicitly override this. [ChangLog][macOS] QMessageBox::about(Qt) now shows dialog non-modal, as documented. Pick-to: 6.2 Change-Id: I6bb59efb81feb23122276a9eede71b2f20c9d7c6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Forward touchEvents to children inside QGraphicsProxyWidgetVolker Hilsheimer2021-09-061-68/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Blacklist flaky QGraphicsWidget test function for macOSVolker Hilsheimer2021-09-061-0/+2
| | | | | | | | Counting repaints is unreliable on macOS. Pick-to: 6.2 Change-Id: Ifa1cf516a2cab94540bea005354d8311a2651d64 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add test-case for QWidget closing exits event loopVolker Hilsheimer2021-09-061-0/+31
| | | | | | | | | Also when closed by destruction, which as of today doesn't call QWidget::close and therefore also not QWindow::close. Pick-to: 6.2 Change-Id: I426255e2274eae9262243c769df2264fbaa915b0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add more QDialog unit test related to closing a dialogVolker Hilsheimer2021-09-051-0/+170
| | | | | | | | | | | | | | | | | QDialog today only hides itself during reject and accept, it doesn't close itself properly. This is problematic, as it doesn't close the QWindow. However, fixing this behavior must not result in duplicate calls to virtual function, or additional calls to virtual functions (such as closeEvent) without explicitly flagging the change in the changelog. Add more tests to document existing behavior so that we can identify such changes and verify the desired side effects. Pick-to: 6.2 Change-Id: I1f30701cd766eb3c7957751b51e8579d4542dd16 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QMessageBox: Reset clickedButton for each invocation of the dialogTor Arne Vestbø2021-09-041-0/+23
| | | | | | | | | | When showing a messagebox that has already been show we don't want to keep around the clicked button of the previous invocation. Pick-to: 6.2 Change-Id: Ib6f6293d40ab338c550ea344094db871ccf45c46 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* QWidget: close the QWindow in QWidget::closeVolker Hilsheimer2021-09-021-0/+66
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix QListView assert when the last row is moved in IconModeChunLin Wang2021-09-011-0/+217
| | | | | | | | | | | | | | | | | | | | | | | | | After the last row is moved, 0 will be returned when obtaining row and column data. At this time, QListView::doitemslayout will not call d->doitemslayout, so the QBspTree data structure will not be cleaned up, leaving a stale tree structure behind. This will trigger an assert during paintEvent handling if QListView is set to IconMode In QListView::ListMode the test for a valid model index doesn't use an assert. Call QListViewPrivate::clear explicitly if the column count is 0 so that the QBspTree and other data structures are cleared. Add a test case that simulates this scenario by implementing a model that returns a 0 column count for an index after the model structure was changed through a move of rows. Done-with: Volker Hilsheimer Fixes: QTBUG-95463 Pick-to: 5.15 6.1 6.2 Change-Id: I36419be5459b8ced930c619f538482ea1db4ad03 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Port to QImage and QPixmap deviceIndependentSize()Morten Sørvig2021-09-011-2/+2
| | | | | | | | | Replace the “size() / devicePixelRatio()” pattern with a call to deviceIndependentSize(). Change-Id: I9d9359e80b9e6643e7395028cd43e3261d449ae7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Revert "Forward touchEvents to children inside QGraphicsProxyWidget"Volker Hilsheimer2021-08-301-2/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* Move QGraphicsProxyWidget test into correct test caseVolker Hilsheimer2021-08-302-310/+315
| | | | | | | | | | | | | | | The test case was previously disabled, so tests were added to the QGraphicsView test instead. With the QGraphicsProxyWidget test active again, move the test cases where they belong. Amends 1ecf2212fae176b78c9951a37df9e33eb24d4f2d, 01aeb5f7e4fd977e9698fffdc7650897664ecb82, and 06235d36ae9d00366215e748d80ff0faed3c2124 Pick-to: 6.2 Change-Id: I208b8a418653cf0640c2e7c9f716fa69538ad7e9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Reactivate QGraphics(Proxy)Widget unit testsVolker Hilsheimer2021-08-305-543/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | They were de-facto disabled in the qmake build system, and didn't make it into the cmake build system either. The dependency to the fusion style is not a build-time dependency since the test uses the QStyleFactory to create the style, and if that fails, tests can be skipped at runtime. As a consequence of not being executed in CI for a long time, many tests failed. Also, many tests were commented out or skipped as broken, ambivalent, or nonsensical. Remove that dead code. The QGraphicsWidget::initialShow test doesn't test anything that initialShow2 doesn't test, but makes incorrect assumptions, so remove it and rename initialShow2 to initialShow. Failing tests frequently left QWidget objects undeleted, causing all subsequent tests to fails as well. Fix that with std::unique_ptr. Some tests are still unstable and fail on some platforms, handle that using QEXPECT_FAIL. The forwardTouchEvent test fails due to a bug in Qt introduced recently. Skipping it for now. Pick-to: 6.2 Change-Id: I405122ea9d4d150bd1d505d40b83fe39604de0f9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Forward touchEvents to children inside QGraphicsProxyWidgetVolker Hilsheimer2021-08-261-0/+168
| | | | | | | | | | | | | | | | | | | | 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: forward Window(De)Activate eventsVolker Hilsheimer2021-08-241-0/+55
| | | | | | | | | | | | | | | | | | The nested widget might be a QGraphicsView as well (documented to be supported), and QGraphicsScene maintains it's own activation status by counting Window(De)Activate events. We need to make sure that the embedded widget is informed about its activation status so that deeper nested children can receive focus. Forward WindowActivate/Deactivate events to the nested widget, which will pass it on to all its children. Add test case, which without this fix fails when verifying the inner scene's isActive state, or later when testing that focusInEvent is delivered to the embedded widget. Fixes: QTBUG-94091 Pick-to: 5.15 6.1 6.2 Change-Id: I4e0ecef50685ed081d15c7f76b6c1a4a40ed2682 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Fix QScroller::scrollTo failing in QGraphicsView with movable itemChunLin Wang2021-08-201-0/+30
| | | | | | | | | | | When forcing software scrolling through QScroller::scrollTo, it will start from (0, 0). QGraphicsViewPrivate::canStartScrollingAt should consider the locationof points, not just the flags of item. Fixes: QTBUG-70255 Pick-to: 5.15 6.1 6.2 Change-Id: Iebdd5568baa3bdb41c705204dadb2895cfe9c0e2 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Report ImAbsolutePosition for QLineEditTor Arne Vestbø2021-08-181-0/+5
| | | | | | | | | | | ImAbsolutePosition was added in f8dbed12266c42785c1e4758eed05833ec035f33, based on requirements on Android, but without an implementation for QLineEdit. It would seem sensible to fall back to the cursor position in this case, as QLineEdit doesn't support multiple blocks. Pick-to: 6.2 Change-Id: Iff1255270ceef069f03ce457df633d7b675f1a28 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* tests: Remove unused SRCDIR definesIevgenii Meshcheriakov2021-08-172-3/+0
| | | | | | | | | | | Remove SRCDIR defines from tests that don't use them. There is a standard define called QT_TESTCASE_SOURCEDIR that is available to all tests and serves the same purpose. Pick-to: 6.2 Change-Id: I2aa237739c011495e31641cca525dc0eeef3c870 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* QGraphicsProxyWidget: fix propagation of high-precision eventsVolker Hilsheimer2021-08-161-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Close all popup windows when the screen is rotatedTang Haixiang2021-08-121-0/+16
| | | | | | | | | | | | | 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>
* tests: Use QT_TESTCASE_SOURCEDIR defineIevgenii Meshcheriakov2021-08-112-3/+1
| | | | | | | | | Replace custom SRCDIR define with QT_TESTCASE_SOURCEDIR. The latter is automatically available to all tests to use and serves the same purpose but is not terminated by a slash. Change-Id: I62896d0fd84ac63ac1b74a459ec1646c6bde0a46 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Implement missing support for 'em' and 'ex' lengths in style sheetVolker Hilsheimer2021-08-101-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | The Qt style sheet reference claimed that Length properties can be specified in 'em' or 'ex' units, but that was never implemented. Add the missing implementation. Since the sizes depend on the size of the font of the current element, we cannot convert the units in the CSS parser, but have to do so in the QRenderRule constructor, where we can make a decision about which font to use if the style sheet itself doesn't specify a font. Fall back to the widget font if possible; otherwise it will be the application default font. The implementation translates em into QFontMetrics.height, identical to what is already done in the QCssParser. This is in line with the CSS specification, but contradicts our previous documentation which stated that 'em' means "width of M". Fix the documentation. Fixes: QTBUG-8096 Pick-to: 6.2 Change-Id: I145e2504ae3b19101a0d0dd63653466b6c2cec1d Done-with: Cristian Maureira-Fredes <Cristian.Maureira-Fredes@qt.io> Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QListView: fix AdjustToContents (sizeAdjustPolicy)Thorbjørn Lund Martsum2021-08-101-0/+42
| | | | | | | | | | | | | | | | | | | | Unlike an acceptable effect in QTableView + QTreeView setAdjustPolicy(QAbstractScrollArea::AdjustToContents) unfortunately didn't work for QListViews (and QListWidget). This patch corrects QListViews AdjustToContents behavior. [ChangeLog][QtWidgets][QListView] A more correct implementation of QListView::viewportSizeHint has been made. That implies that setting the sizeAdjustPolicy to AdjustToContent on QListView and QListWidget will now cause the view to size after the contents and avoid scrollbars. Pick-to: 6.2 Task-number: QTBUG-58749 Change-Id: I1675115f2348e2fcf0b2c39b451ef337e10eb872 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* testlib: Deprecate QWARN() in favor of qWarning()Tor Arne Vestbø2021-08-047-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The QtTest best practices documentations recommends using output mechanisms such as qDebug() and qWarning() for diagnostic messages, and this is also what most of our own tests do. The QWARN() macro and corresponding internal QTest::qWarn() function was added when QtTest was first implemented, but was likely meant as an internal implementation detail, like its cousin QTestLog::info(), which does not have any corresponding macro. This theory is backed by our own QtTest self-test (tst_silent) describing the output from QWARN() as "an internal testlib warning". The only difference between QWARN() and qWarning(), besides the much richer feature set of the latter, is that qWarning() will not pass on file and line number information in release mode, but QWARN() will. This is an acceptable loss of functionality, considering that the user can override this behavior by defining QT_MESSAGELOGCONTEXT. [ChangeLog][QtTest] QWARN() has been deprecated in favor of qWarning() Pick-to: 6.2 Change-Id: I5a2431ce48c47392244560dd520953b9fc735c85 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QWidget: cope with QObject::connect()'s incomplete SFINAE-friendlinessMarc Mutz2021-07-242-24/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Sync default action when checking tool button programmaticallyVolker Hilsheimer2021-07-221-0/+59
| | | | | | | | | | | | | | | | | | | | | | QAbstractButton::setChecked is not virtual, so QToolButton cannot override to synchronize the default action's checked state. This resulted in button and default action not being in sync when the checked state of the button was changed programmatically, while changing the checked state on the action kept the button in sync. Connect to the button's own toggled signal instead to keep the state of the default action in sync. Make it a unique connection to allow multiple calls to setDefaultAction, which are used by QToolButton to keep the button updated if properties of the default action change. Add a test that confirms that button and action are synchronized both ways, and that we only get single signal emissions when changing either programmatically. Fixes: QTBUG-95255 Pick-to: 6.2 6.1 Change-Id: I0e027faf1da763ef1878e46e85bfa70073c8bf82 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* emit layoutAboutToBeChanged timelyLuca Beldi2021-07-203-0/+208
| | | | | | | | | | | layoutAboutToBeChanged must be called before persistentIndexList as the user might create persistent indexes as a response to the signal Fixes: QTBUG-93466 Pick-to: 6.2 5.15 Change-Id: I73c24501f536ef9b6092c3374821497f0a8f0de4 Reviewed-by: David Faure <david.faure@kdab.com>
* Support pt units for sizes, as documentedVolker Hilsheimer2021-07-201-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | Declaration::lengthValue only supported 'px' sizes, but one can transform any 'pt' value into 'px' by multiplying with 1.33. Notes: this ignores display DPI, and instead follows the W3C definition of 'pt' and 'px' as absolute lengths [1]. [1] https://www.w3.org/TR/css3-values/#absolute-lengths 1pt = 1/72th of 1 inch 1px = 1/96th of 1 inch so the conversion is px = pt * (72/96). Add unit test that verifies this using QPushButton's icon-sizes property, also with changed font in preparation of adding support for 'em' and 'ex' units in a follow up commit. Task-number: QTBUG-8096 Pick-to: 6.2 Done-with: Cristian Maureira-Fredes <Cristian.Maureira-Fredes@qt.io> Change-Id: I58782e7ad0e2ff9d89ed695f8a23b1e584cfed64 Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* tst_QComboBox: fix -Wsuggest-overrideMarc Mutz2021-07-181-1/+1
| | | | | Change-Id: I6fce7f84cf1578ac0e4ee0b2d7da579b54d78ec3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* tst_QGraphicsScene: fix compiler warning about misleading indentationMarc Mutz2021-07-171-4/+4
| | | | | Change-Id: I532b5eeb0d4f9632f517deef61a7528bcb4151c6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QListView: don't scroll if selected items are removedVolker Hilsheimer2021-07-161-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | For SingleSelection, removing the selected item will select the nearest item and, if autoScroll is enabled, ensures that the newly selected item is visible in the viewport. This may result in scrolling. For Multi- or ExtendedSelection, this should not happen, as having no selection is perfectly fine in those modes. However, QListView still tried to scroll to the current item in response to the currentIndexChanged signal. Since the currentIndex is at this point already hidden, the rectangle for it became invalid, and the attempt to scroll resulted in a one-pixel up-movement of the viewport (since the invalid rectangle has width == height == -1). Fix this by not scrolling if the rect for the index is invalid. Note that the index is still valid at this point, so we can't shortcut the call stack earlier. Add test that exercises the different combinations of ViewMode and SelectionMode, and demonstrates the one-pixel movement without the fix. Fixes: QTBUG-94788 Pick-to: 6.2 6.1 5.15 Change-Id: I1f36973eadb46e8c9b8b8068bc76ee09e9f490dd Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QMenu/QToolBar: remove addAction() functionsMarc Mutz2021-07-131-0/+13
| | | | | | | | | | | | | | | | | | | | They're now in QWidget itself. Remove them from the API, but not the ABI. The QToolBar case is straight-forward. QMenu is a bit more complicated: Since QT_CONFIG(shortcut) builds changed the signature of an existing function instead of adding/removing an overload, we have to deal with two cases: In a QT_CONFIG(shortcut) build, these overloads that take a trailing QKeySequence parameter have been deprecated and therefore cannot be removed. In a !QT_CONFIG(shortcut) build, the same functions are 1:1 copies of QWidget functions and can be removed (from the API). [ChangeLog][QtWidgets][QMenu/QToolBar] The addAction() functions have been moved down into QWidget. Change-Id: I49997b3440c137a1d4e3858d1d27d34a191e1eed Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QTableView: fix selection with rows and cells in ExtendedSelection modeChristian Ehrlicher2021-07-121-0/+72
| | | | | | | | | | | | QTableView stored the current row/column selection start in an own variable instead using currentSelectionStartIndex. This leads to an inconsistent behavior when the selection is done with a click on the header and then in a cell (and the other way round) Fixes: QTBUG-92561 Change-Id: I4c8bda3a938de451b6eff2819141e86a6870fbef Pick-to: 6.1 6.2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix auto completion in QFileDialog on WindowsVolker Hilsheimer2021-07-091-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Amends c0b3c06a7d4f6a2f90742e8dc81c898082a70416. The QCompleter used by QFileDialog uses starts-with matching of the path parts, for all parts of the path. It uses the EditRole of the underlying model for the data to match. The path parts used for a path on Windows are "C:", "Users", "etc...", and then finally whatever input has been typed so far. If we try to match that against a starts-with rule against "Local Disk (C:)", then it will fail and the completer will never have anything to show. So, for the EditRole, return just the volume drive letter as we did before c0b3c06a7d4f6a2f90742e8dc81c898082a70416, not the volume name. Neither can be edited anyway. This happens to then match the native file dialog behavior, which doesn't complete "L" to "Local Disk (C:)" if the Computer contents (ie. volumes) are shown. Augment the QCompleter test case to cover that scenario (it already has everything set up for this particular combination, even though we are actually testing QFileSystemModel returning the correct data). Fixes: QTBUG-94799 Task-number: QTBUG-78043 Pick-to: 5.15 6.2 6.1 Change-Id: I14844d91601e9b16dc07cff2ca48713acb7cdd09 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Fix placement of placeholder text in QLineEdits with action iconsVolker Hilsheimer2021-07-061-0/+66
| | | | | | | | | | | | | | | | | | | | After dc794f7622bc00f7ca50fab65d6965695d6d2972, side widgets only got space if they were not fading out, but the logic was not correctly accounting for side widgets that never fade, such as buttons added via QLineEdit::addAction. Fix this to give visible widgets space, unless they are fading out. That was the intent of the original change. Rename the variable to make its purpose clearer, and reset it at the end of the fade-out animation. Add a much-needed test that relies on private APIs to verify that the effective margins are calculated correctly. Fixes: QTBUG-94824 Pick-to: 6.2 6.1 5.15 Change-Id: If2ee6be52be9e4f9be1e91f72f27681ce27def6d Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix memory leaks in tst_qlineeditAndreas Buhr2021-07-061-2/+2
| | | | | | | | | | | | In the unit tests, two times a validator was used without a parent, which led to memory leaks. This patch changes this: The validators are initialized with the widget they are meant for as parent. This fixes the memory leaks. Pick-to: 6.2 Change-Id: I480c0c5104cbe60159fad49df28cbb6240e7ce68 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
* Repolish child widgets when parent style sheet changesVolker Hilsheimer2021-07-051-0/+14
| | | | | | | | | | | | | | | | | | | 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>
* Use UTC when parsing only a date or only a time, not a date-timeEdward Welbourne2021-06-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This should reduce the amount of fall-out from DST complications. Also document the assumptions of QDateTimeParser's two fromString() methods (and fix the punctuation on the QDateTime parameter). Adjusted some tests to match. Since only QDateTime-returning methods will show the difference, and it's at least somewhat odd to be using those on QDateEdit or QTimeEdit, this should have little impact on API users. [ChangeLog][QtCore][Behavior Change] QDateEdit and QTimeEdit now operate in UTC, to avoid spurious complications arising from time-zone transitions (e.g. DST) causing the implicit other half to combine with the part being edited to make an invalid result. Returns from their dateTime() and other methods returning QDateTime (max/min) shall thus be in UTC where previously they were in local time. QDateTimeEdit continues using local time. The default can be over-ridden by setTimeSpec(), as ever. Change-Id: I44fece004c12342fe536bbe3048217d236fd97b2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix handling of day-of-week in QDateTimeParser and QDateTimeEditEdward Welbourne2021-06-231-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QDTP's absoluteMax(), setDigit() and getDigit() simply treated day-of-week as synonym for day-of-month. Consequently, QDTE::stepBy() did the same. This meant that wrapping happened at the month boundary, so would jump within the week if it wrapped around, otherwise the up/down arrow would "jam" at a particular day of the week when further steps would leave the month. Instead, when wrapping, wrap round the week while still moving the day-of-month to match, jumping back or forward a week to stay within the month on hitting a month boundary; otherwise, stop backwards stepping on hitting the locale-specific day of the week, or forward stepping when the step would be to or past this first day. Fixed various bugs found in the course of testing this. [ChangeLog][QtWidgets][QDateTimeEdit] Corrected handling of weekdays. Previously, changes to the week-day were simply changes to the day of the month. Weekday fields are now handled as such: changes to them do change the day of the month, but a change that would step past the end (or start) of the month is adjusted to the relevant day of the nearest week within the month. When wrapping is disabled, the locale-specific first and last days of the week are the bounds. Formats which specify day of week but not day of month will now preserve day of week when changing month or year, selecting the nearest day of month that matches. Change-Id: I7868b000fea7a4bc17a1b5687c44bcd56d42ae90 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QWidgetAction: add test for defaultWidget() being deleted before actionMarc Mutz2021-06-221-0/+12
| | | | | | | | | ... even though the documentation states that the action takes ownership of the widget. Change-Id: Ie5520fbda295a5a2774ff8b82165070e9d49e310 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* BLACKLIST tst_QListView::internalDragDropMove for OpenSUSE leapHeikki Halmet2021-06-211-0/+3
| | | | | | | | Task-number: QTBUG-94250 Change-Id: I9ea92b5952e1823cf90716f027f2f8eea1b86278 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 23:10:30 +0000