Upon programmatic window state changes, windowStateChange was fired
once in QWindow::setWindowStates and once when the visual state had
been changed by the window interface.
This patch adds if guards to ensure that the singal is fired only once.
It adds a corresponding autotest to tst_QWindow.
tst_QWidget::resizePropagation() is adapted to no longer expect double
signal emission.
Fixes: QTBUG-102478
Pick-to: 6.4 6.2
Change-Id: If093c0a883d76d8a676e4fab90db6b0676452267
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to
handle typedefs and accesses through pointers, too:
const std::string o = "object";
auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); };
auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) {
auto exprOfDeclaredType = [&](auto decl) {
return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o);
};
return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))));
};
auto renameMethod = [&] (ArrayRef<StringRef> classes,
StringRef from, StringRef to) {
return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)),
callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))),
changeTo(cat(access(o, cat(to)), "()")),
cat("use '", to, "' instead of '", from, "'"));
};
renameMethod(<classes>, "count", "size");
renameMethod(<classes>, "length", "size");
except that the on() matcher has been replaced by one that doesn't
ignoreParens().
a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'.
Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache,
to avoid porting calls that explicitly test count().
Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In Qt 6, after changes such as 121fddcf5a,
we go through the QPA layer to close widget windows properly. Closing
and hiding of windows is now done in when we receive and handle the
window system's CloseEvent.
Such an event to a modally blocked window should be blocked, so that
users can't close a modally blocked window. However, if the event is the
result of a call to QWindow::close, then it should not be blocked.
Luckily, we know that the event is the result of such a call, so let
such events through. This restores compatibility with Qt 5, where it was
possible to first open a new dialog, and then close the previous dialog.
Add a test case.
Fixes: QTBUG-107188
Pick-to: 6.4 6.2
Change-Id: Id812c1fc36aa0e1a10dfb8d3a16a11d387289b05
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace, with manual
unstaging of the actual definition and documentation in dist/,
src/corelib/doc/ and src/corelib/global/.
Task-number: QTBUG-99313
Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
On Wayland there is a special case when decorations are enabled,
where we post an initial update request to ensure widgets are
redrawn after the buffer is recreated (see
af7b60ade5c4be81cbc58eb18307c017d5594071 in qtwayland). To
make sure the test behaves the same on Wayland as on other
platforms, we disable client-side decorations when running
these tests.
The flag is primarily required for the requestUpdate() test
at the moment, but it is only queried once per application
run, so it has to be set before any tests are run.
Pick-to: 6.4
Fixes: QTBUG-100889
Change-Id: Ica6d744083ecae4a3722b6d04b956e7615f0dfe5
Reviewed-by: Inho Lee <inho.lee@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The client does not know its global window position on Wayland,
so testing for this will not work.
Pick-to: 6.4
Fixes: QTBUG-100888
Change-Id: Ibdfc84f1b33d25223dbd740603ce4783c21afc70
Reviewed-by: Inho Lee <inho.lee@qt.io>
The intialSize bug has been fixed in Qt Wayland Client, and thus
this test will now start XPASSing.
Pick-to: 6.4
Task-number: QTBUG-66818
Change-Id: I4b9cb8bd9306a67f04295eb23f09574dad0e97f7
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The cause is that the first EXPOSE event comes with the window not
having focus yet. See QTBUG-105177.
Also remove processEvents() as events are always processed when doing
qWaitFor...().
Task-number: QTBUG-105177
Change-Id: I2260d1885388bbf7091c423bc9b4c16e2ed0090f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Previously the failure was been ignored because of the very generic
"linux" entry in the BLACKLIST file
Task-number: QTBUG-105201
Change-Id: I6914fe350f78266fc18541eb8fcd881f5a4ac511
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Under normal circumstances, when the second point is touched, the
first point has not been released, and the message at this time
should contain two touch points. We are simulating the case where
the message is lost when the popup is closed by touch. Amends
efc02f9cc3
Pick-to: 6.4 6.3 6.2
Change-Id: Ic722e3dbd615c46076ede26611d0107501c5e274
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
More specifically, if either minimum or maximum size are updated, make
sure that the current window geometry is updated so that it is within
the minimum and maximum sizes.
Previously, these constraints was only respected by the window manager
when the user resized the window.
For widgets this already worked, because a top-level widget will take
care of respecting these constraints if they are changed.
Since QWindow::setMinimumSize and QWindow::setMaximumSize started to
share so many common things, a new function (setMinOrMaxSize_helper())
is added.
Task-number: QTBUG-102771
Change-Id: Ia4b2680dcf865f84a3cf6424187f9a6036b76386
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When XCB_INPUT_TOUCH_BEGIN closes a popup, we then receive
XCB_INPUT_TOUCH_END, and cannot find a target window (because it's
destroyed). If we don't deliver it, we need to at least clear the
stored point from QPointingDevicePrivate::activePoints. Then when
we deliver the next touch press, m_fakeMouseSourcePointId also
needs to be reset.
It's now even more paramount that autotests (and real-world
touchscreens) must never omit any active touchpoint from a touch event.
If a point doesn't move, it must be included in the QTouchEvent, with
Stationary state. If not, QGuiApp::processTouchEvent() could generate
multiple TouchBegin events in a row, which gets other bits of logic
confused, here and there.
Fixes: QTBUG-94557
Fixes: QTBUG-98519
Fixes: QTBUG-102751
Fixes: QTBUG-103706
Pick-to: 6.2 6.3 5.15
Change-Id: Ia95e410a2bb8bc7784aa5d296fac2b89e53a9f55
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
QWidget and QWindow use bits in QObjectPrivate to provide for a couple
of shortcuts -- one in qobject_cast, and another in the isWidgetType() /
isWindowType() functions in QObject. These can be optimized by simply
looking at the bits, without actually doing more expensive runtime
casts.
These bits were set on construction, but not unset on destruction. The
result was for instance that destroying a QWidget would report that the
object was still a QWidget when ~QObject was reached.
Fix this
1) by setting the bits only when QWidget / QWindow constructors start;
2) by resetting the bits once ~QWidget / ~QWindow are completed.
Technically speaking this is not 100% correct in the presence of data
members, but luckily those classes don't have any.
Amend an existing test for QWidget (whose comment said exactly the
opposite of what the test actually did) and add a test for QWindow.
Some other code was wrongly relying on isWidgetType() returning true
for destroyed QWidgets; amend it as needed.
[ChangeLog][QtCore][QObject] Using qobject_cast on partially constructed
or destroyed QWidget/QWindow instances now yields correct results.
Similarly, using the convenience isWidgetType() / isWindowType()
functions now correctly return false on such instances. Before,
qobject_cast (and the convenience functions) would erroneously report
that a given object was a QWidget (resp. QWindow) even during that
object's construction (before QObject's constructor had completed) or
destruction (after QWidget's (resp. QWindow's) destructors had been
completed). This was semantically wrong and inconsistent with other ways
of gathering runtime type information regarding such an object (e.g.
dynamic_cast, obj->metaObject()->className() and so on).
Pick-to: 6.3
Change-Id: Ic45a887951755a9d1a3b838590f1e9f2c4ae6e92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QWidget will call close() in its destructor, which we might end up
in if a user deletes the widget in the closeEvent.
Pick-to: 6.2
Change-Id: I39684aec0ca130033dad60f2bbf823364a5edcec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Verify that closing a QWindow using either the close()
API or a close event works as expected, and that the window
can be re-created. Also test QWindows with child windows.
Task-number: QTBUG-46701
Change-Id: I4c12452ff58e1233536c2d6932e72cf924d8ed74
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
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>
Fixes compiler warnings:
warning: implicit capture of ‘this’ via ‘[=]’ is deprecated in C++20 [-Wdeprecated]
Change-Id: Ia7cf50f491e92f39162c69afb2a8320afedba056
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
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>
The tst_qwindow test failed with a warning that programmatically
moving the mouse cursor is not possible with Wayland.
Task-number: QTBUG-91418
Change-Id: I02ceb2af43fbc83a4e6ae09718315f5f79ff8285
Reviewed-by: Liang Qi <liang.qi@qt.io>
QGuiApplicationPrivate::processMouseEvent() sends a
QWindowSystemInterfacePrivate::TouchEvent if the mouse event is not
accepted and AA_SynthesizeTouchForUnhandledMouseEvents is enabled.
A QPA TouchEvent always contains native touch points, which is why
it calls QWindowSystemInterfacePrivate::fromNativeTouchPoints to
translate the QMouseEvent's device-independent position back to the
raw position that it would have had if it came from a real touchscreen.
Therefore we must give that function touchpoints that are actually in
native coordinates.
It may be that some of this transformation could be avoided entirely,
but here we prove that the existing way works correctly, by adding
coordinate checking to the tst_QWindow::mouseToTouchTranslation() test.
Pick-to: 6.0
Task-number: QTBUG-86165
Change-Id: I4c9ca2b11e9eb76d79712c187db3eb9865da581a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
During delivery of a TouchBegin event, if no widget accepts it,
we begin treating the first touchpoint as a synth-mouse, as before.
If a second touchpoint is pressed or released in any order, it's
irrelevant: the fake mouse button is released as soon as the first
touchpoint is released. This fixes the bug that such a scenario
caused the mouse release not to be sent, so that a widget could get
"stuck" in pressed state.
Done-with: Tang Haixiang <tanghaixiang@uniontech.com>
Fixes: QTBUG-86253
Pick-to: 5.15
Change-Id: I7fbbe120539d8ded8ef5e7cf712a27bd69391e02
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It also demonstrated that the tests were out of sync with reality:
since a97759a336c597327cb82eebc9f45c793aec32c9 QMouseEvent::button()
and QWindowSystemInterfacePrivate::MouseEvent::button should be the
button that changes state of course; but when a button is pressed,
we are reacting to it after the fact, so QMouseEvent::buttons() and
QWindowSystemInterfacePrivate::MouseEvent::buttons should include the
new button that was just pressed. Likewise when a button was released,
we send the event with buttons _omitting_ the button that was just
released.
Amends 147a8bc4c8 and
6d6ed64d6c
Change-Id: I670289019fcfa7de685ca38799804772dc0f1c8f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In 4e400369c0 we began to send synth-mouse
events from the touch device, but in the opposite direction it was not
consistent.
Add autotests to prove that it's consistent both ways now.
Change-Id: I7df2328fef224dc1529ca5d27411cd8a5a9c8df9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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>
The explicit paint event on QtGui and QPA level allows us to untangle
the expose event, which today has at least 3 different meanings.
It also allows us to follow the platform more closely in its semantics
of when painting can happen. On some platforms a paint can come in
before a window is exposed, e.g. to prepare the first frame. On others
a paint can come in after a window has been de-exposed, to save a
snapshot of the window for use in an application switcher or similar.
The expose keeps its semantics of being a barrier signaling that the
application can now render at will, for example in a threaded render
loop.
There are two compatibility code paths in this patch:
1. For platform plugins that do not yet report the PaintEvents
capability, QtGui will synthesize paint events on the platform's
behalf, based on the existing expose events coming from the platform.
2. For applications that do not yet implement paintEvent, QtGui will
send expose events instead, ensuring the same behavior as before.
For now none of the platform plugins deliver paint events natively,
so the first compatibility code path is always active.
Task-numnber: QTBUG-82676
Change-Id: I0fbe0d4cf451d6a1f07f5eab8d376a6c8a53ce8c
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Change the functions to operate in float and add the
QPoint versions as overload calling them. This is
more in-line with the event accessors using float
and allows for removing some workarounds using a delta when
converting touch points.
Leave QPlatformWindow::map(To/From)Global() as is
for now and add helpers for float.
Change-Id: I2d46b8dbda8adff26539e358074b55073dc80b6f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Some goals that have hopefully been achieved are:
- make QPointerEvent and QEventPoint resemble their Qt Quick
counterparts to such an extent that we can remove those wrappers
and go back to delivering the original events in Qt Quick
- make QEventPoint much smaller than QTouchEvent::TouchPoint, with no pimpl
- remove most public setters
- reduce the usage of complex constructors that take many arguments
- don't repeat ourselves: move accessors and storage upwards
rather than having redundant ones in subclasses
- standardize the set of accessors in QPointerEvent
- maintain source compatibility as much as possible: do not require
modifying event-handling code in any QWidget subclass
To avoid public setters we now introduce a few QMutable* subclasses.
This is a bit like the Builder pattern except that it doesn't involve
constructing a separate disposable object: the main event type can be
cast to the mutable type at any time to enable modifications, iff the
code is linked with gui-private. Therefore event classes can have
less-"complete" constructors, because internal Qt code can use setters
the same way it could use the ones in QTouchEvent before; and the event
classes don't need many friends. Even some read-accessors can be kept
private unless we are sure we want to expose them.
Task-number: QTBUG-46266
Fixes: QTBUG-72173
Change-Id: I740e4e40165b7bc41223d38b200bbc2b403e07b6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We want every QInputEvent to carry a valid device pointer. It may be
some time until all QPA plugins are sending it, but it's necessary to
provide the functions for them to start doing that.
We now try to maintain the same order of arguments to all the functions.
handleTouchEvent(window, timestamp, device, the rest) was already there
(except "device" has changed type now), and is used in a lot of platform
plugins; so it seems easiest to let that set the precedent, and modify
the rest to match. We do that by adding new functions; we can deprecate
the older functions after it becomes clear that the new ones work well.
However the handleGestureEvent functions have only ever been used in
the cocoa plugin, so it's easy to change their argument order right now.
Modify tst_qwindow::tabletEvents() to test new tablet event API.
Task-number: QTBUG-46412
Change-Id: I1828b61183cf51f3a08774936156c6a91cfc9a12
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We have seen during the Qt 5 series that QMouseEvent::source() does
not provide enough information: if it is synthesized, it could have
come from any device for which mouse events are synthesized, not only
from a touchscreen. By providing in every QInputEvent as complete
information about the actual source device as possible, we will enable
very fine-tuned behavior in the object that handles each event.
Further, we would like to support multiple keyboards, pointing devices,
and named groups of devices that are known as "seats" in Wayland.
In Qt 5, QPA plugins registered each touchscreen as it was discovered.
Now we extend this pattern to all input devices. This new requirement
can be implemented gradually; for now, if a QTWSI input event is
received wtihout a device pointer, a default "core" device will be
created on-the-fly, and a warning emitted.
In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when
multiple devices were in use simultaneously. Now that each event
identifies the device it came from, this hack is no longer needed.
A stub of the new QPointerEvent is added; it will be developed further
in subsequent patches.
[ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer
to an instance of QInputDevice, or the subclass QPointingDevice in case
of mouse, touch and tablet events. Each platform plugin is expected to
create the device instances, register them, and provide valid pointers
with all input events. If this is not done, warnings are emitted and
default devices are created as necessary. When the device has accurate
information, it provides the opportunity to fine-tune behavior depending
on device type and capabilities: for example if a QMouseEvent is
synthesized from a touchscreen, the recipient can see which touchscreen
it came from. Each device also has a seatName to distinguish users on
multi-user windowing systems. Touchpoint IDs are no longer unique on
their own, but the combination of ID and device is.
Fixes: QTBUG-46412
Fixes: QTBUG-72167
Task-number: QTBUG-69433
Task-number: QTBUG-52430
Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Many of these were generated by clazy using the new qevent-accessors check.
Change-Id: Ie17af17f50fdc9f47d7859d267c14568cc350fd0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Macros and the await helper function from qfunctions_winrt(_p).h are
needed in other Qt modules which use UWP APIs on desktop windows.
Task-number: QTBUG-84434
Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Takes care of the first round of todos and deprecations for Qt6 in
qevent.
Not touching anything that might interfere with changing the class
hierarchy as the file also suggest.
Change-Id: If72d63d8932f1af588785bf77b34532358639a63
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
It is conceivable that during the try-compare loop of processing
windowing system events we loose and regain the focus. That would
explain the occasional test failure where instead of the expected 3
focus in events, we have received four.
Task-number: QTBUG-77769
Change-Id: I2221440d09a74d4d18a72f7786232b4491cf45a8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use the standard testlib helpers for generating clicks and port the
remaining occurrences to the new versions of
QWindowSystemInterface::handleMouseEvent(). Similarly, fix
QWindowSystemInterface::handleTabletEvent().
Task-number: QTBUG-76491
Change-Id: I6a30957164891b56a018696606956c3cab56047f
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
- Use nullptr
- Fix C-style casts
- Remove unnecessary casts to int from registered enums
- Fix most signedness-related warnings
- Use range-based for
- Use correct static invocation
- Set a title on shown windows to make it possible to identify
slow tests
- Fix the class declarations, use override, member initializations
- Streamline code in some cases
Change-Id: I4c9b99126cff02136def0e03accdf1129fe6d72b
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Before commit 4d15f393a7 update requests
were handled by a timer on QWindow. Therefore they survived the closing
and re-opening of platform windows. Now, as the timer was moved to
QPlatformWindow, it gets reset when you close the QWindow, and any
pending update requests are lost. However, we do set the
updateRequestPending variable on QWindow when requesting an update.
Therefore, we can also restore the update timer on the platform window
when creating it.
Change-Id: I23b00f24a46706beac7d1455edd8a5623db46b22
Fixes: QTBUG-70957
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@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 test doesn't make much sense on platforms that don't support window
activation.
Task-number: QTBUG-66849
Change-Id: I875314d026d666173ec345d0864ad41d66179783
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The test is actually passing, so just enable it.
Task-number: QTBUG-66849
Change-Id: Ie1566b9e5e19f5ab6d919624aa14662a1d4483ec
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Link to a bug report so we can track the failures and figure out how to fix
it in Qt Wayland or if we should skip the tests in a proper way. I.e. with
platform capabilities or similar.
Task-number: QTBUG-66849
Change-Id: I7a16333c7d2284eb9da6efd4515891438e9976b3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Axel Spoerl
Marc Mutz
Volker Hilsheimer
Eskil Abrahamsen Blomfeldt
Dimitrios Apostolou
Ivan Solovev
Tang Haixiang
Jan Arve Sæther
Lucie Gérard
Liang Qi
Giuseppe D'Angelo
Tor Arne Vestbø
Morten Johan Sørvig
Marc Mutz
Shawn Rutledge
David Skoland
Lars Knoll
Friedemann Kleint
Jarek Kobus
Oliver Wolff
Allan Sandfeld Jensen
Simon Hausmann
Ulf Hermann
Johan Klokkhammer Helsing