Declare hidden friends like qdoc expects them, and other signature fixes
Document function parameters
Remove documentation for removed APIs.
Change-Id: I44c1caeed0d40be04612129d074acc30b75f5259
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
QHighDpiScaling now computes scale factors based on
QPlatformScreen::logicalDpi(), instead of by calling
QPlatformScreen::pixelDensity() as done earlier.
We forgot the rename the internal state variables,
update them to indicate that platform screen DPI is
used.
Change-Id: Ib718a6176e0ac138395eea13b292f75f69dac3ad
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In Qt Quick, when we deliver an item-specific QTouchEvent that contains
only the subset of eventpoints that are inside the Item's bounds,
traditionally the Item can accept the event to tell the delivery logic
that the event is handled and doesn't need to be delivered further.
But an Item cannot be expected to have total scene awareness; so now,
the delivery is "done" only when all eventpoints in the original event
are accepted. This behavior has been working well enough already due to
logic in QQuickWindow that iterates the points and accepts them if the
event is accepted; but it seems appropriate to move this enforcement
into QPointerEvent itself. Making setAccepted() virtual gives us a
useful degree of freedom.
Event-handling code should alternatively use QEventPoint:setAccepted()
or QPointerEvent::setExclusiveGrabber() to take resonsibility for only
a subset of the touchpoints.
Another way to put it is that we treat QPointerEvent::setAccepted() as a
convenience method: accepting the QEventPoints is what counts (at least
in Qt Quick).
Change-Id: Icec42dc980f407bb5116f5c0852c051a4521105a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The
QT_BEGIN_NAMESPACE
QT_END_NAMESPACE
block is added to avoid warnings from the build system's sanity
check.
As a drive-by, fix the include guards in the QtGui/QActionGroup header.
Change-Id: Ie10e7830c3b00a3548123f58498def49b194c7aa
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Since a single-point event (such as a QMouseEvent) only carries one
point, it only has one grabber, so we can have a normal Q_PROPERTY.
It's named exclusivePointGrabber to avoid shadowing the
QPointerEvent::[set]exclusiveGrabber functions that take QEventPoint&.
Change-Id: Ie18f1c1849ed057b98f229de7b17b7fc3f3eea36
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Document new conversion functions and how the new
public API (rounding) effects QHighDpiScaling operation.
Change-Id: I801fc065cdb4904811a009510b08cac630b83fe7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(This code is required to handle corner cases such as a QWindow
covering multiple screens, where the normal code path does not
give correct results.)
Move the map[to|from]Global implementation from qhighdpiscaling.cpp,
and implement it in terms of [to|from]NativeGlobalPosition. These
functions implement the required screenAt()-type searching.
The implementation strategy for both mapping functions is to first
map to the native coordinate system, perform the globalPos addition
or subtraction, and then map the result back to device independent
coordinates.
Task-number: QTBUG-81695
Change-Id: I44e9e68651634650964e839b1e564b50f434553f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Keep (requested) geometry and screen in sync, which
is required for correct high-dpi scaling. The platform
plugin can still override with new geometry (and screen),
as usual.
This has previously been fixed/worked around for QDialog,
see QTBUG-52735. That fix can now be removed in favor
of this change in QWindow.
Change-Id: Ieadb1bfee5fb966c5c2052e9daa5ba124a87f3cd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add functions which scales window geometry:
framNativeWindowGeometry()
toNativeWindowGeometry()
These correctly handles top-level and child windows,
where top-level window positions scale around the screen
origin while child window positions scale around (0, 0).
Modify call cites to use the new functions. We no longer
need the isTopLevel checks at the call site.
Change-Id: I0158672d46a3f52dfc7d37d021fc5cebd7859200
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add functions for scaling global coordinates:
toNativeGlobalPosition()
fromNativeGlobalPosition()
These correctly handle the cases where a window spans several
screens.
Change-Id: I268762499cd8d86a3c417342ddaf2fb6dab4dd20
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Implement support for using the screen at a given position
when determining the scale factor and origin.
Add QHighDpiScaling::screenForPosition(), which searches
for a screen at the specified device independent or native
coordinates. The function returns the QScreen or nullptr
if no screen was found.
Add QHighDpiScaling::Point, used for representing
an invalid, device independent, or native point.
Change-Id: I58e4e3eebb8cdd5171e59f97833a00e7f8d9ecd6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Make fromNativePixels() use QWindow:screen() for determining
which screen's scale factor to use, even if the point-to-be-scaled
is on a different screen.
We'll add API for handling the window-on-multiple-screens
case in subsequent commits.
Task-number: QTBUG-81695
Change-Id: Ib9f40a5a636b2487204c14301ad0190727dcf4ac
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The only thing we need to modify at runtime is the typeId and that can
be mutable. This way we can have a constexpr ctor for QMetaType which
hopefully makes the importing and exporting of related symbols less
fickle.
On Windows we cannot make QMetaTypeForType constexpr as that leads to
mysterious errors in other places. Until we figure out why that is, we
just leave this class as non-constexpr.
This reveals that qcoreapplication.h and qvariant.h are using QDebug
without including it. We now get template instantiation errors. Include
qdebug.h to avoid that.
Change-Id: If1bf0437ada52459c59c6fa45bab3d22dfb0bc92
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The namespace and overviews are in the qtdoc repository.
Docs for individual interfaces should live with their platform.
Change-Id: Iba5fd7e9ebc4f1f634ec9dc3ec125ce88a1312ba
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
After detaching, the current QMutableEventPoint obviously doesn't
reference old QMutableEventPointPrivate anymore. Deref it, so that we
do not leak memory.
Change-Id: I3b59667603d41f452eead9a2db13e1d005f622ec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
On some platforms, tablet events do not have a time stamp.
Task-number: QTBUG-46412
Change-Id: I3cc820b1edaaf55511c000fefb805f5a3a7872a6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QEventPoints are equal when all data values are equal, the
refcount is ignored.
Change-Id: I6ef70faf0b12129eaa22bfc1f0a45bab2422d421
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Following 556511f9f3, there is only one
data member in addition to the shared QPalettePrivate, so we don't need
a data struct anymore.
Change-Id: I8d7f33ed042e47464eb5f60a048956f8bf70e0b9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If we're going to limit shortcuts to non-modifiers, we should
at least include all of the modifiers, otherwise we'll end up
passing through e.g. Key_CapsLock.
Change-Id: If11758f85d06f75e9b9c2d2a57d4a4915ff72317
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Only allow actions disabled due not being visible to trigger, when
enabled is not true.
This matches QQuickAction behavior, and doesn't apppear to affect QtGui
or QtWidgets.
Change-Id: I1a00b80213598ef1560be4c9ee9e65cd6fa6d760
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
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>
The convention for these interfaces is to not have 'platform' in
their name.
Change-Id: I4af831861b58dcfc2538d4206788231b9ec3a766
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
In the porting from Qt 4 to Qt 5 an assumption was made in QKeyMapper
that the underlying platform implementation needed the native scan
code to be able to resolve the possible keymaps for an event.
As a result, the macOS platform plugin started sending key events
with a fake native scan code of 1, so that it would still be allowed
to map key events.
Which in turn led to the documentation of QKeyEvent::nativeScanCode()
getting an exception for macOS.
Let's clean up this by removing the original assumption, and leave it
up to the platforms to decide what information from the key event
is needed.
QKeyMapperPrivate::possibleKeys() will still call extractKeyFromEvent
as a fallback if the platform layer doesn't return any possible keys.
Change-Id: I122a45bcec658c45ccc0b2c0671eb264d85d7be6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Try to get rid of APIs that use raw 'const {char, QChar} *, length'
pairs. Instead, use QByteArrayView or QStringView.
As QStringConverter is a new class, simply change the API to what we'd like
to have. Also adjust hidden API in QStringBuilder and friends.
Change-Id: I897d47f63a7b965f5574a1e51da64147f9e981f6
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
List primary and alternative key sequences and ids together, making the
logic cleaner.
Change-Id: I4eb07f9828f2b15dc66c34ceb2c4f800df73e800
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use the default logicalDpi() implementation, which now
returns logicalBaseDpi() and ensures a default device
pixel ratio of 1.
Change-Id: Idd408261c90b112a093c82695ff9e0078e90ac41
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This function is no longer in use - Qt Gui now computes
scale factors based on logicalDpi() and logicalBaseDpi()
instead.
Change-Id: Ieb4b75ef4e1563694a8e12b7cdd1f60c419d5bf2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Remove the code which calculates physical DPI and
call logicalBaseDpi() instead.
This will make sure that Qt gets a device pixel ratio
of 1.0 by default, for the cases where the platform
plugin does not implement logicalDpi() itself.
Task-number: QTBUG-87035
Change-Id: I08433c9465be03d27b3decccb0e2e7e5e6aff0ae
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
At the moment we have two main strategies for dealing with move
assignment in Qt:
1) move-and-swap, used by "containers" (in the broad sense): containers,
but also smart pointers and similar classes that can hold user-defined
types;
2) pure swap, used by containers that hold only memory (e.g. QString,
QByteArray, ...) as well as most implicitly shared datatypes.
Given the fact that a move assignment operator's code is just
boilerplate (whether it's move-and-swap or pure swap), provide two
_strictly internal_ macros to help write them, and apply the macros
across corelib and gui, porting away from the hand-rolled
implementations.
The rule of thumb when porting to the new macros is:
* Try to stick to the existing code behavior, unless broken
* if changing, then follow this checklist:
* if the class does not have a move constructor => pure swap
(but consider ADDING a move constructor, if possible!)
* if the class does have a move constructor, try to follow the
criteria above, namely:
* if the class holds only memory, pure swap;
* if the class may hold anything else but memory (file handles,
etc.), then move and swap.
Noteworthy details:
* some operators planned to be removed in Qt 6 were not ported;
* as drive-by, some move constructors were simplified to be using
qExchange(); others were outright broken and got fixed;
* some contained some more interesting code and were not touched.
Change-Id: Idaab3489247dcbabb6df3fa1e5286b69e1d372e9
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
A NaN value in globalPos can cause an endless recursion in
QGuiApplicationPrivate::processMouseEvent() when e->enhancedMouseEvent()
is true and this is not a move event.
When an event contains a NaN in globalPos, print a warning and ignore
the event.
Pick-to: 5.15
Fixes: QTBUG-86207
Change-Id: I8789e465921789569715e52c98193f91945ea982
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
The sequence is still press, release, press, double-click, release.
isBeginEvent() should not be true for a double-click event: the second
click began with a normal MouseButtonPress, and the MouseButtonDblClick
event is a way of sending updated state to tell the recipient that the
second click was special, occurring within such spatial and temporal
constraints that it can be interpreted as a double-click.
It never has a different position either, because MouseButtonDblClick
is a synthetic event occurring at the same position as the second press;
so we might as well say its QEventPoint is Stationary.
Together, these changes fix tst_controls::Basic::DelayButton::test_mouse
in Controls 2, without any changes in qtdeclarative.
In QQuickWindowPrivate::deliverPointerEvent(), if isBeginEvent() == true,
it delivers to all items under the point position(s) first, and then if
all _updated_ points were not accepted, it continues delivery to grabbers;
whereas if isBeginEvent() == false, it delivers only to grabbers.
isBeginEvent() and QEventPoint::state() are important to that algorithm.
Amends 6d6ed64d6c
Task-number: QTBUG-87018
Change-Id: I95def9704652147540df5cc065354a0fe04ed626
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
None of this code is even compiled in qt6.
Change-Id: I5891cc9459320083ad3908fcbf646f3ba75b8a4d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add the missing call to QScreenPrivate::emitGeometryChangeSignals()
along with an emission of physicalDotsPerInchChanged()
since that is calculated from geometry and physical size.
Rearrange the code in
QGuiApplicationPrivate::processScreenGeometryChange()
to prevent duplicate emissions of geometryChanged(),
physicalDotsPerInchChanged() which this change would introduce.
Amends 5290027e3b.
Pick-to: 5.15
Task-number: QTBUG-76902
Task-number: QTBUG-79248
Fixes: QTBUG-86604
Change-Id: I3dc2ec5ccd9c6413e92f9246242f323e8afc5e57
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Deprecated from 6.0, but necessary for migration.
Change-Id: Idb1264e6ecca9400086970c15270b803c8fd391b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
XDG_SESSION_TYPE is a non-standard part of systemd, and not set if you
run a compositor from the command line, for instance.
[ChangeLog][Wayland] XDG_SESSION_TYPE is no longer used to determine which
platform plugin to use. Instead, if WAYLAND_DISPLAY is set in the environment,
wayland is used. Similarly, if DISPLAY is set, xcb is used. If both are
detected, wayland will be attempted first, then xcb.
Gnome-shell is still skipped for automatic wayland detection.
Fixes: QTBUG-75732
Change-Id: Ieed123330662dc29eafa31148a9b99ba0810de90
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
It was already used many places directly making the code inconsistent.
Change-Id: I3b14bc6c333640fb3ba33c71eba97e78c973e44b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Omitting stationary points from touch events is such a marginal
optimization that this code probably isn't worth maintaining.
It wasn't implemented correctly this time either, according to the
tst_QQuickMultiPointTouchArea::stationaryTouchWithChangingPressure()
test.
[ChangeLog][QtGui][QPointerEvent] We no longer attempt to avoid
delivery of stationary points within QTouchEvent: every pressed point
is now included in every TouchUpdate event.
Task-number: QTBUG-77142
Change-Id: If1fd666fb3057a17e0dffdd7ca7138693126b02b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
As drive-by, fix qdoc warning in related internal documentation.
Change-Id: I7716a9b126e38e99dcd11c6af2e91b8ec7bf4346
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
Qt Quick Pointer Handlers depend on this behavior:
QQuickPointerHandler::onGrabChanged() receives only the grabber that
was losing the grab or the one that is receiving it, not both at the
same time. UngrabExclusive means the original grabber simply
relinquished the grab by setting the exclusive grabber to null.
CancelGrabExclusive means the new grabber took over the grab that the
old grabber had before.
Task-number: QTBUG-86729
Change-Id: Iefca6fe91b11fcb03d2c6ac3598841c924facb22
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
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>
...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>
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>
They are redundant, not in use, and got added without implementation in
a81859a3c8.
Change-Id: Ifed1fbf97a8158c2801df09dac47bf1fc90795d4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If we have a platform plugin we ask the platform to quit, and if
not we fall back to the base implementation of QCoreApplication
that sends Quit events directly.
This allows the platform to involve the rest of the system in the
process. The platform will then come back with a spontaneous quit
via QWSI::handleApplicationTermination(), which will then send
the corresponding Quit even from QGuiApplication like normal.
Task-number: QTBUG-45262
Task-number: QTBUG-33235
Task-number: QTBUG-72013
Task-number: QTBUG-59782
Change-Id: I0000aaf7192e4b905933c5da0e53901c6c88f26a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Document the new base classes QPointerEvent and QSinglePointEvent,
and move relevant documentation to be located under them.
* Replace linking to deprecated functions with their new counterparts.
* Remove non-existent function and parameter documentation.
* Document QEventPoint::State enum.
* Prefer \obsolete over \deprecated and fix the usage.
* Document the Capabilities enum in the correct location and
add docs for the missing enum values.
Change-Id: Ic8f2732f2e90ecbf522cd744c601cedcc574825c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We plan to move storage of the grabbers into QPointingDevice so that
QEventPoint will store only data that does not need to persist between
deliveries of individual events. These API changes prepare for that.
addPassiveGrabber/removePassiveGrabber is a better API than
setPassiveGrabbers(), because it will never require constructing a
temporary QList just to call the function. Eventually we need to emit
signals to notify about grab changes, so it's better to have incremental
changes to the list rather than needing to iterate and find differences.
Fix up the docs.
QEventPoint IDs are no longer written in hex in debug output.
That was done in Qt 5 because an ID was a composite of device ID
with the OS-provided touchpoint ID; but since the QPointingDevice
is always available, it's more readable if the IDs are in decimal.
Change-Id: I86b9016d9b28c331ca05c7c108d9788de93fb642
Reviewed-by: Lars Knoll <lars.knoll@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>
... and the equivalent enum in QPlatformDialogHelper.
No need to keep numerical values the same anymore.
Remove ### Qt 6 comment.
Change-Id: Ib369ea6ca2362f6ab0f71a3a6c90c4adaa7f11cd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
QT_DEVICE_PIXEL_RATIO is replaced by QT_SCALE_FACTOR, while
QT_AUTO_SCREEN_SCALE_FACTOR is replaced by QT_ENABLE_HIGHDPI_SCALING.
Since High-DPI is now always enabled, there's no reason to keep the
code path for android.app.auto_screen_scale_factor. Also, based on
the original commit message that introduced this code, the value of
the property should have been true.
Change-Id: Ib34b1deeab46c488c67c4d64f087599b4a54dc55
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
As the private headers are not included by default in the precompiled
header QDoc builds for QtGui, create a custom module header for
the documentation build and pull in the required headers.
Add dummy declarations for Windows-specific types for building docs
on non-Windows platforms.
Task-number: QTBUG-83252
Change-Id: I225ed08f68cf4f7c1f1d093424070b13ce36aa51
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
With the Qt6 compatibility break, it can finally be removed.
Closing windows (which might quit the application with
quitOnLastWindowClosed() true, the default) acted contrary to the
documentation of the commitDataRequest() signal, which could have
been a hint.
This removes the workaround API from the fix for QTBUG-49667 and
also removes the problematic feature that it worked around.
Change-Id: I672be58864ef062df7fb7f2a81658b92c4feedd2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
droparea.h has been removed. Remove all code that depends on that header
except the one snippet that is still used. Add minimal code to allow
the snippet to be compiled.
Done-with: Nico Vertriest <nico.vertriest@qt.io>
Task-number: QTBUG-81486
Change-Id: I58c80d3527c82389ccff97567f4c75c33aec0f5e
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
This attribute is now on by default.
Change-Id: I7c9d2e3445d204d3450758673048d514bc9c850c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Set HighDpiScaleFactorRoundingPolicy to PassThough
by default. This makes Qt track the system UI setting
accurately, and is overall the least confusing option.
Historically, Qt has rounded the scale factor (for example,
Windows 175% -> DPR 2) due to faulty handling of fractional
scale factors in Qt Widgets and with the native Windows
style.
Other areas of Qt such as Qt Quick have had few issues
with fractional scale factors and support this well.
Qt has never rounded the scale factor on the Android
platform.
Support for fractional scale factors in Qt Widgets and
the windows style has improved, which makes changing
the default for Qt 6 viable.
Task-number: QTBUG-83068
Change-Id: I38b60f621f95be8ebb6cb84a07d3370fec19ab92
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Enable high-DPI support for all platforms which use
QHighDpiScaling. This changes the default behavior
of Qt applications on X11, Windows, and Android.
Qt::AA_EnableHighDpiScaling is now effectively on by
default, and Qt 6 applications do not have to set
this application attribute. Opting out is possible by
setting the Qt::AA_DisableHighDpiScaling attribute.
Task-number: QTBUG-83068
Change-Id: Ia2bd3e6f490130afcacd3a951bc50dbb40a79d7f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Drop deprecation warnings for now-dropped items
* Use the 'qt6' define and a new \nothing doc macro to conditionally
document items on Qt 6
* Add a custom module header for docs that pulls in also Vulkan headers
* Add \internal command for internal classes/functions
* Move QtGUI-related code snippets from widgets to gui docs
Change-Id: Ieb386b96631a49568d09059906d307c45c01d93a
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
This follows the work done in 6ff79478a4.
The API is available by including qoffscreensurface.h, scoped in
the QPlatformInterface namespace. The namespace
exposes platform specific type-safe interfaces that provide:
a) Factory functions for adopting native contexts, e.g.
QAndroidPlatformOffscreenSurface::fromNative(ANativeWindow);
b) Access to underlying native handles, e.g.
surface->platformInterface<QAndroidPlatformOffscreenSurface>()
->nativeSurface()
Fixes: QTBUG-85874
Change-Id: I29c459866e0355a52320d5d473e8b147e050acb3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
With 64bits, the mask is exhausted with the 21 colors x 3 color groups
we have right now.
In order to support accent colors, we need more palette entries. By
moving the mask into the d-pointer, we can extend QPalette within
the Qt 6 series, without breaking binary compatibility.
The resolveMask/setResolveMask methods that take integers are
documented as internals, so we can change those signatures after
Qt 6.0 as well.
As a side effect, setting the resolve mask on a QPalette detaches now.
Setting a mask is in most cases done on the result of
QPalette::resolve, which is usually detached already. And the QPalette
default constructor will have to detach from the global application
palette if that palette has any colors set explicitly.
Task-number: QTBUG-82925
Change-Id: I1e70f1c4d0dd98303e353b91df5dba2b1fe8ba01
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
This is a z coordinate unrelated to tilt, AFAIK.
Amends ea2ae140e9
Change-Id: If165df3af290fbe7c2e5bfa94d578175debd53cd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
This makes high-level event dispatching easier: for example in Qt Quick,
all pointer events should eventually be delivered to items in a similar way.
Implemented in a similar way as d1111632e2.
Change-Id: I2f0c4914bab228162f3b932dda8a88051ec2a4d7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
event()->device() was the most common use case anyway.
The idea that the "parent" of a QEventPoint is the QPointerEvent
interferes with the ability to copy and move event objects: the parent
pointers are dangling unless we use the QPointerEvent subclass
destructors to set the points' parents to null. Since there is no move
constructor, even returning a QEventPoint from a function by value
results in destroying the temporary instance and copying it to the
caller's space. So the parent pointer is often useless, unless we do
even more work to maintain it when the event moves.
If we optimize to avoid copying QEventPoints too much (and perhaps
enable exposing _mutable_ points to QML) by storing reusable instances in
QPointingDevice (which is the current plan), then the actual parent will
no longer be the event. Events are usually stack-allocated, thus
temporary and intended to be movable.
Change-Id: I24b648dcc046fc79d2401c781f1fda6cb00f47b0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This helps get better symmetry with the other modules,
and to unify the code paths for both conversion and
retrieving the interface for static types.
Change-Id: Icbd20de2563f36e3de20d826323acd057734abfb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move the type conversions from QVariant::Helper to QMetaType. Only do
this for Qt Gui in a first step.
This makes it possible to completely remove the Handler struct in
QVariant, and now allows QMetaType to also convert Gui types.
Moving the conversion of Core types into QMetaType will require
further work.
Change-Id: I061f789deca1b595d92bb29227eb54b8e71a3ee3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
That parameter is duplicating the return value, get rid of it.
Change-Id: I8d6ecee8aca90aecaf08e6d0072d83e9a08ce3d6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This code is now unused, as streaming operators are
registered automatically.
Change-Id: I0e48944c33a92cf1f2f158fb2dc0ca49256d7938
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the builtin support in QMetaType instead.
Change-Id: Ifc0e88719a384aa7fb525652bada22b6f7ee1c45
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We actually do not need this "mode" in qwsi API. I think while
writing the patch from 00ae1e6b7b I got confused by focusing
on my test application. We can't know what the native event
filter will filter out, therefore it makes sense that we
unconditionally do filtering at qwsi level as well for user input
vs other events in QWindowSystemInterface::sendWindowSystemEvents().
Pick-to: 5.15
Pick-to: 5.12
Change-Id: Idb23152a24bf3ba3b91804427a6e78f991969c29
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
MidButton had its // ### Qt 5: remove me
upgraded to Qt 6 at 5.0; but it dates back to 4.7.0
Replace the many remaining uses of MidButton with MiddleButton in the
process.
Pick-to: 5.15
Change-Id: Idc1b1b1816673dfdb344d703d101febc823a76ff
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QtQuickTest synthetized events can have modifiers, but those modifiers
were not accessible globally, from QGuiApplication::keyboardModifiers
for instance.
eg. calling QML's TestCase::mouseClick with modifiers triggering a call
to QGuiApplication::keyboardModifiers did not give the expected result.
QtTest synthesised events can also have modifiers and those were
correctly handled by QApplication to set modifiers globally.
This fix moves the handling code from QApplication::notify to
QGuiApplicationPrivate::maybeSimulateModifiers and calls this function
from QGuiApplication::notify too.
The definite fix would be to do as suggested in the comment attached to
the moved code:
> Qt Test should not call qapp->notify(), but rather route the events
> through the proper QPA interface. This is required to properly
> generate all other events such as enter/leave etc.
Pick-to: 5.15 5.12
Change-Id: I734e5bbc82232b13828b1a1f82e06ee8eb695417
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Make sure Qt reacts correctly to DPI changes while the
application is running, also when going from “standard-dpi”
to “high-dpi” (like Windows 100% to 200%).
Call QHighDpiScaling::upateHighDpiScaling() on DPI
change and update the m_usePixelDensity flag from there.
Fixes: QTBUG-85384
Pick-to: 5.15
Change-Id: I8ca83e4eea76cc8ba701a18e1f8c535b9953918f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Setting the QT_USE_PHYSICAL_DPI environment variable
will make Qt use physical DPI when determining the
screen scale factor, instead of logical DPI.
However, the code was using QScreen::physicalDotsPerInch(),
Whose return value is itself scaled by the device
pixel ratio. (See QTBUG-62649 for further discussion).
Use QPlatformScreen API instead and calculate the DPI
based on geometry() and physicalSize().
Pick-to: 5.15
Change-Id: Ifa29065c447b0d3431e0f14aacb5aafce61051c2
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
It is only broken in C++11/c++14 mode.
We do need to fix the order of visibility-attributes and this
C++ attribute.
Change-Id: I41e4367f1aaa9241fec4e336c39e58b798336b2c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This makes it easier to reliably maintain input-event related states
in widgets, in particluar the state of keyboard modifiers. Instead of
testing for all possible event types, code can just test the flag before
safely static_cast'ing to QInputEvent to access the modifiers.
Simplify the code in QAbstractItemView accordingly.
Task-number: QTBUG-73829
Change-Id: Idc7c08e2f3f1e8844f5c6693c195153038ee6490
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QPixmap doesn't implement operator==, but QCursor had a non-explicit
constructor from a QPixmap, which the compiler would use if two pixmaps
get compared.
Making that QCursor constructor explicit prevents that implicit
conversion, at the cost of potential (but trivially resolved) source
incompatibility.
Also, make QCursor's comparison operators into hidden friends to avoid
any other implicit conversions, and allow only QCursor object to be
compared.
In addition, delete operator== and operator!= in QPixmap so that the
compiler generates a useful error message, rather than a screen full
of global operator== candidates.
Delete these operators in QIcon as well for consistency.
Change-Id: I9b3f770da5718360ecc41c35cf327ef4f60d169b
Fixes: QTBUG-85993
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
It was marked internal anyway. Use the constructor taking a
QMetaType instead.
Change-Id: I15b9cd0911aac063a0f0fe0352fa2c84b7f7c691
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Both normal and relaxed constexpr are required by our new minimum of
C++17.
Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
isNull() would forward to the contained type and check that type's
isNull() method for some of the builtin types. Remove that behavior
and only return true in isNull(), if the variant is invalid, doesn't
contain data or contains a null pointer.
In addition, implement more consistent behavior when constructing
a QVariant using the internal API taking a copy from a void *.
isNull() should return true in both cases. This mainly changes behavior
for some corner cases and when using our internal API.
[ChangeLog][Important Behavior Changes] QVariant::isNull()
no longer returns true when the variant contains an object of some
type with an isNull() method, that returns true for the object;
QVariant::isNull() now only returns true when the variant contains
no object or a null pointer.
Change-Id: I3125041c4f8f8618a04aa375aa0a56b19c02dcf5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Remove the compare method in the QVariant::Handler struct. Rely
on the generic support provided by QMetaType instead.
[ChangeLog][Important Behavior Changes][QVariant] QVariant will now use builtin support in
QMetaType to compare its content. This implies a behavioral change
for some graphical types like QPixmap, QImage and QIcon that will
never compare equal in Qt 6 (as they do not have a comparison
operator).
Change-Id: I30a6e7116c89124d11ed9052537cecc23f78116e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add the logging category qt.pointer.grab, which generalizes the
qt.quick.pointer.grab category in Qt 5 (and is almost always needed
for troubleshooting Qt Quick pointer-handling bugs).
Change-Id: I10b4f43aa60e8717d92ac43384d8fdeefd41d836
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QQuickPointerEvent had them, so despite how trivial they look,
it's very convenient to keep using them in QQuickWindow rather than
duplicating these kinds of checks in various places, and for multiple
event types too.
Change-Id: I32ad8110fd2361e69de50a679ddbdb2a2db7ecee
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
There was no good reason for QEventPoint::pressTimestamp() to be
missing. The case for QEventPoint::timestamp() is a bit dubious
because it's redundant with QInputEvent::timestamp(); but for now,
we keep m_timestamp, in anticipation that Qt Quick may need to keep
copies of eventpoints between events, thus they need to avoid depending
on their shorter-lived parent events too much.
Change-Id: Iec38acfdfaa2afb3dc77d5cd1b95baa8d301c0fd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Just T makes qdoc's clang parsing fail, it needs template<typename T>.
Also, the return type is T*, not T.
Change-Id: I210676aff3122b432888c3d79d9967e249ac88e1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The error was:
src\virtualkeyboard\qvirtualkeyboardinputcontext_p.cpp(305): error C2678:
binary '!=': no operator found which takes a left-hand operand of type
'QList<QInputMethodEvent::Attribute>' (or there is no acceptable conversion)
This patch fixes the issue by manually defining an operator== for
QInputMethodEvent::Attribute.
Change-Id: Idb283cf7b6ff4388a38ea7780c3d5c1c5f77038d
Fixes: QTBUG-85789
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move createMessageWindow(), the GPU detection for qtdiag and the async
expose setting (used by Active Qt) from QWindowsNativeInterface to
QWindowsApplication.
Remove unused registerWindowClass() and use logFontToQFont() directly from
the font database.
Task-number: QTBUG-83252
Change-Id: I9c72351970b47457d08125557c2580016c66e586
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Move QWindowsMime (which was a public class in Qt 4 and moved to the QPA
plugin in Qt 5) to the platform namespace and add register functions to the
native application.
Move in test code from QtWinExtras.
Task-number: QTBUG-83252
Change-Id: Iaac440e2d5cb370110919921b1eeb779600b5b65
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Move options to new interface, making them settable from
code on this occasion.
Task-number: QTBUG-83252
Change-Id: Idd80667c502a8cde5d7c66d7e597ea34c22738e7
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Given some decimal scaling, the clipping of the QRegion/QRect passed to the QRegion/QRect done inside paintEvent cannot handle the decimal scaling.
Solved by only converting QRect to a certain QRectF and calling QRectF overload instead of QRect.
Fixes: QTBUG-82601
Fixes: QTBUG-64854
Pick-to: 5.15
Change-Id: I0d8f4193aabfc0d917612db68d2a39ebb726fa2f
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Affects the custom margin used by QWizard.
Task-number: QTBUG-83252
Change-Id: Iffda043f106282f682e119ec955fa2b2eb0f259e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change TouchWindowTouchType(s) to be (global) property of
QGuiApplication's native Windows interface since it does not make
sense to set it per window.
It appears the previous code setting the types per Window has never
worked since registerTouchWindow() bailed out due to the checks for
the flags TouchRegistered and IsTouchWindow() (setting in
HCBT_CREATEWND). In addition, registering windows for touch after
plugging in a device would not observe the setting.
Move the checks around to make this work.
Task-number: QTBUG-41433
Task-number: QTBUG-48849
Task-number: QTBUG-83252
Change-Id: I4306fdf13208f6eef22655875f3bd1769270e617
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
After the QVector->QList rename it made no sense.
Change-Id: I4a422f48b1f5d42c1c4d402ea947a0f4098172b7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
On Windows, and possibly other platforms, a touchpad can send a mouse
button press followed by an unexpected mouse move event to the same
coordinates, before sending a mouse button release, which may confuse
applications. Before the enhanced mouse event processing was added, the
code in QGuiApplication was responsible for deducing the mouse event
type and other info, and in the process performed a checking that
discarded events that did not change state. The enhanced mouse
processing code lacked this checking. This change adds an equivalent
checking to the enhanced mouse event processing.
Fixes: QTBUG-85431
Pick-to: 5.15
Change-Id: Ie3e2ae8cbf9870d465dfd2c8808942dd6fc647d2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Implement the static parts of QWindowsWindowFunctions.
Move some things around and make them static in tablet support
to make this easier.
Task-number: QTBUG-83252
Change-Id: I24c3b0b3c6548eb96c4f3285a4e46385a1e79ef5
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Before 0a93db4d82 we would polish the
application palette even when it was the default palette, as we
always recreated the system palette each time a style was set.
After the change we skipped polishing the palette unless it was set
by the user, under the assumption that the style would set its
own default palette if it wanted to override the system palette.
This turned out to break the style's ability to slightly tweak the
palette via polish (versus the more full on standardPalette approach).
We now polish both the default palette and user palettes, and we do
so as part of the normal palette update logic. This ensures that
the style also gets a chance to polish the palette when the platform
theme changes.
The polish will not have an effect on the resolve mask of the palette,
as the polish is conceptually the same as a base palette, and should
not affect e.g. Qt::AA_SetPalette.
Fixes: QTBUG-85469
Fixes: QTBUG-85188
Pick-to: 5.15
Change-Id: I869e9c442b177de4f1dc49eb75220709306f4d12
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
src/corelib/text/qstringconverter.h:160:54: error: no matching constructor for initialization of 'QStringConverterBase::State'
src/corelib/text/qstringconverter.h:72:19: note: candidate constructor not viable: no known conversion from 'QFlags<QStringConverter::Flag>' to 'QFlags<QStringConverterBase::Flag>' for 1st argument
src/corelib/text/qstringconverter.h:75:9: note: candidate constructor not viable: no known conversion from 'QStringConverter::Flags' (aka 'QFlags<QStringConverter::Flag>') to 'QStringConverterBase::State' for 1st argument
src/corelib/text/qstringconverter.h:108:24: note: candidate constructor not viable: no known conversion from 'QStringConverter::Flags' (aka 'QFlags<QStringConverter::Flag>') to 'const QStringConverterBase::State' for 1st argument
src/corelib/text/qstringconverter.h:159:32: warning: constexpr constructor that does not initialize all members is a C++20 extension [-Wc++20-extensions]
src/corelib/text/qstringconverter.h:187:11: note: member not initialized by constructor
src/corelib/kernel/qproperty.h:403:14: error: deduction guide must be declared in the same scope as template 'QProperty'
src/corelib/kernel/qproperty.h:202:7: note: template is declared here
src/corelib/kernel/qproperty.h:403:14: error: deduction guide declaration without trailing return type
src/gui/painting/qregion.h:139:5: error: unknown type name 'HRGN'
src/gui/painting/qregion.h:140:29: error: unknown type name 'HRGN'
Change-Id: I3c195a60ceeb51664368a4aeef90c70c31954fc3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
They should not clutter the "public" QPA headers that clients
use to implement new platforms, and having them in the private
headers allows us to check for private configure features.
Change-Id: Ib4b4db96c086d81bb5810392c7c8922fc5b4950d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
As they are protected, they need to be excluded from the Python
bindings, which is best done by a pattern.
Task-number: PYSIDE-1339
Task-number: PYSIDE-904
Change-Id: I667aa3b8e229e11b3b46635adfddbd62ce4747c1
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
On one hand it looks like API clutter: a whole Qt namespace enum just
to track whether an individual mouse click is about to geenerate a
MouseButtonDblClick event. On the other hand, we should not remove it
without replacing it somehow, so that users don't lose the workaround for
QTBUG-25831 that it provides. That would be an invasive change because
this flags property exists in QMouseEvent, QGraphicsSceneMouseEvent
and in MouseArea { onClicked: doSomethingWith(mouse.flags) }
Reverts a small part of 4e400369c0
Task-number: QTBUG-25831
Change-Id: I9a3b4f6cc6b858012186f10ed57689f8c0f5fd79
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
State was Unknown by default, and that is OK in widgets so far, because
widgets pay attention to the event type, not QEventPoint::state().
But Qt Quick cares about that, because QEventPoint turns into
QQuickEventPoint, in which state() has long been important, due to
the semi-unified handling of mouse and touch events.
If it was not a button that caused the event, state is Updated (the
mouse is hovering or dragging, or it's an enter event, wheel event etc.)
If more buttons are now held than before, state is Pressed.
If fewer buttons are now held than before, state is Released.
Amends 4e400369c0
Change-Id: I926d268982449e46e7ca713c4a6ee2014c28c645
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Qt Quick's MultiPointTouchArea compares the delta since press against
the drag threshold to determine whether a gesture has started, for
example. Since it can be configured to handle both mouse and touch,
this needs to be done for mouse events in a similar way as it's done
in QGuiApplicationPrivate::processTouchEvent().
Storing one global cursor position is not OK for multi-mouse support,
but that's a problem for another time; so we keep using
QGuiApplicationPrivate::lastCursorPosition for now.
Amends 4e400369c0
Change-Id: I242565c4548878878a67074877468e5fde84a490
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Change the functions to operate in float and add the
QPoint versions as overload calling them. This is
more in-line with the event accessors using float
and allows for removing some workarounds using a delta when
converting touch points.
Leave QPlatformWindow::map(To/From)Global() as is
for now and add helpers for float.
Change-Id: I2d46b8dbda8adff26539e358074b55073dc80b6f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Some goals that have hopefully been achieved are:
- make QPointerEvent and QEventPoint resemble their Qt Quick
counterparts to such an extent that we can remove those wrappers
and go back to delivering the original events in Qt Quick
- make QEventPoint much smaller than QTouchEvent::TouchPoint, with no pimpl
- remove most public setters
- reduce the usage of complex constructors that take many arguments
- don't repeat ourselves: move accessors and storage upwards
rather than having redundant ones in subclasses
- standardize the set of accessors in QPointerEvent
- maintain source compatibility as much as possible: do not require
modifying event-handling code in any QWidget subclass
To avoid public setters we now introduce a few QMutable* subclasses.
This is a bit like the Builder pattern except that it doesn't involve
constructing a separate disposable object: the main event type can be
cast to the mutable type at any time to enable modifications, iff the
code is linked with gui-private. Therefore event classes can have
less-"complete" constructors, because internal Qt code can use setters
the same way it could use the ones in QTouchEvent before; and the event
classes don't need many friends. Even some read-accessors can be kept
private unless we are sure we want to expose them.
Task-number: QTBUG-46266
Fixes: QTBUG-72173
Change-Id: I740e4e40165b7bc41223d38b200bbc2b403e07b6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The plumbing from QKeyMapper to the platform specific key mappers
via QPA was never done, so this method is unused. The code path
in QKeyMapper that would trigger it would be changeKeyboard(),
but that's already handled in QCocoaKeyMapper, and wouldn't be
initiated from the cross platform code in any case.
Change-Id: Ibc0c419627fc0430d028945038c1f2fbafe42d4b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Volker Hilsheimer
Morten Johan Sørvig
Shawn Rutledge
Ulf Hermann
Tor Arne Vestbø
Fabian Kosmale
Friedemann Kleint
Giuseppe D'Angelo
Lars Knoll
Allan Sandfeld Jensen
Steffen Kieß
Johan Klokkhammer Helsing
Alexander Volkov
Eskil Abrahamsen Blomfeldt
Topi Reinio
Marcel Krems
Tasuku Suzuki
Andreas Hartmetz
Paul Wicking
Assam Boudjelthia
Karsten Heimrich
Gatis Paeglis
Edward Welbourne
Nicolas Guichard
Michal Klocek
Laszlo Agocs
Mitch Curtis
Tang HaiXiang
Andre de la Rocha