We were already using the 'native' nomenclature when referring to these
kinds of APIs, e.g. when talking about native handles, or the existing
QPlatformNativeInterface on a QPA level. Using 'native' for the user
facing APIs also distinguishes them from the 'platform' backend layer
in QPA and elsewhere.
Change-Id: I0f3273265904f0f19c0b6d62471f8820d3c3232e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@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>
Reports on the Web have it that there's nothing guaranteeing a
driver does any actual freeing of resources then doing
vkFreeCommandBuffer for a command buffer from a command pool that
does not have VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT, thus
leading to continuously growing resource usage with our current
allocate/free pattern. It could be that this is the source of out
of memory problems we are seeing on some Android devices.
Instead of just going straight for said command pool flag and doing
ResetCommandBuffer for the command buffers individually, take one
step further and use per-slot (slot being 0 or 1 if QVK_FRAMES_IN_FLIGHT
is 2) command pools. The current pool is reset in each
beginFrame/beginOffscreenFrame, moving all allocated command buffers
to the initial state (while other command buffers with the other pool
are not affected).
This may be (while impossible to tell from just guessing based on the
spec) our best approach to command buffer allocation since a Vulkan
implementation can likely just use some simple per pool allocator,
knowing that we never want to free or reset individual command buffers,
but we rather only reset the whole pool at once.
The option of importing an existing VkCommandPool when creating the
QRhi instance is now gone, but there was probably no point in offering
that in the first place.
When it comes to VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT it will
not be set unless releaseCachedResources() (in Qt Quick this is hooked
into QQuickWindow::releaseResources()) was called. What this does in
practice is unknown, but have an option to set it now and then if the
application really wants.
While we are at it, rename secondaryCbs to activeSecondaryCbStack to
indicate what it really is. (it's a stack as each call to
beginExternal() pushes a new one, while each endExternal() pops)
Change-Id: I2e5c1fad26d794e1f56c778e38f750998d706d84
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
ExternalContentsInPass becomes a per-pass flag now. Why is this
beneficial? Because while Qt Quick has no choice for its render
pass, not being able to guess if the application wants to do some
native rendering in there, Quick 3D's render passes, all the ones
that are under Quick3D's control, do not have native rendering
from the application in them, and so using secondary command
buffers with Vulkan is not necessary.
Introduce something similar for compute and OpenGL. By knowing that
none of the resources used in a pass are used with a compute pass
(e.g. because we know that there are no compute passes at all) a small
amount of time can be saved by skipping tracking buffers and textures
because the only purpose of said tracking is to generate barriers that
are relevant only to compute.
Change-Id: I0eceb4774d87803c73a39db527f5707a9f4d75c1
Reviewed-by: Andy Nichols <andy.nichols@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>
This reverts commit b1ef104866.
This test is BPASS on openSUSE_42_3 for 5.12 and PASS on openSUSE_15_1
for 5.15.
Pick-to: 5.15
Pick-to: 5.12
Change-Id: Ia1d81ed38491c27c01f270623c5082663f4da699
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
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>
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>
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>
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>
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>
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>
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>
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>
Adjust to changes to QIcon::pixmap, QMetaType::type, and
QAbstractItemView::itemDelegate.
Change-Id: I9eb0331ef899131afc86c33f27feeee76331ffc8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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 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>
As per ### Qt6 comment. Also rename the LibraryLocation enum
to LibraryPath.
Change-Id: I556025a19c5bcdf2ff52598eaba32269522d4128
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no reason to use double precision for colors. We at most have
16 significant bits anyway.
Change-Id: I8b402cd978675b8ba7248176976d934363212ff1
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
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>
Gives it its own changed signal, and simplifies setting from group,
while fixing an inconsistency in propagation.
Change-Id: I22b243210260a8878144fa4b60204df46f847f37
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
I still have doubts that QEventPoint can't be made small enough that
copying would be cheaper than reference-counting and all the indirections
in now-noninline accessors, but this gives us the usual freedom to
change the data members later on.
Change-Id: I792f7fc85ac3a9538589da9d7618b647edf0e70c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Because we removed public setters from QTouchEvent and QEventPoint in
4e400369c0 and now it's proposed to give
QEventPoint a d-pointer again, the implementation of QTouchEventSequence
needs to start using QMutableEventPoint: being a friend will no longer
be enough, because the member variables won't be accessible in the future.
But because we have separate test libs for Gui and Widgets, it needs to
be further refactored into two classes.
Change-Id: I0bfc0978fc4187348ac872e1330d95259d557b69
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Following the introduction of QKeyCombination, reduce the number
of warnings raised by the test. Drive-by, remove some pointless
math like Qt::SHIFT+0, which does not make any sense and would
actually fail to compile (shortly).
Refactoring the test to fully use QKeyCombination (instead of
ints) is left as a future exercise; some QKeyCombination->int
warnings are still around.
Change-Id: If825bc4c369986623447927bb11493c4f58b544f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Adjusting the QPrinter test case - some use cases no longer exist, or are
already tested in QPageSize and QPageLayout tests.
Adjust examples and manual tests.
Change-Id: I01cbc65f3d8031aea2dac86dd942126ba708b111
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
C++20 via P1120 is deprecating arithmetic operations between
unrelated enumeration types, and GCC 10 is already complaining.
Hence, these operations might become illegal in C++23 or C++26 at
the latest.
A case of this that affects Qt is in key combinations: a
QKeySequence can be constructed by summing / ORing modifiers and a
key, for instance:
Qt::CTRL + Qt::Key_A
Qt::SHIFT | Qt::CTRL | Qt::Key_G (recommended, see below)
The problem is that the modifiers and the key belong to different
enumerations (and there's 2 enumerations for the modifier, and one
for the key).
To solve this: add a dedicated class to represent a combination of
keys, and operators between those enumerations to build instances
of this class.
I would've simply defined operator|, but again docs and pre-existing
code use operator+ as well, so added both to at least tackle simple
cases (modifier + key).
Multiple modifiers create a problem: operator+ between them yields
int, not the corresponding flags type (because operator+ is not
overloaded for this use case):
Qt::CTRL + Qt::SHIFT + Qt::Key_A
\__________________/ /
int /
\______________/
int
Not only this loses track of the datatypes involved, but it would
also then "add" the key (with NO warnings, now its int + enum, so
it's not mixing enums!) and yielding int again.
I don't want to special-case this; the point of the class is
that int is the wrong datatype. Everything works just fine when
using operator| instead:
Qt::CTRL | Qt::SHIFT | Qt::Key_A
\__________________/ /
Qt::Modifiers /
\______________/
QKeyCombination
So I'm defining operator+ so that the simple cases still work,
but also deprecating it.
Port some code around Qt to the new class. In certain cases,
it's a huge win for clarity. In some others, I've just added
the necessary casts to make it still compile without warnings,
without attempting refactorings.
[ChangeLog][QtCore][QKeyCombination] New class to represent
a combination of a key and zero or more modifiers, to be used
when defining shortcuts or similar.
[ChangeLog][Potentially Source-Incompatible Changes] A keyboard
modifier (such as Qt::CTRL, Qt::AltModifier, etc.) should be
combined with a key (such as Qt::Key_A, Qt::Key_F1, etc.) by using
operator|, not operator+. The result is now an object of type
QKeyCombination, that stores the key and the modifiers.
Change-Id: I657a3a328232f059023fff69c5031ee31cc91dd6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Port the high-dpi icon test to use the new pixmap()
API which takes the target devicePixelRatio as an argument.
This means we can run the fromTheme test at dpr = {1,2,3},
instead of at the current global devicePixelRatio only.
Task-number: QTBUG-85885
Change-Id: Iec7b21e04ed760e48964307d2048eaec1976ffe2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Without an override for logicalDpi() the base class implementation
would use the geometry of the screen to figure out the DPI, and end
up with ~100, which combined with a 96DPI base logical DPI would
give a wrong scale factor.
Change-Id: I68aecce44d2ee672c7b707dfe5444af8f551e961
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Add new QIcon::pixmap() overload:
QPixmap pixmap(const QSize &size, qreal devicePixelRatio, ...)
This function replaces the existing pixmap() function which
take a QWindow pointer, and should be more convenient in use.
Task-number: QTBUG-85885
Change-Id: Ie4ca96a266d9278864678dc61bdfc2836cabdb93
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
Remove QTypeInfo::isStatic, as that's not used anymore in Qt 6.
Also remove sizeOf, it's unused, and we have QMetaType for that if
required.
Remove all typeinfo declaractions for trivial types, as the default
template covers them correctly nowadays.
Finally set up a better default for isPointer, and do some smaller
cleanups all over the place.
Change-Id: I6758ed37dfc701feaaf0ff105cc95e32da9f9c33
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Having three methods with the same name doing different things is
unnecessarily confusing, so follow the standard naming convention in
Qt and call the getter of the resolve mask resolveMask, and the setter
setResolveMask. These methods were all documented as internal.
The publicly documented resolve() method that merges two fonts and
palettes based on the respective masks remains as it is, even though
'merge' would perhaps be a better name.
Change-Id: If90b1ad800834baccd1dbc38fc6b861540d6df6e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
