This code, after applying it to linguist, didn't compile.
Change-Id: I25011a44ca059a149f041f8f07848232883140cc
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
After we started defaulting to high-dpi enabled, it was discovered
that it does not work correctly with the placeholder screen. Since
the placeholder screen has no physical size, and the default
implementation of logicalDpi() divides by the physical size, we
got a scale factor of NaN in the high-dpi code.
The effect of this was that the nooutput test in Qt Wayland would
fail, because it did not get the events it was expecting, since
the window geometry was never set to a valid rect in the
resize() call.
Task-number: QTBUG-86698
Change-Id: I7ee68db9a13446b414502ae0f26fd214531c673a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The non-deprecated one called the deprecated one :-(
Inline the deprecated one and simplify, given the null pointer passed down.
Change-Id: I5b99053357fc3be109e61ccf1161835bf527b686
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The reason for this bug is that after the TextItem loses focus,
the focusItem in QGraphicsScene is already empty.
When QGraphicsScene responds to the inputMethodEvent event again,
since focusItem is already empty,focusItem will no longer deliver events.
Fixes:QTBUG-85088
Pick-to:5.15
Change-Id: I329054333c2adec133d35318761612aca3afcf0d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Use QVERIFY in test functions, and (void)tr.load outside.
Change-Id: I18d2eb3aeaf00f9f2bbe75d0a2d8b12569b541e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
These states correspond well with ScrollPhase, and this abstraction
makes it possible to handle wheel events the same way as mouse events
in Qt Quick: on "begin" we deliver to all Items and Handlers until
all points (the only point) are accepted; on "update" and "end" we
deliver only to the exclusive grabber, if there is one, and to any
passive grabbers.
Change-Id: I702dbd4f2c1bf5962eb3dbb9e4b725300a00a887
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
These docs are not part of the generated docs due to QRhi being private,
but nonetheless keep it useful.
Change-Id: Ic46aaa4cd329535c37fffcd514ba354dff4bfb5c
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Do not qHashBits on the whole data that is at least 260 bytes, a big
part of it often unused. Just hash binding/stage/type and the first
resource pointer.
Change-Id: If9b3dc9acf36edf225302b1216d91e87b652b8ef
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
When we know the spec already, we can route to the correct branch of
the check directly. This also prepares the way for avoiding
duplicating the expensive check for LocalTime during
setMSecsSinceEpoch().
In the process, move duplicated code into massageAdjustedDateTime()
from its callers, to avoid adding verification to the duplication; and
clean up refresh{now: Zoned}DateTime().
Change-Id: I04d7a417110109d1f246a891b5aa94945821804b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Various places in moc relied on the magic behavior of QByteArray, that
provided a non-null pointer to a null byte when the byte array was
null, resulting in crashes when QT5_NULL_STRINGS is turned off. Fixed
them to cope with this (and optimised out some pointless effort, when
empty QByteArrays are involved, in the process).
Change-Id: I617a878eb2e9ac8be244080efa1f0de4ac9a68a2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Use ternary operator form, or boolean algebra, for the short returns.
Handling invalid differently from valid isn't symmetric, they're
qualitatively different branches.
Skip a fatuous default-initialization.
Change-Id: I01a8a06055c315ecf08fc87d208808c0fe71eb31
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is lossy, so should be requested explicitly, using a dedicated
fromPixmap factory function.
Deprecate the constructor and assignment operator, and make the
constructor explicit.
[ChangeLog][QtGui][QBitmap] Implicitly constructing and assigning
to a QBitmap from a QPixmap has been deprecated, and the respective
constructor has been made explicit. Use the fromPixmap factory
function instead.
Change-Id: I68ce85b26c901415137b664a1db687021d48bae0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QToolButton::initStyleOption is const. Apply some DRY while at it.
Change-Id: If29a52e828bbc2aa58df2852c4c434545acfef3e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Allow Gradle builds to run using JVM daemon, this will improve the
current build time noticeably for clean builds and hugely for
incremental builds.
This will bring the Gradle build to comparable speed with a normal
Gradle build in Android Studio.
Task-number: QTBUG-86674
Pick-to: 5.15
Change-Id: Icc4267223802e4c9350b48099236650c023f868d
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
There were a small typos about those methods and fixed with correct ones.
Fixes: QTBUG-86635
Change-Id: Ib853e502fdcdafdf3ddf7ef6d25d368ebc2a631f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Adjust to changes to QIcon::pixmap, QMetaType::type, and
QAbstractItemView::itemDelegate.
Change-Id: I9eb0331ef899131afc86c33f27feeee76331ffc8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
...not with the given point. Since QEventPoint has a constructor that
takes an id, it's possible to write something like
pointerEvent->setExclusiveGrabber(pointId, object)
which will construct a QEventPoint on-the-fly, containing only an id.
(That was unintentional, but perhaps useful sometimes.)
setExclusiveGrabber() looks up the persistent point, but if we emit the
signal with the given point, it is missing the device. A handler
connected to that signal might reasonably assume that the point is a
complete instance; so we'd better emit the complete instance that we
found. (OTOH if the given point was a detached instance, it might also
be unexpected that the signal emits the persistent instance instead of
the given instance.) Amends 2692237bb1
Change-Id: Iee16363dcb22c1dc07b0cc0a81930218e22fa19e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Because of these lines in the Linux kernel (kernel/fork.c, see [1][3]):
if (clone_flags & CLONE_VFORK)
trace = PTRACE_EVENT_VFORK;
else if (args->exit_signal != SIGCHLD)
trace = PTRACE_EVENT_CLONE;
else
trace = PTRACE_EVENT_FORK;
Without CLONE_VFORK (which we can't use), if the exit signal isn't
SIGCHLD, the debugger will get a PTRACE_EVENT_CLONE, which makes it
think the process we're starting is a thread, not a new process. Both
gdb and lldb remain attached to the child and when it later performs an
execve(), they get mightily confused. See gdb bug report[5].
The idea of not having an exit_signal was so that no SIGCHLD would be
delivered to the parent process in the first place. That way, some
misguided SIGCHLD handler (*cough* GLib *cough*) wouldn't reap our
processes. Unfortunately, what I didn't realize was that the kernel
sends SIGCHLD anyway (see [2][4]), so this defensive measure didn't
actually work. Consequently, we can pass SIGCHLD to clone() and get the
debuggers working again.
[ChangeLog][Linux] Fixed an issue that would cause debugging a Qt
application that uses QProcess to confuse both gdb and lldb if
the Linux kernel was version 5.4 or higher. Behavior outside of
a debugging session was not affected.
[1] https://code.woboq.org/linux/linux/kernel/fork.c.html#_do_fork
[2] https://code.woboq.org/linux/linux/kernel/signal.c.html#do_notify_parent
[3] https://elixir.bootlin.com/linux/v5.8/source/kernel/fork.c#L2432
[4] https://elixir.bootlin.com/linux/v5.8/source/kernel/signal.c#L1925
[5] https://sourceware.org/bugzilla/show_bug.cgi?id=26562
Fixes: QTBUG-86319
Pick-to: 5.15
Change-Id: I2fc68c725ba649218bd9fffd1633863613537d42
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: hjk <hjk@qt.io>
Our CI cross-compiling arm qemu builds have issues in tests that use
QProcess, due to user-space qemu seemingly not supporting pidfds
properly.
Add a 'forkfd_pidfd' configure.json feature, which can be manually
disabled when configuring Qt, causing QProcess to do a regular fork
instead of using the new pidfd kernel feature.
This will help us avoid the regression of multiple tests failing on
the new Ubuntu 20.04 CI host images when they are run via qemu.
Task-number: QTBUG-86285
Task-number: QTBUG-86187
Task-number: QTBUG-86198
Change-Id: Ib2209d7e95126e0fb738bf59e39070d5a62c482f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qt_add_test supports now QT_TEST_SERVER_LIST, which will add the test
servers as docker test fixtures.
The docker server will be started before the test is run, and stopped
after the test is run.
Running the tests in parallel is not supported.
Docker tests are currently only supported on Linux hosts.
Task-number: QTBUG-85034
Change-Id: If3cefe05c5dec19c14b05d2fa8b01a0b6d95e259
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Create a colormap per visual, not per window.
Pick-to: 5.15
Change-Id: I97d94618f159b4beaffd4a1afe0611233ced6676
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is in accordance to the examples from harfbuzz docs:
https://harfbuzz.github.io/ch03s03.html
The fix is because `pkg-config --cflags harfbuzz` returns
the subdirectory as include path, for example:
-I /usr/local/include/harfbuzz
and this caused the system-harfbuzz not to be found when
/usr/local/include was not included by default (recent change on
macOS) and the code was doing #include <harfbuzz/hb.h>.
Fixes: QTBUG-85568
Change-Id: I12a34638e8ad5e3085768828457f0bfa1a2c68ad
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Use -source 8 and -target 8 for javac by default.
Task-number: QTBUG-86282
Change-Id: I291beab4df166468972138822ca26f01c9666985
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
The configure options -android-javac-source and -android-javac-target
can be used to set the version numbers.
Fixes: QTBUG-86282
Pick-to: 5.15
Change-Id: I36b0665de2c31e16bf6d138859b5503455eb8e66
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
... in order to avoid a bogus compiler warning.
Change-Id: I25eb435d6d57bdd5ef5c05ccacb0e6413631f6c9
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Change the rounding of negative half values to match standard C++
round, this will also allow future optimizations.
Change-Id: I8f8c71bed1f05891e82ea787c6bc284297de9c5c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also add existing such docs to the new document group
Task-number: QTBUG-84051
Change-Id: I76f033f0846e09943f249d2beeb1606869eef382
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QCoreApplication object is instantiated, creation of the internal
message window is delayed until QEventDispatcherWin32::processEvents()
is called or socket/event notifier is registered. But, if the user uses
a native event loop, posted events are not delivered and timers do not
work.
This problem was fixed in a4ac4b3263 for
QWindowsGuiEventDispatcher in the same way. So, the risk of regression
is minimal.
Change-Id: I7bbb721d96046f64d21a7b0e553e46798b37189c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Avoids a linking error when the library is not found as
find_library sets GLESv2_LIBRARY to GLESv2-NOTFOUND
Change-Id: I7ddc15483276e0be0c78b67b760c4d9188758270
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@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>
This functionality was only in Qt Quick in Qt 5. Now we move it up to QtGui
so that every QEventPoint will have a valid velocity() before being delivered
anywhere.
[ChangeLog][QtGui][QPointerEvent] Every QEventPoint should now carry a valid
velocity(): if the operating system doesn't provide it, Qt will calculate it,
using a simple Kalman filter to provide a weighted average over time.
Fixes: QTBUG-33891
Change-Id: I40352f717f0ad6edd87cf71ef55e955a591eeea1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QQuickEventPoint instances were very long-lived and got reused from one
event to the next. That was initially done because they were "heavy"
QObjects; but it also became useful to store state in them between
events. But this is in conflict with the ubiquitous event replay
code that assumes it's OK to hold an event instance (especially
a QMouseEvent) for any length of time, and then send it to some widget,
item or window. Clearly QEventPoints must be stored in the QPointerEvent,
if we are to avoid the need for workarounds to keep such old code working.
And now they have d-pointers, so copying is cheap. But replay code
will need to detach() their QEventPoints now.
QEventPoint is useful as an object to hold state, but we now store
the truly persistent state separately in an EventPointData struct,
in QPointingDevicePrivate::activePoints. Incoming events merely
update the persistent points, then we deliver those instead.
Thus when event handler code modifies state, it will be remembered
even when the delivery is done and the QPA event is destroyed.
This gets us a step closer to supporting multiple simultaneous mice.
Within pointer events, the points are moved up to QPointerEvent itself:
QList<QEventPoint> m_points;
This means pointCount(), point(int i) and points() can be non-virtual.
However in any QSinglePointEvent, the list only contains one point.
We hope that pessimization is worthwhile for the sake of removing
virtual functions, simplifying code in event classes themselves, and
enabling the use of the range-for loop over points() with any kind of
QPointerEvent, not just QTouchEvent. points() is a nicer API for the
sake of range-for looping; but point() is more suited to being
non-const.
In QML it's expected to be OK to emit a signal with a QPointerEvent
by value: that will involve copying the event. But QEventPoint
instances are explicitly shared, so calling setAccepted() modifies
the instance in activePoints (EventPointData.eventPoint.d->accept);
and the grabbers are stored separately and thus preserved between events.
In code such as MouseArea { onPressed: mouse.accepted = false }
we can either continue to emit the QQuickMouseEvent wrapper
or perhaps QEvent::setAccepted() could become virtual and set
the eventpoint's accepted flag instead, so that it will survive
after the event copy that QML sees is discarded.
The grabChanged() signal is useful to keep QQuickWindow informed
when items or handlers change exclusive or passive grabbers.
When a release happens at a different location than the last move event,
Qt synthesizes an additional move. But it would be "boring" if
QEventPoint::lastXPosition() accessors in any released eventpoint always
returned the same as the current QEventPoint::xPosition()s just because
of that; and it would mean that the velocity() must always be zero on
release, which would make it hard to use the final velocity to drive an
animation. So now we expect the lastPositions to be different than
current positions in a released eventpoint.
De-inline some functions whose implementations might be subject to
change later on. Improve documentation.
Since we have an accessor for pressTimestamp(), we might as well add one for
timestamp() too. That way users get enough information to calculate
instantaneous velocity, since the plan is for velocity() to be somewhat
smoothed.
Change-Id: I2733d847139a1b1bea33c00275459dcd2a145ffc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It should not be necessary to have the xkb dev package installed for
users of QtGui.
Task-number: QTBUG-86421
Change-Id: I4a4102d578df504d23f504a97704fcab4a39023b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The test was previously using int; I shall be wanting to add tests
that exercise the bounds of qint64. Clean up the layout of the
test-row additions in the process of making a trivial change to them
all. Also const the QFETCH() types so we catch any use of non-const
methods on the values fetched.
Change-Id: I4b0187de71f5f14b39b4eabe8afd12a196f73d23
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
And remove another ### Qt comment, this time ### Qt 5.
Change-Id: I1d5cef47ddd81b6a27f870599128c8f16846c350
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Instead of using imprecise QTest::qSleep() to estimate the
elapsed time, we trigger a single shot PreciseTimer and
gather all the data in lambda. We wait for lambda to be
executed - we give it twice as much time as is in theory
needed. Afterwards we verify all the data collected in lambda.
Task-number: QTBUG-82903
Change-Id: I0147b7cd2aaf4bf58a216caff167d2db8712541a
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Some CMake files currently assume that QtGui is always enabled and we
get a configure-time failure without these changes.
Task-number: QTBUG-86053
Change-Id: I28e32c180c32221f32519017bac6b518a19d5983
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
If a consumer wants to cross-compile a Qt app, they need to provide
the host Qt path location.
When building Qt in the CI we embed the Qt host path into the
generated CMake toolchain file for convenient building of other Qt
modules.
But once Qt is built, packaged and installed on a user's machine, most
likely the Qt host path will not be the same. In such a case, if the
user wants to use the convenience toolchain, they should explicitly
provide the Qt host path via the QT_HOST_PATH and
QT_HOST_PATH_CMAKE_DIR variables.
Show an error message if the values are not provided or don't exist
on the file system.
It's possible that in the future the Qt installer will patch the
toolchain file, or provide additional info, to point to the host
Qt installation so that the user doesn't have to do it manually.
But until that's done, a friendly error message is a good way to
inform the user what they should do.
Task-number: QTBUG-83999
Change-Id: I26291e3c47bb77375f8a5ce7b848c0382a660ca9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
