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>
Public consumers of the qt toolchain file will most likely not have
their compilers in the same location where they were on the Qt build
machine.
Only set the compiler paths if none was set already, and the paths
actually exist.
This seems to become a trend in the generated toolchain file, and is
only a stop-gap solution.
A proper solution (two different toolchain files) may follow.
Task-number: QTBUG-83999
Change-Id: I7a603af447333a45c65b98e299ee109932d16517
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Do follow the example of winmain.pro and replace /Zi with /Z7.
Manipulating CMAKE_CXX_FLAGS_DEBUG is not particularly elegant,
but CMake seems not to offer a more modern way yet:
https://gitlab.kitware.com/cmake/cmake/-/issues/19084
Fixes: QTBUG-86423
Change-Id: I280d06ad52b79d4be04052ab4e0d2113ef08414c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A previous change accidentally broke what we we set for
QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR.
The QT_HOST_PATH variable should use an absolute path as it was
done before.
The QT_HOST_PATH_CMAKE_DIR variable incorrectly used the value of
"${QT_HOST_PATH}" instead of "${QT_HOST_PATH_CMAKE_DIR}".
Fix both of these, and change the names of intermediate variables
to be consistent.
Amends a6a3b82ffb
Task-number: QTBUG-85240
Change-Id: I328a7edee12a13ff793684e8a0a4c2e03204eca4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The qfilesystemmodel.pro was recently moved to the gui tests subfolder,
but it uses widgets inside. Skip it in a no-widgets build.
Amends fb9ec8ad44
Task-number: QTBUG-86187
Change-Id: I955556ffddad483d4c25602ae126b8c2433091b2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This requires refactoring of QMetaSequence, as they share a lot of
common functionality. QMetaAssociation provides a low level interface to
an associative container.
Task-number: QTBUG-81716
Change-Id: I273e00abd82f1549ba8803c323d82aa3a2d12ded
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Updated QIcc::fromIccProfile() and friends to not rely on
QByteArray pointer alignment. Used qFromUnaligned() instead
Task-number: QTBUG-84267
Pick-to: 5.15
Change-Id: I69ef7e011707bec27cd84693e7f0e92d79a577d1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
[ChangeLog][QtCore][QString] QString is a prepend optimized
container similar to QList.
Task-number: QTBUG-84320
Change-Id: Id035aac859a6f404e389f2eeaf20f9eee5bff20c
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Amends f9940b15f7, which
amended 6e1d70ae12.
The bevel of the button is not defined by the contentsRect, but by the
borderRect that the stylesheet style calculates.
Change-Id: I9a0d5bf29a06ce2270014f0d144e33cc3a1a7473
Pick-to: 5.15
Fixes: QTBUG-86587
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Otherwise we hit an #error statement in MSVC standard library.
Change-Id: Ib029edf0be8513a80f2640fd9ca75541615a0448
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
test.bjon file doesn't exist, however, it's still included in json.qrc.
That causes the test to fail on Android because it's using that resource
file.
Change-Id: I1e93076069073a1a621459a7d90aec5c0c03f768
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The macro BACKTRACE_HELPER_NAME is defined inside a block with
#ifdef __GLIBC__ which is not defined on Android, thus causing the test
to fail on Android.
Change-Id: I55e9b3e3bae2da182481239ad88107c36e3bd438
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This prevented QDoc from parsing the properties correctly.
Change-Id: Ib3e02eb29a5c35034c30a3dd9fdf797d4c7e1550
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
For this build, cxx11_future is not available and thus
QThread::create() as introduced by
ed114b728d does not work.
Revert back to implementing a QThread.
Pick-to: 5.15
Fixes: QTBUG-86575
Task-number: QTBUG-85676
Change-Id: I86a91f6bcdfc88804b35bf617362d92f37e51dea
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This was overlooked when doing the conversion to use UTF-8 as the
standard 8 bit encoding for text.
Fixes: QTBUG-54942
Change-Id: Ib7b1b75b4d694648ab7143f6930b6bb1dcad19c9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
