Change lots of code to avoid the deprecated operator+() or implicit
casts to int.
Change-Id: I0c343cd5b28603afdf1214eefb85e928313345e2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QtConcurrent algorithms are making an internal copy of the passed
sequence, to make sure it won't be destroyed before the execution
is finished. However, they were using iterators of the originally
passed sequence. So, if the original sequence is deleted, QtConcurrent
algorithms would use invalid iterators to a deleted sequence. This
might work with Qt containers thanks to implicit-sharing, but with
other containers will lead to unexpected results. Fixed them to work
on the internal copy of the original sequence.
Change-Id: I1d68692ed9746223c85f51bb05977bc1443b681d
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
Before we had the option of eager evaluation, we were able to use the
dirty flag to detect whether we are recursing. However, eager properties
will lead to a evaluateIfDirtyAndReturnTrueIfValueChanged call, and that
in turn will clear the dirty flag.
Introduce a new member to detect that situation, and set the bindings
error state to BindingLoop if we detect that kind of loop.
Change-Id: If40b93221848bd9e9422502318d992fad95b0b74
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Do not always use the smoothScaled routine, the normal routines are
also optimized, and do not convert to alpha formats when not necessary.
Task-number: QTBUG-49719
Change-Id: I6ee9b620cc259472c419e7363357f41ce29b594a
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Configuring and building Qt should not require a running dbus session bus.
However, when building the html_docs target on a headless system, qmake bails
out with error if dbus is linked in, while only showing a warning if it's not.
This is unnecessary. We can warn in both cases, build the tests with dbus
linked in. Running the tests will fail if there is no session bus, ie.
tst_QDBusConnection_Delayed::delayedMessages fails with
QVERIFY(session.isConnected);
Pick-to: 5.15
Change-Id: Ia6b6e226398e87880449b003d28dfd76553bee2c
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
It was already used many places directly making the code inconsistent.
Change-Id: I3b14bc6c333640fb3ba33c71eba97e78c973e44b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If it does not add item,the currentText should return empty string
Fixes: QTBUG-86580
Pick-to: 5.15
Change-Id: I54c3a8b7ececfb1e62bcd7ac592feccaff3f8b48
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Current implementation of QLineEdit uses the "edited" bit-field flag to
prevent unnecessary emissions of editingFinished() when a line edit
loses focus but its contents have not changed since the last time the
signal was emitted; however, this flag is only cleared when the signal
is fired due to focus loss and not when the Return/Enter key is pressed.
This causes an unexpected double emission of the signal when focus is
lost following a press of the Return/Enter key if the line edit's text
was not further altered between the two actions.
This change includes the Return/Enter press as a trigger for clearing
the "edited" flag to make editingFinished()'s behavior more consistent
and expected. Prevents slots in user code from triggering twice in
situations where the line edit's current contents have already been
handled, but still allows the end-user to force an emission of the
signal via Return/Enter.
The effect of the "edited" flag on the signals behavior has also been
noted in the signal description as it was previously omitted.
[ChangeLog][QtWidgets][QLineEdit][Behavior Change] Pressing the
Return/Enter key in a QLineEdit will now also prevent editingFinished()
from firing due to focus loss if the contents of the line edit have not
changed since the last time the signal was emitted.
See - https://forum.qt.io/topic/116902/
Change-Id: I11aadd45341337b7852da8cf5802c7c9efdd614d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Change the implementation of Qt DBus to use QMetaType directly
instead of integer based type ids.
Change-Id: I999023b58fa50dcc3504386467faf09874f7d2cf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Modernize the code base, use QMetaType and avoid
reinterpret_casts.
Change-Id: I0bad2ee393a0f850cf40b248cb9439b06ed9f663
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It already has a move-assignment operator, and implements swapping.
This requires a specialization of the QExplicitlySharedDataPointer
destructor to be forward declared, and an implementation that is
identical to the default version. Otherwise we would need
QPlatformPixmap to be fully defined in the public QPixmap header.
Change-Id: I2651bbc29a7083a93e3b3ad671d3aeea659b7d5a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
In the past, string formatting and parsing was done in the users
locale. Now, the C locale is consistently used in QDate(Time) and
localized functions are offered in QLocale. This patch reflects
this change in the documentation.
Change-Id: I81afda9063fa232d06841d63f69e19b49f8083f3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Colors with wrong number of elements are now invalid.
Change-Id: I32c934894de86095d9790baa5f0d2001d76bcd3c
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QDateTime's comparisons just compare milliseconds when both values are
local times and their statuses (hence DST-ness) match. It can do the
same for time-zones. While doing the same for UTC and fixed offsets
wins nothing, it also costs nothing, given that we're already checking
the spec.
Task-number: QTBUG-75585
Change-Id: Ib6d824569aba8def2f1319ef3a11cca6869a5b5e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add some unit tests using emojis as separator characters to check
utf handling.
Change-Id: I03c4bb5cd349e649c58e8a908c38a0185d80e722
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Binary provider:
It was not possible to remove the first glob in a local override,
because the mainPattern handling would re-add the first glob back.
XML provider:
It didn't support glob-deleteall.
Also, the order of the providers was wrong. We want to pick local
overrides first, the internal DB has to go last in the list.
Fixes: QTBUG-85436
Pick-to: 5.15
Change-Id: I9a4523f37cd962c730df9a6ed992bd01c075bf03
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To avoid potential decompression bombs. This is implemented with just
a simple check that the ratio doesn't pass some hardcoded preset.
Change-Id: I17246f0f43e73280cdb35a8f03d65885f5678ad6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Clean up the state of the projects,
before changing the internal CMake API function names.
Task-number: QTBUG-86815
Change-Id: I90f1b21b8ae4439a4a293872c3bb728dab44a50d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
tst_qguiapplication was missing an Info.plist file.
We can't directly reference the tst_qcoreapplication Info.plist
file like the qmake project does, because that breaks ninja
(says multiple rules create the same output file), so use a
copy instead.
Blacklist the qpluginloader loadMachO test when doing CMake builds.
The qmake projects use multiple custom rules to build the macho
plugins, which need to be ported to CMake.
Task-number: QTBUG-86053
Task-number: QTBUG-86792
Change-Id: Iaff2b2d5e9e84a457b4f2ffc011a580388498f00
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
MSVC has strange problems with it and we don't actually need it.
Change-Id: I2c443946d52d475208800f310b5f910da165c99b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Changes the definition of invalid QRects to be more consistent.
This simplifies the logic, and makes it possible for us to fix
normalized() so dimensions don't change.
The actual API is not changed except for inverted rects.
Only one use-case for the old normalized() function existed,
and has been reimplemented as QRect::span().
Fixes: QTBUG-22934
Change-Id: I29dad2952dc6c8e84a6d931898dc7e43d66780f3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Do not use QVariant::Type anymore, instead use QMetaType
For some reason, this pushed the qvariant autotest over the limit where
MSVC requires the /bigobj flag, so add that one.
[ChangeLog][QtCore][QMimeData] The signature of the virtual retrieveData()
function has changed and now takes a QMetaType instead of a QVariant::Type.
Change-Id: Ib46773bd731ee2177b1ef74d8162d744be7017ef
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Resolve remaining Qt6 TODO
[ChangeLog][QtCore][QAbstractEventDispatcher] The signature of the abstract virtual registerTime function now takes a qint64 value for the interval parameter.
Change-Id: I10166ad5cfb455edc404d465a3731ff094a8977e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Current implementation of QProgressDialog always calls
QCoreApplication::processEvents() when the user calls
QProgressDialog::setValue() if the PD is modal. For most cases this is
fine, but when using a Qt::WindowModal PD with setValue() connected to
a signal in another thread using Qt::QueuedConnection a reentrancy
issue is present if setValue() is triggered too frequently as the
execution of its previous call may not have finished. If this happens
too many times in a row a stack overflow will occur.
Current documentation notes this potential issue but offers no way it
avoid it while still using QProgressDialog (user must implement a
custom dialog) without resorting to using Qt::BlockingQueuedConnection,
which unnecessarily reduces performance.
Introduces the boolean reentrancy guard "processingEvents" that is
checked before calling QCoreApplication::processEvents() in a modal
PD when setValue() is used. It is set before the first call to
processEvents() and cleared after that call returns. This ensures that
only one invocation of processEvents() is possible from within
setValue() at a time, and thereby minimizes iterations of the main event
loop and eliminates the aforementioned stack overflow condition.
See - https://forum.qt.io/topic/118292/
Fixes: QTBUG-10561
Pick-to: 5.15
Change-Id: Ifa9b91cbb66881981356954ead0906bdc91fab60
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
In order to modify a container through an iterable, we need the original
container to be mutable. The iterable, then, is not a conversion of the
container, but rather a view on the container. The concept may be
extended to other types.
In order to facilitate this, provide a set of methods in QMetaType and
QVariant similar to the convert family. The new methods are non-const
and expect the original value to stay available during the life time of
the view.
Change-Id: I363621033f7fc600edcea2acb786820ccba49c86
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
And add mutable iterators. This requires some refactoring of the
existing iterators.
Task-number: QTBUG-81716
Change-Id: I61b3a3e8c0df5fd449679257a29d9f0c3d19c4f0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The constructor taking an array literal will now stop at the first
null-terminator encountered.
And fromArray is introduced which only supports array literals.
Constructs a view of the full size. Explicit so it shouldn't be
surprising.
Change-Id: I1497c33a5c12453a95e87c990abe6335b2817081
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
1. Make the ctor unable to construct a QByteArrayView from
array literals other than 'char'.
With the new behavior it would either be (very likely) unintended to
pass e.g. a std::byte array to the ctor. And it would be confusing
because you would get different sizes based on signed-ness.
2. Introduce fromArray
Only supports array literals. Constructs a view of the full size.
Explicit so it shouldn't be surprising.
Change-Id: Ifdb55eb21057dfe7053b2561bd81e2c9825e9bc6
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@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>
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>
Adjust to changes to QIcon::pixmap, QMetaType::type, and
QAbstractItemView::itemDelegate.
Change-Id: I9eb0331ef899131afc86c33f27feeee76331ffc8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
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>
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>
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>
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>
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>
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>
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>
