Fails on previous 42.3 and also 15.0. Just covering "opensuse" saves
us from new commits every time we upgrade our openSUSE. We have a bug
open of it after all.
Task-number: QTBUG-51399
Change-Id: I5c0869daea41b1886faba3d0caaa0804a3705d54
Reviewed-by: Liang Qi <liang.qi@qt.io>
This test was un-blacklisted in 4050ee6ac7
but apparently it is still not stable.
Task-number: QTBUG-69666
Change-Id: Iaf933ee27d54ebbfa52d0a8d7b1def0ca91808e7
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
Additionally to setting the cursor position we have to make sure that
enter and leave events are triggered. As WinRT at the moment only supports
maximized/fullscreen native top level widgets, an enter or leave event has
to be triggered, every time the cursor enters or leaves the core window.
Same as is done on Windows desktop an enter event is immediately followed
by a move event even for emulated mouse events.
Change-Id: I4b9a7b07f8e24b7887619f96979a064d933788aa
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
The original code was added by b316c3ac5e
(in 2012). This patch changes two things:
1) We now rely on WM to position a window based on the set gravity. It
should not be necessary to calculate coordinates manually as was done
in windowToWmGeometry(). We don't even know the decoration size before
the window is mapped.
2) We now update gravity whenever needed instead of hardcoding based
on what Qt APIs (setGeometry vs setFramePosition) where used to set
the initial window position.
The patch from b316c3a says:
"Determine gravity from initial position. Do not change later as
it will cause the window to move uncontrollably"
Since it did not elaborate on the situation, we can only assume
that it was caused by another bug in Qt at the time or perhaps
a broken WM. From [1]:
"Applications are free to change their win_gravity setting at any
time. If an Application changes its win_gravity then the Window Manager
should adjust the reference point, so that the client window will
not move as the result."
Tested on Ubuntu/Unity, KDE/KWin, Gnome-shell/Mutter, Lubuntu/OpenBox.
Works as expected everywhere expect Unity. Unity seems to ignore
XCB_GRAVITY_STATIC and treats it as XCB_GRAVITY_NORTH_WEST, which means
that setGeometry/setFramePosition produce the same placement on this WM
(the behavior was the same also before this patch).
P.S. Also renamed xRect -> rect, which was a leftover from
ae5f2a6672
With this change we can un-blacklist QWidget save/restore geometry
auto tests.
[1] https://specifications.freedesktop.org/wm-spec/latest/ar01s09.html
Task-number: QTBUG-66708
Change-Id: I381eef5d34dddb04de16a897ce5540b9c430b216
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
QWidget::restoreGeometry() is calling QWidget::move() with restoredFrameGeometry,
which internally calls setGeometry() and sets positionPolicy = QWindowPrivate::WindowFrameExclusive,
which is invalid: restoredFrameGeometry is WindowFrameInclusive geometry.
QPA plugins rely on correctly set policies when interpreting x,y. QWidget::move()
was not designed for this AFAICT, so making it to accept frame geometry is
no-op. It is widely used legacy code, changing it could cause regressions.
Save/restore API was introduced in Qt 4.2, at that time we did not have APIs
like QWindow::setFramePosition(), so its unclear why geometry() was not stored
instead. The documentation also is somewhat unclear:
"[..] save the geometry when the window closes [..]"
Frame or client geometry? It does not specify. And from the code we see
that frame geometry was passed as client geometry, not making the original
intention clearer. Besides that, restoreGeometry() is full of other undocumented
assumptions where to place windows and when to fail (fortunately its easy
to write your own save/restore logic). Added a Qt 6 note in the source code.
What this patch changes:
Now we store geometry() in saveGeometry() and use that value in restoreGeometry()
by setGeometry(). This does not cause any behavior difference in window
positioning (tst_QWidget::saveRestoreGeometry still works). Geometry restored
from data saved with earlier versions of saveGeometry() might be positioned at:
x + leftMargin, y + topMargin.
This patch makes tst_QWidget::saveRestoreGeometry to always fail instead
of being flaky. Blacklisting for XCB instead of selected distros.
Also enabled excluded code paths for XCB on tst_QDockWidget::restoreDockWidget().
It does not seem to be flaky, maybe it was in 2015, but lot of things have changed
since then.
Task-number: QTBUG-66708
Change-Id: Ic86a6fd091e2c71b7550b2f476386da704253cd4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This autotest fails on Ubuntu 18.04 builds.
Task-number: QTBUG-68862
Change-Id: Ib02c28ede135c9ba4303dbf0224b32b080762a31
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
It's not possible to ask for window activation on Wayland, and some Wayland
compositors—such as Weston—don't give window focus to newly created window
either.
Task-number: QTBUG-62188
Change-Id: Ibebb2a14e03127fec703d79498627fccf65b2f88
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We move QInternalMimeData to a separate file, because this class is
used, even if draganddrop is disabled. From now on, include
qinternalmimedata_p.h instead of qdnd_p.h for QInternalMimeData.
Change-Id: I594e08e2e90d574dc445119091686b4b69e4731b
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
QDesktopWidget::screenGeometry() and similar was deprecated in 5.11
and replaced by QScreen::geometry()
Change-Id: Ic630d022bc6461af78f49684c8ac9d1836d738bc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Windows 10 windows contain an invisible area within the NC window frame
on which the mouse cursor is enabled to perform resizing. This change
captures the geometry of the invisible margins and considers it when
moving a window, so that, for instance, a move(0,0) does not generate
gap between the window and the beginning of screen.
[ChangeLog][Windows] The dimensions of invisible margins inside the
frames of Windows 10 windows will now be disregarded in the positioning
of Qt windows to avoid a misplaced look (offset by a few pixels from
the expected position).
Task-number: QTBUG-55762
Change-Id: I1f537756eb1a093f78b919de9d44992528199700
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This way the platform window is destroyed in a timely manner, preventing
redundant close events from the window system.
Task-number: QTBUG-43344
Change-Id: Ifdfca59ceacef54405f1c227c493dc514a1b27ea
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
[ChangeLog][QtWidgets] QApplication no longer sends a mouse move event
to the entered widget if it sends synthetic enter and leave events.
Task-number: QTBUG-67736
Change-Id: I75daaffd53f1ddc2bc4d7df67382cbc22d3eb6fc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This test function was removed from the blacklist as
a part of the cleanup in 2056bc6b, but is still flaky
on CI.
Change-Id: I348ed167dff6fd618ede28456ada6da86ee341cd
Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io>
Whitelist tests that pass locally and that have been
blacklisted since the BLACKLIST was introduced in
2015 (in commit a8dda3b8).
Change-Id: I777b490313ebaa6c8c8daee168487d350179a5e6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Has been flaky in CI.
Task-number: QTBUG-66708
Task-number: QTBUG-66216
Change-Id: I69878574a98139681100c1424d5bbf46cc4a87b8
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Previous version of Ubuntu used to be blacklisted and the test is still flaky on
Ubuntu 16.04.
Task-number: QTBUG-66390
Task-number: QTBUG-66216
Change-Id: Iec404879f61164b995f0df7348f4f4baf608ca90
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Drop the useless copy 'r' of 'region', reuse 'r' for the rects in 'region',
to clean up the region handling in verifyColor().
Change-Id: I8e159976b4b0152823be864488d2ef25d7cb0078
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
on Ubuntu_16_04 and openSUSE_42_3.
Task-number: QTBUG-64446
Change-Id: If8fff2823f041428852822470a2f00157795558b
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
The vast majority is actually switched to QRandomGenerator::bounded(),
which gives a mostly uniform distribution over the [0, bound)
range. There are very few floating point cases left, as many of those
that did use floating point did not need to, after all. (I did leave
some that were too ugly for me to understand)
This commit also found a couple of calls to rand() instead of qrand().
This commit does not include changes to SSL code that continues to use
qrand() (job for someone else):
src/network/ssl/qsslkey_qt.cpp
src/network/ssl/qsslsocket_mac.cpp
tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b5285d43f4afbf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The test showed flakyness on Linux. It has been observed that its
windows overlap. Position the windows beside each other.
Change-Id: I4ff1b9cafaf753a6844b3dfabb576a07f74b396a
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
... by moving them in QTestPrivate namespace (qtesthelpers_p.h). This
header file is a convenient staging area for helper APIs, eventually
some could be moved to public QTest API.
This header file utilizes the same pattern as other qtestlib header
files - wrapping functions with QT_${LIBNAME}_LIB to automatically
enable certain APIs based on what is in the projects dependencies,
e.g. QT += widgets.
Change-Id: Ic0266429939c1f3788912ad8b84fc6e0d5edd68b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The autotest has been blacklisted for RHEL 7.1 and RHEL 7.2 earlier already
and it is still failing in 7.4.
Task-number: QTBUG-46116
Change-Id: I0f33be849513a2debaf8c093dcd413fa09b5c681
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
The qWaitFor functions themselves can not trigger a test failure, as that
will not result in the test function exiting early, so every single call
to qWaitFor needs to be wrapped in a QVERIFY.
Change-Id: Id15a1549f31d06cdbf788e1d84ea431c28636ec8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A "compound widget" is a widget that has a focus proxy set to an inner
child. This is normal for complex black-box components where focus handling
is delegated to the children. Since the compound can have several
children, a local tab order might exist between them.
The current implementation of setTabOrder had no idea about
compound widgets. As such, when connecting two compounds in the
tab chain, it would just break up their inner tab order and
cause tabbing to ignore children other than the proxy.
The new implementation recognizes compound widgets, and add some
extra code to figure out the correct tab targets. This way, the
local tab order between the children will be preserved.
This implementation was inspired by the patches of Marek Wieckowski posted
in the linked bug report, and later modified by Nikita Krupenko.
[ChangeLog][Widgets] QWidget::setTabOrder() will now preserve the local
tab order inside a widget if it has a focus proxy set to an inner child.
Task-number: QTBUG-10907
Change-Id: I0673d39d70ec8c6bf64af30bf978d67c651b2f3c
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
When tabbing/searching for the next focus widget, the current
code would check if the next widget in the focus chain
had a focus proxy, and if so, ignore it. The exact reason
for this behavior is not clearly understood, but some widgets
(e.g QSpinBox) has children (a QLineEdit) that sets the parent
as focus proxy. If we didn't ignore children with focus proxy, tabbing
from a QSpinBox would lead us to find the inner QLineEdit, which
(because of its proxy), would lead us back to the QSpinBox. And
therefore not be able to tab out.
But ignoring the focus proxy has other problems. Normally a focus
proxy is the next sibling to the widget it acts as a proxy for, and
tabbing to the widget will therefore appear correct. But if the
focus proxy is not the next sibling, the logic will fail, since
the tab would anyway give focus to the next sibling. This becomes very
apparent if the focus proxy is a child of the widget, since then
its likely that the focus proxy is not the _first_ child among all
the children. So tabbing to the parent would not give focus to
the proxy.
This patch will change this logic so that you are allowed to tab to a
widget with a focus proxy. But we check that if you do so, you actually
end up moving focus in the right direction. If not, we ignore it like
before. This will ensure that we tab correctly when dealing with focus
proxies, and especially when focus proxies are used to construct
compound widgets.
[ChangeLog][Widgets] When tabbing to a widget with focus proxy, focus
will now be given to the proxy rather than just being ignored.
Task-number: QTBUG-10907
Change-Id: I66d1da5c941fdd984bb2783cc355ca65b553b5dd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Remaining uses of Q_DECL_OVERRIDE are in:
src/corelib/global/qcompilerdetection.h
src/corelib/global/qglobal.cpp
doc/global/qt-cpp-defines.qdocconf
(definition and documentation of Q_DECL_OVERRIDE)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: Ib9b05d829add69e98a86238274b6a1fcb19b49ba
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
