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>
... 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>
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
555661b625: 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>
child->widget() returns null if the layout item is not a widget.
Thus, calling removeWidget(nullptr) will remove all non-widget items
such as layouts or strechers.
Change-Id: I772c1158d0f7e8e2850b6e571b0405a2896f09b8
Pick-to: 6.0 6.1 5.15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Those tests don't fail anymore and show in CI as BPASS, so we
can safely, hopefully, unblock them
Task-number: QTBUG-87429
Fixes: QTBUG-68974
Fixes: QTBUG-69166
Fixes: QTBUG-87403
Fixes: QTBUG-87411
Fixes: QTBUG-69083
Fixes: QTBUG-69084
Fixes: QTBUG-87426
Pick-to: 6.1
Change-Id: I831b955116c0f465319b9c5fc726dd98804d1c00
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
contentsMargins is a Q_PROPERTY on a QLayout. Qt 6.1 introduced
QLayout::unsetContentsMargins() to reset the contents margins to the
"default" ones (that the user can't know); that's the textbook
description of a RESET function for the property.
Add some tests also for unsetContentsMargins.
[ChangeLog][QtWidgets][QLayout] The unsetContentsMargins() function now
acts as the RESET function for the contentsMargins property.
Change-Id: I463d88363c11f4a15ad3d6af71401d8698de1d41
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QGridLayout::takeAt() and QLayoutItem *itemAt() only check the upper bound.
If the index < 0, these function will return invalid pointer.
Fixes: QTBUG-91261
Pick-to: 5.15 6.0 6.1
Change-Id: Idfb9fb6228b9707f817353b04974da16205a835c
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Wayland doesn't support explicit window activation, so the
qWaitForWindowActive() function won't actually wait for the
window to be active.
On platforms like this, we just QTRY_VERIFY() for the window
activation instead.
Task-number: QTBUG-91418
Change-Id: I5f728e6a6bcaac283c026b60e6378b9d5aaf1be5
Reviewed-by: Liang Qi <liang.qi@qt.io>
The test assumed that a window was registered as the active
one immediately when it was exposed. This created a race
condition on Wayland, where we would often get the wrong
active window when simulating the events.
Task-number: QTBUG-91418
Change-Id: Ie41fe5adb339bbb43d5ee5db400a198e479de386
Reviewed-by: Liang Qi <liang.qi@qt.io>
Several tests failed due to side effects of client side
decorations. We explicitly disable this when initializing
the test to make things go smoother.
In addition, the setToolTip() test tries to set the mouse
cursor position programmatically, which is not possible
on Wayland.
And finally, the qWaitForWindowActive() falls back to
qWaitForWindowExposed() on platforms where explicit window
activation is not supported. This fixes a few issues, but
in cases like focusProxy(), it means we aren't actually
waiting for the WindowActivation event. Instead of testing
for exposed twice on such platforms (Wayland), we replicate
the logic from qWaitForWindowActive() instead and rely on
automatic window activation. If it fails, we do a QSKIP, so
this shouldn't cause any flaky test failures at least.
Task-number: QTBUG-91418
Change-Id: I767c881e7cdc91f43ad357294a2c6240ab1af43c
Reviewed-by: Liang Qi <liang.qi@qt.io>
Applications on macOS are automatically activated (put into the foreground),
when launched from the Finder, or via 'open' on the command line. But when
launched from the terminal, e.g. foo.app/Contents/MacOS/foo, the application
will launch in the background (inactive).
In Qt we override this behavior, activating the app even when launched from
the terminal, as a convenience, as long as the application is a GUI application.
Unfortunately this means that when tst_qapplication launches a subprocess that
is a GUI app, it will steal activation from tst_qapplication, which in turn
will break tests that later try to activate a window and check that the window
is then active. The window will not be active until the application is active.
We can work around it by preventing Qt from activating the application, but
ideally we'd find a better solution to this, as we don't want to sprinkle
overrides all over our tests.
Fixes: QTBUG-90699
Pick-to: 6.1 6.0 5.15
Change-Id: If53a86548002b739df0c0a7153d6244924a4a205
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
With the updated QEMU and toolchain, these tests now pass.
Change-Id: Icb74562a0e6422cd4564f63db991aa431e0e3119
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When setting the application's focus widget we search for the next
child widget that can hold the focus and call its setFocus() method,
which also updates focus widgets of all its parent wigets.
In case if the focus widget is the active window itself, we only set it
as the application's focus widget, but we don't update the focus widget
of the active window itself. Because of this the focusWidget() method
always results nullptr for the active window. This prevents from setting
the focus back to active window after the focus has changed (for example
after a context menu is closed, as in the bugreport).
Transfer the focus to active window by calling the setFocus() method, as
it is done in case of transferring the focus to any other widget.
Pick-to: 6.0 5.15
Fixes: QTBUG-85846
Change-Id: I91ebf182fd5bb7d451a1186e2f3e38c8d48acc4e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If a default font was not registered for the widget's class, it returns the default font of its nearest registered superclass.
Fixes: QTBUG-89910
Pick-to: 5.15 6.0
Change-Id: I6e6b2c6a0044462f84db9f76a03be0c6cfaaae8e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
setTabOrder was not considering the case, when a child widget has
its focus proxy set to its parent widget. This happens, for example,
for the QLineEdit that is nested inside the QAbstractSpinBox.
For such cases the lastFocusChild was calculated incorrectly, and, as
a result, such child widgets were not correctly positioned in the
focus chain. This could lead to an error while backtabbing.
Here is a brief example. Suppose we have 3 widgets arranged like this:
auto spinBoxOne = new QDoubleSpinBox;
auto spinBoxTwo = new QDoubleSpinBox;
auto button = new QPushButton;
Then the default widget focus order is:
- spinBoxOne
- lineedit (from spinBoxOne)
- spinBoxTwo
- lineedit (from spinBoxTwo)
- button
Before this commit setting the explicit tab order changed the focus
order in the following way:
QWidget::setTabOrder(spinBoxOne, spinBoxTwo);
QWidget::setTabOrder(spinBoxTwo, button);
- spinBoxOne
- spinBoxTwo
- button
- lineedit (from spinBoxOne)
- lineedit (from spinBoxTwo)
In this case, backtabbing from spinBoxOne actually leads us to
lineedit (from spinBoxTwo), which refers to spinBoxTwo.
And so we're stuck in a loop.
This commit fixes the issue by handling such special case, and
preserving correct focus order.
Note: the actual unit-test in this patch uses QLineEdit instead of
QPushButton, because one can't tab to buttons on macOS by default.
However the general idea is the same.
Pick-to: 6.0 5.15
Fixes: QTBUG-81097
Change-Id: I5d16da7733a4d63f809cab28b8ca9e116b87cffa
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Apparently some library definitions went overboard, link them directly.
Pick-to: 6.0
Change-Id: I009737f7e3edff5619241b700a627dc4e25e6018
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Android packages the test instead of qapplication folder, thus the
BLACKLIST file for Android tests needs to be in "test" folder
instead.
Task-number: QTBUG-87666
Task-number: QTBUG-87025
Change-Id: I065072fa8a030cf9d15e057869e74a8c736c80ab
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's unnecessary, and copying QEvents is a bad practice since it's a
polymorphic class.
Change-Id: Ieb6de106084f838c5e6c8a0643c54fd3c7f4a7a8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We want to re-enable Android tests in QTQAINFRA-3867. However,
many tests are failing already preventing that from happening.
QTBUG-87025 is currently keeping track (links) to all of those
failing tests.
The current proposal is to hide those failing tests, and enable
Android test running in COIN for other tests. After, that try
to fix them one by one, and at the same time we can make sure
no more failing tests go unnoticed.
Task-number: QTBUG-87025
Change-Id: Ic1fe9fdd167cbcfd99efce9a09c69c344a36bbe4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This makes it feature comparable with QAction, and makes it possible
to use as a backend for QAction, and fixes a few missing alternative
keybindings in qtwidgets.
Change-Id: Iaefc630b96c4743fc5ef429dc841870ddd99fc64
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
All QFontDatabase APIs are static, use them accordingly.
Task-number: QTBUG-88114
Change-Id: I0e4a7508646037e6e2812611262eed8b6d7ad3de
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
CMake builds are special and need to know the path to the source dir.
This is handled automatically by QTEST_MAIN, but tst_qapplication
doesn't use QTEST_MAIN. Thus we need to call
QTEST_SET_MAIN_SOURCE_PATH manually.
Task-number: QTBUG-87137
Change-Id: Ib2c461f0da0a3d9a2f571f37476b750a606065f7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Testing the mouseMoveCount before XFAIL'ing before then testing the
mouseRelaseCount was anyway wrong.
Change-Id: I666f143ff15088562fc63f833f5785f870de6f26
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It's been obsolete for a long time already. Make sure
the compiler now warns about it and remove all remaining
uses in qtbase.
Change-Id: I0ff80311184dba52d2ba5f4e2fabe0d47fdc59d7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Leave the normalizedPos warnings, there is no equivalent function.
Change-Id: I50c72ab24b4855e36941aafdee30cdb0e94c1684
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Silence the warning, and test event delivery in addition.
Change-Id: I59c49a2ac70ecd32429116b76643700a7ad5ce3e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
tst_QApplication::sendEventsOnProcessEvents() and
tst_QItemDelegate::editorKeyPress()
There is some issue with the glib event dispatcher.
Task-number: QTBUG-87137
Pick-to: 5.15
Change-Id: I79a983192edef3c3560a4296cc9dea2dfc2ee1b0
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Use QScreen APIs instead.
Change-Id: Ie99af94fe4292223dbb165b3f5c1b74e8fe0498b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Change lots of code to avoid the deprecated operator+() or implicit
casts to int.
Change-Id: I0c343cd5b28603afdf1214eefb85e928313345e2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Changes the definition of invalid QRects to be more consistent.
This simplifies the logic, and makes it possible for us to fix
normalized() so dimensions don't change.
The actual API is not changed except for inverted rects.
Only one use-case for the old normalized() function existed,
and has been reimplemented as QRect::span().
Fixes: QTBUG-22934
Change-Id: I29dad2952dc6c8e84a6d931898dc7e43d66780f3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
As per ### Qt6 comment. Also rename the LibraryLocation enum
to LibraryPath.
Change-Id: I556025a19c5bcdf2ff52598eaba32269522d4128
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove around 1000 compiler warnings about missing overrides
in our auto tests.
This significantly reduce the compiler warning noise in our auto
tests, so that one can actually better see the real problems
inbetween.
Change-Id: Id0c04dba43fcaf55d8cd2b5c6697358857c31bf9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Because we removed public setters from QTouchEvent and QEventPoint in
4e400369c0 and now it's proposed to give
QEventPoint a d-pointer again, the implementation of QTouchEventSequence
needs to start using QMutableEventPoint: being a friend will no longer
be enough, because the member variables won't be accessible in the future.
But because we have separate test libs for Gui and Widgets, it needs to
be further refactored into two classes.
Change-Id: I0bfc0978fc4187348ac872e1330d95259d557b69
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Following the introduction of QKeyCombination, reduce the number
of warnings raised by the test. Drive-by, remove some pointless
math like Qt::SHIFT+0, which does not make any sense and would
actually fail to compile (shortly).
Refactoring the test to fully use QKeyCombination (instead of
ints) is left as a future exercise; some QKeyCombination->int
warnings are still around.
Change-Id: If825bc4c369986623447927bb11493c4f58b544f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
