Amends 65093a84c2, which changed how we
destroyed the main thread's QThreadData. This merges the call to
destroy_current_thread_data() for both types of Unix systems: those with
broken thread_local destructors and those with working ones. It turns
out that the function got called too early for us in those working
systems (see updated comment).
The clean up of the QThreadData is split into two different mechanisms:
* for any auxiliary thread, when it exits, PThread will call back to
destroy_current_thread_data()
* for the thread that called ::exit(), PThread won't, but ::exit() will
invoke set_thread_data()::TlsKey's destructor
This is different from the situation that existed prior to commit
65093a84c2b94b1543fd4593bc45d491951d28d4: first, there's no code in
qcoreapplication.cpp for this (all in qthread_unix.cpp). Second one may
call ::exit() from any thread, whether that is the thread that called
main(), the thread Qt thinks is theMainThread, or any other.
This commit moves the tst_QCoreApplication check for no extant objects
to a new test. I've chosen to add a new test instead of running a helper
binary via QProcess because we do have a couple of !QT_CONFIG(process)
platforms in the CI, and this is too important.
Credit to OSS-Fuzz for finding this, though it is not itself a fuzzying
problem (all tests of a given structure were crashing on exit).
Fixes: QTBUG-132381
Task-number: QTBUG-130895
Task-number: QTBUG-129927
Task-number: QTBUG-129846
Task-number: QTBUG-130341
Task-number: QTBUG-117996
Pick-to: 6.9 6.8
Change-Id: Ie294dce7263b4189f89ffffd9155ec71d31b89d9
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
These are set later in openSUSE.
Fixes: QTBUG-131368
Change-Id: Ifd27b0b6f94c7d97cbe13acd9741624431dd9906
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
They are an unnecessary hit on build time.
Rewrite the tests using the standard Qt conventions.
Pick-to: 6.8
Change-Id: Iac47e62c58b1805c3b4a0ac4f4b3db206c66cc65
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When a TabletPress event is not accepted and
AA_SynthesizeMouseForUnhandledTabletEvents is enabled,
QGuiAppicationPrivate::processTabletEvent() follows it up with a QPA
MouseButtonPress event (since f931e5e72d).
Double-clicks could be spuriously detected: two presses arrive with the
same timestamp from the same device; so we no longer send the
MouseButtonDblClick if the timestamps are identical.
Some autotests need to use realistic event sequences now. An actual
MouseDClick event always occurs after the second MousePress.
And to trigger a double-click, events must be clearly sequential
according to their timestamps.
Amends e50416066cf931e5e72d and
4e400369c0
Task-number: QTBUG-111336
Task-number: QTBUG-129998
Change-Id: I5840e20c032cc99101fb5aafa7b6b91933a97eff
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
If a window is positioned with setFramePosition, we reflect that to
the platform window via QPlatformWindow::setGeometry(), but with the
QWindowPrivate::positionPolicy set to WindowFrameInclusive. On the
platform side the position policy is read from QWindowPrivate to
determine how to interpret the incoming geometry.
When the resulting geometry is applied to the native window,
it's reflected through QPlatformWindow::geometry() and reported
back via QWSI::handleGeometryChange() as client geometry, ie.
without the frame margins.
If the platform layer later interprets this geometry in
combination with the window's positionPolicy, it will incorrectly
position the frame top left at the point of the client geometry's
top left.
It would make sense to reset the window's positionPolicy at
the point of QGuiApplicationPrivate::processGeometryChangeEvent,
but doing so might break situations where there's another in
flight geometry request.
What we can do as a first step is reset the positionPolicy when
the platform window is destroyed. This ensures that the next
time the platform window is created it will be placed at the
same position, even if the initial position was requested via
the setFramePosition() API.
Pick-to: 6.8
Change-Id: Ic555f19884ccd68c46421d0fe666717170ba7638
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Instead of build dir, where it can clash when multiple tests runs
are being done from the same build dir in parallel.
Due to the way platform plugin argument parsing works we can't
pass the full file name of the config, as on Windows this would
include C:, which QGuiApplication will split into two, thinking
they are two different platform plugin arguments.
Instead we chdir into the temp dir, and create the file there,
passing the file name as a relative path as before.
Pick-to: 6.8
Change-Id: Ia4ea82280e35f4f52b7de74bbf53b2a48ecbaecd
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
There is a bug in GNOME 46.0 on Ubuntu 24.04 Wayland when showing
a maximized or fullscreen window.
Task-number: QTBUG-127920
Pick-to: 6.8
Change-Id: I49c0f53b16f501072cbbe92ddd79ff21fb9adb27
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The framePositioning test was split out from the positioning test, but
without the existing skips. Turns out we do need the same skips, so
add them.
Pick-to: 6.8
Change-Id: Ib5d1cdf474a3a88a154c7cdc8df346668c8053d6
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
This amends 31ec108dd0 .
framePositioning() was split from positioning(), which was skipped
before.
Pick-to: 6.8 6.7 6.5
Change-Id: I23dcfbe6012bb44c9b7c343b963e7338ddd16f28
Reviewed-by: David Edmundson <davidedmundson@kde.org>
When building qt with QT_NO_DEBUG/WARNING/INFO_OUTPUT set, then the
qDebug/Warning/Info macros expand to `QMessageLogger::noDebug`. That
helper is not defined to take a logging category or category function,
so using `qDebug(lcX, ...)` breaks the build. The correct way to emit
categorized logging is to use the qCDebug/Warning/Info macros.
Task-number: QTBUG-125589
Pick-to: 6.8 6.7 6.5
Change-Id: I968b0e826871a09023c11fec9e51caa5a2c4dc0b
Reviewed-by: Jonas Karlsson <jonas.karlsson@qt.io>
When the QCocoaWindow is created it picks up the QWindow geometry,
and applies that to the NSWindow it creates. But since we haven't
created an NSWindow yet for the first step, our logic to adjust the
window geometry when the positionPolicy is WindowFrameInclusive is
a noop. As a result the NSWindow gets a client geometry corresponding
to what the user requested as the frame geometry.
To fix this we hook into [QNSWindow setContentView:], where we apply
QWindow properties to the NSWindow after creation.
The tst_QWindow::positioning test has been split out into a separate
framePositioning test.
Pick-to: 6.8 6.7 6.5
Change-Id: I85fe6ad10aee8346202de3d55d6b2cd89915c5df
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We no longer support fake fullscreen mode on macOS, and haven't for
a long time.
Pick-to: 6.8 6.7 6.5
Change-Id: Ic2eb6065239c4e5be5ab2011a6da50272c77460a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Dogfooding the new QtTest 6.8 feature.
Pick-to: 6.8
Change-Id: I4ded1fabac25fb283eb26b5eef341892b4459e96
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
We need to be able to have true popup windows in Qt Quick and Controls,
including handling the press-drag-release sequence to select one entry
from a menu or combobox. After the mouse press, a new window is created.
On some platforms (such as xcb), the new window gets window system grabs
of both keyboard and mouse (QApplicationPrivate::openPopup() calls
grabForPopup() and it actually works); while on others, the pre-existing
window continues to get the whole sequence of mouse events until the
release. In the latter case, Qt needs to forward events from the
original window to the popup. Until now, the list of popups was
QApplicationPrivate::popupWidgets.
Now we track the open popups as a list of QWindows rather than QWidgets,
in QGuiApplicationPrivate::popup_list, and add a set of static functions
to manage that list. Functions such as QApplication::activePopupWidget()
QApplicationPrivate::openPopup() and closePopup() are rewritten to make
requests to QGuiApplicationPrivate.
276943c8b7 made
QGuiApplicationPrivate::closeAllPopups() virtual. That is now reverted,
because we're putting QGuiApplication in charge of popup management
and trying to minimize widget-specific behavior. So far,
QApplicationPrivate::closePopup() is still overridden to take care
of focus changes.
So far, QtGui does not take care of closing popups when the user
clicks outside: the active popup window gets those events, and needs
to close itself if the click occurs outside. An attempt to move this
logic raised some issues with legacy widget test cases.
Using a touchscreen to press on QMenuBar and open a QMenu, drag to
a menu item and release, is temporarily broken for now. The plan is
to fix it in a subsequent patch.
Task-number: QTBUG-68080
Task-number: QTBUG-69777
Change-Id: I02b5034987b5ee8909917d305f414c8b0db9c7f5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We rely on setParent for parenting top level windows into our desktop
manager view, so we can't condition the call on having a parent window,
like we do on other platforms.
This was a regression from 988039729f.
Fixes: QTBUG-125142
Pick-to: 6.7
Change-Id: I2884d77db09cba5371ccd77eabda7ce38c0292de
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Now developer build tests compile, but some are not working.
Functional fix will come later via separate tasks.
Task-number: QTBUG-122999
Change-Id: I70487b46c1b32ba4279cb02a4978e4f55ac0d310
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As part of df359bcb70 the semantics and
interaction between QEventLoopLocker and QGuiApplication was changed,
based on the assumption that these two mechanisms were independent
and should not affect each other.
This had a surprising regression where the use of QEventLoopLocker in
combination with the QCoreApplication::isQuitLockEnabled() automatic
quit would end up quitting the app, even if it had open windows, for
example when the last job of some internal job queue finished.
It could be argued that if the app has open windows that should not
be closed, they should ignore the Close event, and that an application
with running QEventLoopLocker jobs should maintain an active window
showing the progress of those jobs, but still, this is regression
that we want to fix.
We now bail out if !lastWindowClosed() in QGuiApplication's
canQuitAutomatically, which is triggered from QEventLoopLocker's
isQuitLockEnabled() behavior. And we do so regardless of whether
quitOnLastWindowClosed is set or not, as the latter property
determines the behavior when closing a window, not the behavior
when a QEventLoopLocker goes out of scope.
Similarly, we now block quitting of the application when triggered
by quitOnLastWindowClosed() if a QEventLoop is active, regardless of
the isQuitLockEnabled(), as the latter property is determining
whether we should trigger a quit, not whether we should block them.
[ChangeLog][Important behavior changes] Fixed a regression where
the last QEventLoopLocker going out of scope would quit the app,
even if there were open windows, if quitOnLastWindowClosed was
false.
[ChangeLog][Important behavior changes] Fixed a regression where
closing the last window would quit the app, even if there were
active QEventLoopLockers, if isQuitLockEnabled was false.
Fixes: QTBUG-124386
Pick-to: 6.7 6.5
Change-Id: I84fd0ddea78a2f417f3a17b326113c880079cf85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We used to set a private _q_foreignWinId property on QWindow when
creating foreign windows, and this was the mechanism which we then
passed the foreign winId to the platform plugin.
With c585802e94 this was removed,
since we now were passing the winId through via explicit QPA
APIs, and since 0c6911e5cd removed
the ability to explicitly destroy() a foreign window.
But when closing a QWindow, we destroy both the window itself,
and all its children, including foreign windows. In this case
we still want to support recreating the foreign window, for
example when the parent window is shown again. To enable this
we restore the _q_foreignWinId private property, but keep
the limitation of not being able to explicitly destroy a
foreign window.
Pick-to: 6.7 6.5
Fixes: QTBUG-124160
Change-Id: Ia885ba9f043e64fb21eedd2b4c344679726f1b5c
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
In some cases calls to QFile::open are made outside of a testfunction
(so we can't use QVERIFY), or even in standalone executables that are
executed by tests. Make them fail "visibly".
Change-Id: Iec4d56f6d874be16aa2e9ad6974eeec2a98caa3f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Wrap the call in QVERIFY.
tst_QTextStream::read0d0d0a was also faulty as it *never* opened
the file because of a broken path. Fix it with QFINDTESTDATA.
Change-Id: I61a8f83beddf098d37fda13cb3bfb4aaa4913fc5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The interval in QTimer is a QProperty of type int, which means it's
limited to the number of milliseconds that would fit in an int (~24
days), this could cause overflow if a user constructs a QTimer with an
interval > INT_MAX milliseconds. And it can't be easily changed to use
qint64/std::chrono::nanoseconds:
- changing the getters to return qint64 means user code would have
narrowing conversions
- the bindable QProperty interval can't be changed to qint64 during
Qt6's lifetime without the risk of breaking user code
- adding a new bindable QProperty that is qint64/nanoseconds is an
option, but it has the complication of what to do with the int
interval; set it when setInterval(milliseconds) is used by using
saturation arithmetic? and what about notifying observers of the
changed interval?
Thus the idea of creating a new stop-gap class, QChronoTimer, as a
cleaner solution. Both classes use QTimerPrivate.
During the lifetime of Qt6, QTimer's interval range is about 24 days,
whereas QChronoTimer's interval range is about 292 years
(duration_cast<years>nanoseconds::max()).
Currently the plan is to fold QChronotTimer back into QTimer in Qt7.
Mark all QPropertyS in the new class as FINAL since they aren't
intended to be overridden; this offers a performance boost for QML[1].
[1] https://lists.qt-project.org/pipermail/development/2024-February/044977.html
[ChangeLog][QtCore] Added QChronoTimer, which uses a
std::chrono::nanoseconds intervals, as a replacement for QTimer.
Fixes: QTBUG-113544
Change-Id: I71697f4a8b35452c6b5604b1322ee7f0b4453f04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Ultimately this is the best way to keep the log history of the code.
Change-Id: I3413deffdb093a3239d65b6ca939e744224e722a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We already had the machinery to copy one buffer to another, so this
machinery has been generalized a bit, so we can use it to preserve
the static content during buffer resize.
As explained in the comments, we need to do the buffer copies during
buffer creation, instead of relying on our back buffer finalization,
as we are not guaranteed that we can always copy the static content
from the front buffer.
Pick-to: 6.7
Change-Id: Ia9b3ac6ec982949990d172b0b14f35b13bbae92a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This was a feature in Qt 4, but the only platform that carried it over
to Qt 5 was Windows, in ab76593f18, and
that's still the situation.
As a first step in possibly implementing this on more platforms, lets
replace the hard-coded check in QWidgetRepaintManager::hasStaticContents
with a proper QPlatformIntegration capability check in the only call site.
Pick-to: 6.7
Change-Id: I2067109f45116cd8c62facf7224cd748f19e845b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The plumbing from QBackingStore::resize to the platform backing store
was missing a high-DPI conversion for the backing store's static
contents, which is also expressed in the QtGui coordinate system.
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: Ifaac916cbf184b9386aa5feca1577a53bf2906ed
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
All we need are the APIENTRY and WINGDIAPI macros, as those are used
in the gl.h header. Define those locally for the time we need them.
Use a QT_APIENTRY macro instead of hijacking APIENTRY for when we
declare OpenGL functions with the stdcall calling convention.
A few build fixes needed in tests that used Windows types without
explicitly including windows.h first, or that (incorrectly) included
one of the sub-headers of windows.h (like winuser.h).
[ChangeLog][Potentially Source-Incompatible Changes][OpenGL]
On Windows, the public qopengl.h header no longer includes windows.h.
Pick-to: 6.7
Fixes: QTBUG-120687
Change-Id: I3770ac8eaeee5bcf4e7234e5a2539935a8aa5a7d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Remove the following CIs from BLACKLIST files as they are no longer
used:
- msvc-2015
- msvc-2017
- windows-7sp1
- opensuse-42.3
- ubuntu 16.04/18.04/20.04
- rhel 6.6/7.4/7.6
- redhatenterpriselinuxworkstation-6.6
Change-Id: Ief9550e3455a1ed211d978933262c8d5557b0fec
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This change is required when running in real hw with eglfs backend. It passed on CI because CI used "offscreen" backend and eglfs is not tested on CI at the moment.
Task-number: QTBUG-115777
Change-Id: I4bbfbedcbe21c5c2041be9bdb8ae370156bb6200
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
It's flakey, so let's unbreak the build while we investigate further.
Pick-to: 6.6
Change-Id: I9f7559803dd3ebc80946e5e5c5d31292101cd36f
Reviewed-by: Liang Qi <liang.qi@qt.io>
It's used to build different variations of the unittest,
linking against QtCore-only/QtGui, with/without GLib, that's four
individual tests.
Change-Id: Iaf0f37041dbb148134631f86be99feaa881a8ce8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We only care about no longer being a child of the old parent window,
not what the system does when we reparent to nullptr.
Pick-to: 6.6
Change-Id: Ibd670432f0fd2595195d3951014a570dfdb7a998
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
When a QWindow is parented into another window, either via its constructor,
or via setParent(), we also update the QObject parent of the window. This
in turn sends ChildAdded and ChildRemoved events to the new and old parent
of the window, as well as ParentAboutToChange and ParentChange to the window
itself.
But at the point when these events are sent, the QWindow parent relationship
has not been fully established. We have not updated d->parentWindow, nor
have we propagated the parent relationship to the platform window.
This is problematic because clients can not use these events to react to
window parent changes synchronously. For example. trying to raise a child
window when added to a parent is not going to work, because at that point
the child window isn't a native child of the parent.
Instead of re-using the QObject events for QWindow, like QWidget does,
by delaying the events or sending them manually at a point when the
window parent relationship has been fully formed, we opt to add new
dedicated events.
Change-Id: I019c14eba444861f537e4f68ab3a82297f843cf7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
A foreign window used to embed a Qt window into it should not end up
with changes to its own parent, as its only job is to give the embedded
Qt window a parent handle.
Pick-to: 6.6
Change-Id: If1bc89658fedf449d266bc0cc750c90b6a841a68
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Although not explicitly documented, this is the behavior in practice
on XCB and Windows, and we rely on this behavior in our implementation
of QApplication::widgetAt(), where we punch a temporary hole in the
widget using a mask if it has Qt::WA_TransparentForMouseEvents set.
Pick-to: 6.5 6.6
Fixes: QTBUG-41696
Task-number: QTBUG-119092
Change-Id: Ie7abc31b6930ee6b56fcdf391befc625c1ddf502
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Under some circumstances (e.g. setDesktopSettingsAware(false) on
windows) it may happen that the call to platformTheme::palette() returns
a nullptr which is not checked before dereferencing the pointer.
Therefore add a check for this to avoid a crash.
Fixes: QTBUG-111527
Change-Id: I6443d5d1a9b813f499d8f65b4fee55b0b8299b16
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We are using eglfs in VxWorks which make 3 few testcases fail, because eglfs windows are fullscreen by default.
This is the same solution as in qt5 in tag 5.12.6 from commit with hash 39027ef076c.
[...] EGLFS forces the first top-level window - either a QWidget or a QQuickView - to become fullscreen. [...]
from: https://doc.qt.io/qt-6/embedded-linux.html
Change-Id: I3ab3208b3c7c1b2e27d879bac1ee0679f48109e2
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Use the arguments to call the parent class implementation.
Pick-to: 6.5 6.6
Change-Id: I602a66447fb8681b3ec9ef8e2e281828612d178c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A foreign window embedded into a Qt hierarchy must also support
being removed from that window hierarchy.
Pick-to: 6.6
Change-Id: Id4d08079ff19d67a8989937bc72602e8bd14b31b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
In be268ae197 we made QCocoaWindow::setVisible
idempotent by checking if NSView.hidden needed update.
This failed to take into account the case when a window is moved from
being a child window to a top level, where the window is still visible
and the NSView's hidden state doesn't change, but we need to order in
the NSWindow that we're now managing.
We now check NSWindow.visible as well, if we're a top level window.
Pick-to: 6.5 6.6
Change-Id: I94434d6ebfe2c9ece6eac7f83f17ead250ccc07a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
When a child window is made visible without its parent having been
created yet, we defer creating and making the child visible until
the parent is created.
But if a child window is explicitly created, we create the parent
first. And creating the parent will in turn apply visibility to
all children that had their visibility deferred. Which includes
creating the child.
This results in child -> parent -> child creation recursion,
which means that when we return from creating the parent window
we already have a platform window for our child, and should
bail out.
Pick-to: 6.6 6.5
Change-Id: I11dc4864b57f031de2cca70b79cdfc057d4fbd0d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
All these TUs relied on transitive includes of qpointer.h, maybe to a
large extent via qevent.h, though, given that qevent.h is more or less
the only public QtBase header that includes qpointer.h, something else
seems to be at play here.
Said qevent.h actually needs QPointer in-name-only, so a forward
declaration would suffice. Prepare for qevent.h dropping the include.
The algorithm I used was:
If the TU mentions 'passiveGrabbers', the name of the QEvent function
that returns QPointers, and the TU doesn't have qpointer.h included
explicitly, include it. That may produce False Positives, but better
safe than sorry. Otherwise, in src/, add an include to all source and
header files which mention QPointer. Exception: if foo.h of a foo.cpp
already includes it, don't include again.
Task-number: QTBUG-117670
Change-Id: I3321cccdb41ce0ba6d8a709cea92427aba398254
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
After d9bb8c0a17 we call inputDirection()
on the platform input context to initialize the direction at startup.
The test can't assume there are no other callers to the functions
in the QPlatformInputContext layer.
Change-Id: Ic1cecd608b2759e703a17838fcf24b4ff53ad07e
Reviewed-by: Liang Qi <liang.qi@qt.io>
Thiago Macieira
Audun Sutterud
Friedemann Kleint
Shawn Rutledge
Liang Qi
Ahmad Samir
Tor Arne Vestbø
Volker Hilsheimer
Marc Mutz
Jari Helaakoski
Giuseppe D'Angelo
Tasuku Suzuki
Lucie Gérard
Doris Verria
Christian Ehrlicher
Marcin Zdunek