| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Change-Id: I1a8ae38121b3a9880ac67f80133df3c15b9951c9
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The protocol is used by services that interact with content in the
application on behalf of the user.
So far we have only been able to deal with plain text content,
which resulted in wiping any formatting if the user tried to
use a service to rewrite text in a rich text document.
We now support rich text, by teaching our IM protocol how to
deal with rich text for both reporting of the current text
selection, as well as text insertion (commit).
Unfortunately this doesn't help us for Writing Tools, as in
15.2 it no longer uses the NSServicesMenuRequestor protocol
for insertion if we also implement NSTextInputClient. As
a result we get insertions via insertText:replacementRange:,
which is not prepared for rich text yet.
[ChangeLog][macOS] Text services via the Services menu now
support rich text extraction and insertion.
Task-number: QTBUG-126238
Change-Id: I3d2933d766af8fe29e4f17636f703a257bf389fd
Reviewed-by: Richard Moe Gustavsen <[email protected]>
|
|
|
|
|
|
|
|
| |
Also, use a consistent syntax for when the pointer is null.
Fixes: QTBUG-135856
Change-Id: I2f5c80a5650b1be6cc0d70cde7cd1e1c1990df9a
Reviewed-by: Christian Ehrlicher <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
...and across Qt Quick and Widgets, and somewhat from a usability
perspective.
Pick-to: 6.9
Task-number: QTBUG-67331
Task-number: QTBUG-93486
Change-Id: I75085f3a7a8e76c3e67ff5864600324faf262a76
Reviewed-by: Mitch Curtis <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logging category now silences QtWarningMsg and below by
default, so we can be more granular in our logging.
Use info logging category for registering/unregistering, to allow
filtering out the detailed debug logging while still seeing when
devices are registered/unregistered.
Log the number of buttons for pointing devices, if there are any.
Log the device for wheel events.
Pick-to: 6.8
Change-Id: Ie046fee1659fc3967caf7eafbaf46f3ed22be5bb
Reviewed-by: Shawn Rutledge <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Avoid casting an event to a type it does not have. Instead use a static accessor class.
Pick-to: 6.8
Task-number: QTBUG-99563
Change-Id: Ideb11779b1510cd10a27fb8bc40bcc8e4849bf15
Reviewed-by: Marc Mutz <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
It's sometimes useful. QEventPoint debug output includes the timestamp;
but for ordinary mouse events, we're often focused on the event itself
rather than its eventpoint.
Pick-to: 6.8
Change-Id: Ib65922331c8601bbed5aea3ea96c820906c89ef2
Reviewed-by: Liang Qi <[email protected]>
|
|
|
|
|
|
|
|
| |
Amends 111115bf8862b7cd1197c2ef8a4b475c882776d4
Change-Id: Ibc557fdde9c894a3a58bb58835e11be9180e6e6d
Pick-to: 6.2 6.5 6.7
Reviewed-by: Paul Olav Tvete <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a QWindow is parented into another window, either via its constructor,
or via setParent(), we also update the QObject parent of the window. This
in turn sends ChildAdded and ChildRemoved events to the new and old parent
of the window, as well as ParentAboutToChange and ParentChange to the window
itself.
But at the point when these events are sent, the QWindow parent relationship
has not been fully established. We have not updated d->parentWindow, nor
have we propagated the parent relationship to the platform window.
This is problematic because clients can not use these events to react to
window parent changes synchronously. For example. trying to raise a child
window when added to a parent is not going to work, because at that point
the child window isn't a native child of the parent.
Instead of re-using the QObject events for QWindow, like QWidget does,
by delaying the events or sending them manually at a point when the
window parent relationship has been fully formed, we opt to add new
dedicated events.
Change-Id: I019c14eba444861f537e4f68ab3a82297f843cf7
Reviewed-by: Volker Hilsheimer <[email protected]>
Reviewed-by: Qt CI Bot <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All these TUs relied on transitive includes of qpointer.h, maybe to a
large extent via qevent.h, though, given that qevent.h is more or less
the only public QtBase header that includes qpointer.h, something else
seems to be at play here.
Said qevent.h actually needs QPointer in-name-only, so a forward
declaration would suffice. Prepare for qevent.h dropping the include.
The algorithm I used was:
If the TU mentions 'passiveGrabbers', the name of the QEvent function
that returns QPointers, and the TU doesn't have qpointer.h included
explicitly, include it. That may produce False Positives, but better
safe than sorry. Otherwise, in src/, add an include to all source and
header files which mention QPointer. Exception: if foo.h of a foo.cpp
already includes it, don't include again.
Task-number: QTBUG-117670
Change-Id: I3321cccdb41ce0ba6d8a709cea92427aba398254
Reviewed-by: Fabian Kosmale <[email protected]>
|
|
|
|
|
|
|
| |
Sometimes it's useful to know the scan code and virtual key as well.
Change-Id: Ic120189470a9ff44a5cb7f6dcc1405654136424f
Reviewed-by: Timur Pocheptsov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With 6e77da640aa84c1efe330d4a5224c9c7425ece57, the documentviewer
demo's TxtViewer plugin has been fully documented in order to replace
the Application example.
This patch moves the application example to manual tests.
Pick-to: 6.5
Change-Id: I67d975e478c7bc840613c8af1301a4eafe8f1a42
Reviewed-by: Qt CI Bot <[email protected]>
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
| |
By using an iterator-based for loop.
Change-Id: I9ae12f16bc2a5c2d74c8557a0324438102fec5b1
Reviewed-by: Giuseppe D'Angelo <[email protected]>
Reviewed-by: Thiago Macieira <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Amends 76c63936d3d3c937960108da88a56394a0ac70b5 by adjusting the test case.
We still just test that we can open a file based on a filename that we came
up with ourselves.
Also, update usage documentation and make the snippet a bit more relevant.
Change-Id: I5bf00210d74e2a73d5a71a09a5beb1b3f6f8e225
Reviewed-by: Axel Spoerl <[email protected]>
Reviewed-by: Tor Arne Vestbø <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the string we receive from the system doesn't parse into a valid
QUrl (because QUrl requires a valid IDN), then we shouldn't send the
QFileOpenEvent based on that invalid QUrl, but instead pass the string
through as the file name.
The file name is anyway not guaranteed to be path to a file that can be
opened, as per the existence of QFileOpenEvent::open and the repective
documentation stating:
"some files cannot be opened by name, but require specific information
stored in this event."
However, that API is not useful at all, the implementation just opens
the passed-in QFile, using the stored file name. There's no way
to override this, and QFileOpenEvent is a locked class with all data
stored inline. So we can't even redirect to a platform-implementation.
Deprecate that function. Applications should interpret the string
returned by file(), which might not be a path to a local file.
Fixes: QTBUG-98384
Change-Id: Iff75489de9d7c5fc034f44c0bda4963b2efb1925
Reviewed-by: Tor Arne Vestbø <[email protected]>
|
|
|
|
|
|
| |
Pick-to: 6.5
Change-Id: I32580a29e3d5bbeca2832c421e07cec094e9576d
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the case for keys such as Qt::Key_Delete ("\u007F"),
and Qt::ControlModifier + Qt::Key_C ("\u0003") on Windows and XCB,
as well as potentially any key event on macOS when IM is not enabled,
as of 705665957baf16f9ec4d256dd4d2fad98788314b.
We can not filter QKeyEvent text() based on QChar::isPrint() or
similar, as there might e.g. be valid printable text in the private
use area, depending on the script and available fonts.
See QInputControl::isAcceptableInput() for some of this complexity.
Task-number: QTBUG-106393
Change-Id: I84d7ed86f57c1b605ac512d0f7ab66f6a11ed7bb
Reviewed-by: Volker Hilsheimer <[email protected]>
Reviewed-by: Eskil Abrahamsen Blomfeldt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Input events that originate from actual device interaction should reflect the
device's state, and device and events need to be kept in sync so that event
sequences (such as multi-touch events, where we have begin/update/end cycles
spanning multiple events) are working correctly.
For that reason, the event point data in pointer events is explicitly shared,
and we only detach in exceptional situations. This saves us memory allocations,
and makes sure that the event point data carried by events, and the event point
data stored persistently in the device, are kept in sync.
Cloned pointer events do not originate from device interactions, and should
therefore not sync back to the device. E.g. accepting a clone should not modify
the original event data stored in the device. There are exceptions here as
well, e.g. when cloning an event in Qt in order to deliver a translated version
of it to a different scene. Different points might even get delivered to
different scenes or windows, or at least different items in the same scene. For
that reason, we explicitly detach, and then explicitly write back the relevant
states after the cloned event has been delivered.
But in general, we should assume that cloned events do not write back to the
device. Since QEventPoint is an explicitly shared data type that never detaches
itself, we have to explicitly detach it when making copies that should not be
shared.
The ideal implementation of this would be to do the detach in the copy
constructor of QPointerEvent, which is called when cloning. However, Qt itself
makes copies of QPointerEvent without using clone, e.g. when assembling lists
of touch events for the different subscenes or windows in
QGuiApplicationPrivate::processTouchEvent, where event objects are added to a
QVarLengthArray<QMutableTouchEvent>. This makes copies, and those copies must
not detach.
So we have to implement the special cloning behavior in each override of
QPointerEvent::clone(). For this, introduce a dedicated macro for the common
member functions. This macro must be used for QPointerEvent subclasses.
Fixes: QTBUG-107560
Change-Id: I4b56f9e71c7d067ba9054a2a631e8ba5bc7b1ab9
Reviewed-by: Shawn Rutledge <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Wasn't marked deprecated in documentation, and was needed for user
construction of QShortcutEvents.
Fixes: QTBUG-109090
Change-Id: Ibf0ad83a57de724d9b88a7e610ba04c2c662983b
Reviewed-by: Ivan Solovev <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Only did instances where two-and-two words are duplicated,
easy to see when wrong.
Task-number: QTBUG-107777
Pick-to: 6.4
Change-Id: I11593728acc386e7ef9aba9b39a0a4d9c60a532f
Reviewed-by: Ievgenii Meshcheriakov <[email protected]>
Reviewed-by: Edward Welbourne <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QHoverEvent ctor takes two points: scenePos and globalPos; the first
of those is passed to the QSinglePointEvent ctor as _both_ the local and
scene pos, which calls QMutableEventPoint::setScenePosition() on the
persistent QEventPoint instance, and then detaches before setting
ephemeral state.
Therefore, we must construct QHoverEvent with scene position, not local
position, so that the right value is persisted. To localize a
QHoverEvent during delivery, use QMutableEventPoint::setPosition().
This needs to be done repeatedly while visiting multiple widgets or
items; the detach() prevents it from being saved in the persistent
QEventPoint in QPointingDevicePrivate::EventPointMap.
Amends 0a64a044b6c1c44b0a2bb2be5e70fda920f5f6bf
Task-number: QTBUG-35409
Task-number: QTBUG-100324
Change-Id: Ic1084e1c3cd384683666ba52fe34f16b9d039877
Pick-to: 6.4
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have deprecated the usage of Qt::MouseEventSource getter in
QMouseEvent::source() since 6.0. However, we have a lot of related
APIs, where the usage of this enum was not marked deprecated. Also we
have a lot of code in qtbase, qtdeclarative and some other modules
that rely on those values.
In most cases using QMouseEvent::source() is the only way to pass
the proper value to the other APIs.
This patch un-deprecates the method, so that we can safely identify
all of its usages in our code, and port away from it.
At the same time, we do not want the client code to use this method,
so documentation still mentions it as deprecated since 6.0.
Task-number: QTBUG-104857
Pick-to: 6.4 6.3 6.2
Change-Id: I767002aa6dc754fb5a58cf8fbf35774dae9986ed
Reviewed-by: Shawn Rutledge <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Amends 8932e80d0c8879a1e720fef825ed0d9c4e384a01 to make implementation
match docs: the ! went missing during repeated patch rebasing, apparently.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-101932
Change-Id: I3fe910774f5bdf4ab0342a9cf1994bb489f20e87
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-104857
Pick-to: 6.4 6.3 6.2
Change-Id: I5ee41802ecc4d6291aaaa1f0efddd20027c1c1e4
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the deprecated methods didn't have their definitions guarded by
if QT_DEPRECATED_SINCE(MAJ, MIN)
This patch fixes such cases over all QtBase.
Task-number: QTBUG-104857
Pick-to: 6.4 6.3 6.2
Change-Id: I0106128f3a35a30c9f2949819f39076e773559e7
Reviewed-by: Volker Hilsheimer <[email protected]>
Reviewed-by: Qt CI Bot <[email protected]>
Reviewed-by: Marc Mutz <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Fixes: QTBUG-104484
Pick-to: 6.2 6.3 6.4
Change-Id: I20068bb9e641545edad67910b4586aa38aec093b
Reviewed-by: Kevin Keating
Reviewed-by: Topi Reiniö <[email protected]>
Reviewed-by: Shawn Rutledge <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The API is deprecated, but the documentation does not state that.
Fixes: PYSIDE-1750
Pick-to: 6.4 6.3 6.2 6.1 6.0
Change-Id: I038ffeb958312d7648690743e06598a15dfb4cbc
Reviewed-by: Topi Reiniö <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <[email protected]>
Reviewed-by: Lars Knoll <[email protected]>
Reviewed-by: Jörg Bornemann <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Including moc files directly into their classes' TU tends to improve
codegen and enables extended compiler warnings, e.g. about unused
private functions or fields.
Pick-to: 6.3 6.2 5.15
Task-number: QTBUG-102886
Change-Id: I1945741794c25679a9d94c0d68c8642e2c823502
Reviewed-by: Mårten Nordheim <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no advantage to them being inline: Absent de-virtualisation,
clone() is only supposed to be called through the vtable, and the copy
ctor is only supposed to be used in the implementation of clone().
And when the compiler de-virtualises, we don't want the code
duplication associated with inlining.
Enforce this by introducing new macros to hide the boilerplate.
This fixes missing out-of-line dtors in:
- QSinglePointEvent
- QApplicationStateChangeEvent
- QFutureCallOutEvent
Wrong covariant return in:
- QFutureCallOutEvent
And missing clone() reimplementations in:
- QCloseEvent
- QIconDragEvent
- QShowEvent
- QHideEvent
- QDragEnterEvent
- QDragLeaveEvent
While these don't carry extra data or members, a dynamic_cast of the
result of clone() as well as using the expected covariant return value
would fail:
QShowEvent *e = ~~~;
QShowEvent *e2 = e->clone(); // ERROR: converting QEvent* to QShowEvent*
Check that reimplementing clone() is binary compatible (covariant
returns may change the numerical pointer value returned, cf.
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B).
The copy-assignment operator stays inline for the time being, as the
goal is to = delete it in the future.
This patch covers, roughly, QtCore and QtGui.
[ChangeLog][QtGui][QEvent subclasses] Fixed missing clone()
reimplementations on QCloseEvent, QIconDragEvent, QShowEvent,
QHideEvent, QDragEnterEvent, and QDragLeaveEvent.
Task-number: QTBUG-45582
Task-number: QTBUG-97601
Change-Id: Ib8a0519dbe85a7a8da61050d48be338004dfa69a
Reviewed-by: Thiago Macieira <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This de-inlines destuctors of classes whose vtables are proven to be
duplicated even within the set of Qt libraries.
Since these are all private API classes, we can pick all the way back
to 6.2, and we don't need the comment that the dtor must always stay
empty, like for public classes.
As a drive-by, also de-inline the QPaintDeviceWindowPrivate ctor.
That's just code hygiene, it doesn't partake in vtable duplicating.
Pick-to: 6.3 6.2
Task-number: QTBUG-45582
Change-Id: I3477063d6f42edc9a5d352c47900366fd50c3ef6
Reviewed-by: Fabian Kosmale <[email protected]>
Reviewed-by: Shawn Rutledge <[email protected]>
Reviewed-by: Giuseppe D'Angelo <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
...for now anyway. The plan is to have C++ API for custom handlers
later on; and we'll see if we find any other "must-have" use cases.
Task-number: QTBUG-68110
Pick-to: 6.2 6.3
Change-Id: I5e624a500af37797345d25bb5f54b146b13a45ca
Reviewed-by: Venugopal Shivashankar <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As with QHoverEvent, it's better to require globalPos rather than
"initialized to QCursor::pos(), which may not be appropriate" as the
docs have pointed out for many years now. This removes the remaining
calls to QCursor::pos() in event constructors.
Task-number: QTBUG-52430
Task-number: QTBUG-69433
Task-number: QTBUG-100324
Change-Id: I076dae56f37abaad7085cc95dddee453a80a45f3
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QSinglePointEvent ctor assumes that the given globalPos is correct,
so it was wrong that the QHoverEvent ctor passed along a local position
as global. It's better to require globalPos as an argument; and in fact
it seems that everywhere we construct a QHoverEvent, global position is
available, or possible to get by transformation (which is better than
resorting to QCursor::pos()).
Also, don't convert to QPoint: pointer events have qreal resolution and
there's no reason to truncate them.
Fixes: QTBUG-100324
Change-Id: I919455da36265988d3d149eb97563c9ed0d2c660
Pick-to: 6.3
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The header no longer uses QMutableEventPoint.
Fix TUs that relied on the transitive include.
Task-number: QTBUG-99615
Pick-to: 6.3
Change-Id: Iae4ff34ea708304fcd365fd763875dd4a97a1cf8
Reviewed-by: Fabian Kosmale <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the new static QMutableEventPoint setters, which do not depend on
undefined behavior.
Made it a separate commit, because, while straight-forward, it's a lot
of changes compared to other users.
Task-number: QTBUG-99615
Pick-to: 6.3
Change-Id: I580b6b225421a1e908f04c8e30adcdef6540ea52
Reviewed-by: Shawn Rutledge <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These overloads don't require a cast from QEventPoint to
QMutableEventPoint, thus avoiding undefined behavior.
Port easy users of QMutableEventPosition::(const)from()
to the new API.
Pick-to: 6.3
Task-number: QTBUG-99615
Change-Id: I4e9228322134ef7c712ca478ee8286466efc3585
Reviewed-by: Qt CI Bot <[email protected]>
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function contributed 1.2s of the total 361s (0.34%) to KDDockWidgets
compilation time, according to a trace generated by Sergio Martins:
**** Time summary:
Compilation (146 times):
Parsing (frontend): 343.2 s
Codegen & opts (backend): 18.1 s
**** Templates that took longest to instantiate:
[...]
1228 ms: QList<QEventPoint>::operator[] (59 times, avg 20 ms)
1213 ms: QList<QEventPoint>::detach (59 times, avg 20 ms)
1209 ms: QArrayDataPointer<QEventPoint>::detach (59 times, avg 20 ms)
1202 ms: QArrayDataPointer<QEventPoint>::reallocateAndGrow (59 times, avg 20 ms)
Task-number: QTBUG-97601
Pick-to: 6.3
Change-Id: I5f4ff9843f7deff9f390c465df28cba3391e048b
Reviewed-by: Lars Knoll <[email protected]>
|
|
|
|
|
|
|
| |
Pick-to: 6.2
Fixes: QTBUG-98875
Change-Id: I2678edccf68d754d191b9eb6cdfe09bba327e85a
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
| |
Pick-to: 5.15 6.2
Change-Id: I533f5a55cd0cd60a76990b552d7dab51a301ac1c
Reviewed-by: Giuseppe D'Angelo <[email protected]>
|
|
|
|
|
|
| |
Pick-to: 6.2
Change-Id: I0924f5a540ab5e58f7830c1af099ce6e44287811
Reviewed-by: Paul Wicking <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Amends 53496e67f0b78645c6080e9218c7a36bc5a9d76d:
- move flags() out of the QT_DEPRECATED_SINCE block in the header
- add QT_DEPRECATED_SINCE block around source() implementation
Pick-to: 6.1 6.2
Change-Id: Id52fa6b04a13efbede3e6ac440060f90b283e773
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Added missing #if-ery and deprecation macros to a QFont constructor
that was only documented as deprecated.
Fixes: QTBUG-94521
Fixes: QTBUG-95310
Pick-to: 6.2 6.1
Change-Id: I3d0418a3f7dca191a9068cc22627fe4deb7c53c5
Reviewed-by: Edward Welbourne <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
We keep QVector2D storage Qt 6 BC (to avoid making QNativeGestureEvent
larger), but in Qt 7 we should return exactly the same value as given
(for what it's worth, in spite of this being overkill for panning a
reasonable distance).
Change-Id: Iecbd4c9b60ad9ae5e0466c7027b038ddb85b8c8b
Pick-to: 6.2
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In QPanGesture this is called delta().
OTOH we have QWheelEvent::pixelDeltas().
Delta is a vector, and there's only one (with two components).
Native gestures hold incremental values: e.g. the pinch gesture event
provides an incremental amount of either zooming or rotation (so most
events have QNativeGestureEvent::value() very close to 0).
It's the same with the pan gesture's delta().
Add better docs for swipe and pan gestures.
Change-Id: Ia147c7c9a22e084c3700b1620dec46427d792bd1
Reviewed-by: Povilas Kanapickas <[email protected]>
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It came up during 6.2 API review that we prefer all floating-point API
to be double-precision on 64-bit platforms, despite the awkwardness of
representing a displacement vector with something called a "point".
The docs for QPointF explicitly state "A QPointF object can also be used
as a vector: Addition and subtraction are defined..."
Amends 31f90e99b8f04d9a228c5a0b01319b3f112c1490
Change-Id: I01029661f2586640cbf846f49df164c176d17f7a
Reviewed-by: Volker Hilsheimer <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
In Qt 6, QHoverEvent is a QSinglePointEvent and carries more information
than it did in Qt 5.
Task-number: QTBUG-94971
Change-Id: I55b271e8741081ed9074f687b08f4111142a1bf0
Pick-to: 6.2
Reviewed-by: Fabian Kosmale <[email protected]>
|
|
|
|
|
|
|
|
| |
It's only Qt::MiddleButton in Qt 6.
Pick-to: 6.1 6.2
Change-Id: Ia68bad910c617993e30e3ed1e117192469ec50eb
Reviewed-by: Edward Welbourne <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 0336f08fec906af7e907d07d990a097a9a1d8726.
Reason for revert: This breaks tst_qquickpinchhandler;
We no longer seem to construct a QNativeGestureEvent of type
EndNativeGesture with it.
Change-Id: I942fa099d5c5a1c757accde0c67e407809ce2d72
Reviewed-by: Shawn Rutledge <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The QSinglePointEvent is mostly responsible for setting
QEventPoint::state(); but in this case we need to decide based on
Qt::NativeGestureType, so it needs to be refined in the
QNativeGestureEvent constructor.
Fixes: QTBUG-94178
Change-Id: I9799fe5b8fea71f934311ae2f3bb8e033d132ec5
Reviewed-by: Povilas Kanapickas <[email protected]>
Reviewed-by: Fabian Kosmale <[email protected]>
|