| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
It's no longer used; the only calls to QApplicationPrivate::desktop
pass the default nullptr for QScreen, so all we need is a Qt::Desktop
type toplevel widget.
Include changes documentation about both the class and QApplication::desktop
being gone in Qt 6.
Change-Id: I22d6e93cabc6aaaefffe5e96942886a2ef4e0609
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
It returns the QFontMetrics of the desktop widget, so just for the
default screen. Any usage of it is probably wrong, esp since code should
use QFontMetricsF instead.
Change-Id: I0b4b85a74a2c9b6cc023ffda0b2b399f9fc3c1c4
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
It's been replaced with QScreen-based APIs.
There's some internal code left
depending on a QWidget representing a screen, so move the API into
QApplicationPrivate until that's cleaned up as well.
Change-Id: I851e0901832f2747af3bf2c16a9c4d815598bd08
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
| |
Use QScreen APIs instead.
Change-Id: Ie99af94fe4292223dbb165b3f5c1b74e8fe0498b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no function equivalent in Qt 5.15, but the entire QDesktopWidget
class is already documented as obsolete, so this method should implicitly
no longer be used in new code.
Qt 6 lifts QScreen up to support the various QDesktopWidget use cases,
and a follow up will remove this method from Qt 6.0, or at least mark it
as deprecated API as well so that it
generates warnings when used.
Change-Id: I9b205e6d4a636c22a95728695088233c898cbfc4
Pick-to: 5.15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In translateTouchCancel() and findClosestTouchPointTarget(), in the
context of doing a range-for loop over activePoints:
for (const auto &pair : devPriv->activePoints) { ... }
clang was warning that the reference to the pair is a copy:
warning: loop variable 'pair' is always a copy because the range of type
'QPointingDevicePrivate::EventPointMap' (aka 'QFlatMap<int, QPointingDevicePrivate::EventPointData>')
does not return a reference [-Wrange-loop-analysis]
But we weren't using the key anyway, so we might as well iterate over
values() just as various functions in QPointingDevicePrivate are doing.
Change-Id: Id8ee784255af98064e8347d5fa6a806d442933a8
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
|
|
|
|
|
|
|
| |
Use C++17 attribute directly
Change-Id: Id853e7a5117065e4adb549f81303c1820fe198ce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
It was already used many places directly making the code inconsistent.
Change-Id: I3b14bc6c333640fb3ba33c71eba97e78c973e44b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
| |
Replace with QPointerEvent::points().
As a drive-by, turn QEventPoint copies into const references where possible.
Change-Id: Ia5e0645493984fe9177dd3ca16afdb4d56e384ee
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: Idf5c1490330e0f2e5d4bcf920eb03fc9993b3c8a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
|
|
|
|
|
|
|
| |
Adapt to 5bb4baae0379d5903f547f0399be9620f5ab06a0.
Change-Id: Id65f87740f9de8e0d3624ff63c431dcad642f3a5
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
It replaces the deprecated int margins property, which was a Q_PROPERTY.
This enables Qt for Python users to use property syntax for it.
Task-number: PYSIDE-1019
Change-Id: I958d2ef7f8e2afcc2be490e29d4b11c070569fbd
Reviewed-by: Christian Tismer <tismer@stackless.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
| |
This follows up on commit d273076b4474bb473d90e996960c4c773745761a
which left a comment asking for the clean-up this finishes.
Task-number: QTBUG-85700
Change-Id: I1c6896a42a09b873302ad7ec8273879f2a4a4ce6
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
| |
This ports all of QtBase.
Change-Id: If6712da44d7749b97b74f4614a04fac360f69d9e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and the associated enumeration.
Using them is almost always a certain mistake.
1) op+ between two enumerators of the same enumeration yields int,
not QFlags, so removing the type safety that QFlags is supposed to
give and breaking the semantics of bitwise operations.
2) op+ between two enumerators of different enumerations is
deprecated in C++20 (already flagged by GCC10), and again yields
int. This is a code smell. Dedicated classes (holding a combination
of unrelated enums) should be used instead.
3) op+ between an enumerator and its QFlags loses the semantic
meaning of bitwise operations. If the real meaning was to use
operator|, then use that instead; operator+ hides the intent,
and can introduce bugs by creating a result not expressible via
OR combinations of enumerators:
enum E { A = 0x01, B = 0x02 };
QFlags<E> f = E::A;
f + E::A; // ???
f + E::B; // ???
Identical reasoning applies for operator-. Technically the
other arithmetic operators could be disabled as well, but I
really don't expect any real-world usage for them.
This has spotted bugs in Qt.
[ChangeLog][Potentially Source-Incompatible Changes][QFlags] Using
operator+ or operator- with a QFlags object or with an enumeration
that has a corresponding QFlags object will now result in a
compile-time error, because it's a generally unsafe operation.
Use the proper bitwise operations instead (|, &, ~); or cast
the enumeration to a integral type before attempting arithmetic
manipulations on it.
Change-Id: I5eabc5195dec3d3082bc9da10dbc8cf5dff3e1eb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because we removed public setters from QTouchEvent and QEventPoint in
4e400369c08db251cd489fec1229398c224d02b4 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of QCoreApplication::quit() directly calling exit(0), which would
leave QGuiApplication and client code out of the loop, we now send the
Quit event, and let it pass through event delivery, before finally ending
up in QCoreApplication::event(), where we call exit(0).
This has the advantage that QGuiApplication can ensure all windows are
closed before quitting, and if any of those windows ignore the close
event the quit will be aborted. This aligns the behavior of synthetic
quits via QCoreApplication::quit() with spontaneous quits from the
platform via QGuiApplicationPrivate::processApplicationTermination.
Clients who wish to exit the application without any event delivery or
potential user interaction can call the lower level exit() function
directly.
[ChangeLog][QtGui] Application termination via qApp->quit() will now
deliver Quit events to the application, which in turn will result in
application windows being closed as part of the application quit,
with an option to cancel the application quit by ignoring the close
event. Clients who explicitly want to exit the application without
any user interaction should call QCoreApplication::exit() explicitly.
Task-number: QTBUG-45262
Task-number: QTBUG-33235
Task-number: QTBUG-72013
Task-number: QTBUG-59782
Change-Id: Id4b3907e329b9ecfd936fe9a5f8a70cb66b76bb7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
| |
In some places needs to be ordered before const/constexpr though.
Change-Id: I57a521ac0ad22b5a018761c4d52befbef69d64c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
They are unused.
Change-Id: I77383f2be45551401ed9c2f88285511134cc8b0d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a source incompatible change for widget implementors.
Leaving the old enterEvent as a virtual overload is problematic due to
shadowing. Best to make a clean cut, widget reimplementors will get a compile
time warning if they mark their override as such, or if they try to call the
parent class implementation.
Addresses ### Qt 6 comment.
[ChangeLog][QtWidgets][QWidget] The virtual enterEvent handler now receives
a QEnterEvent, which contains information about mouse position and button
states, rather than a plain QEvent.
Change-Id: I233f594fd79c0c090983b3db8532913d00132fde
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
Display QCompoBox popups on the correct screen, also
when the parent window spans multiple screens. In this
case, QWidget::screen() will return the main screen for the
window, which will not necessarily be the screen at
the combobox popup position.
Change-Id: Ib8a8163a757f7b849883b833fbde27a1e01af49a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 5.0 - WFlags
Since 5.6 - ItemIsTristate
Since 5.14 - WA_NoBackground, WA_MacNoClickThrough,
WA_MacBrushedMetal, WA_MacMetalStyle, WA_MSWindowsUseDirect3D
WA_MacFrameworkScaled, ImMicroFocus
Since 5.15 - MatchRegExp, MidButton (really since 5.7.0),
WA_ContentsPropagated (really since 4.5.1, as are the following),
WA_WState_DND, WA_ForceAcceptDrops.
Change-Id: Ib1db3d85bf28823c704b5f3857546764b158e1ed
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A comment is not good enough, Some of the enum members were even still
in use, or mentioned in documentation.
WA_ContentsPropagated, WA_WState_DND and WA_ForceAcceptDrops have been
deprecated since 4.5.1; and at least the last has been an \omitvalue
in the docs for even longer. (WA_ShowModal and WA_GroupLeader have
been similarly marked, but are in use, see QTBUG-85816.)
Push back to 5.15.1 in order to be able to remove these at Qt 6.
Pick-to: 5.15.1
Change-Id: I6ea3839767e5f5158b0fed508f65798470191908
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop relying on the "magic" of itemAt returning nullptr for out of
bounds. Just use count().
Unfortunately, QMainWindowLayout breaks the API contract by NOT
implementing count() properly. So, make its count() crash if called;
and move the itemAt implementation there.
Change-Id: I120686a834bab15dd537598a56bd93d6a5924aa5
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the name/key of the style to 'macos'. Besides the
name 'macintosh' being archaic, we also need this
change to avoid creating 'macintosh' style folders
in QtQuickControls, now that we plan to use QPlatformTheme
also there to resolve the style.
[ChangeLog][Widgets][QStyle] The 'macintosh' style
has been renamed to 'macos'.
Change-Id: I14b8a8b4dbd369e7a7d16b94e4ad27e501e7e8d0
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>
|
|
|
|
|
|
| |
Task-number: QTBUG-80316
Change-Id: I2ee74110fd55e94d86321d3b3dc5bb8297424ed4
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Thanks to the newly introduced indexOf overload.
Change-Id: I00377591dba4104f1dfd34816cc74efcf5220a4d
Reviewed-by: David Faure <david.faure@kdab.com>
|
|
|
|
|
|
|
|
| |
warning: C5054: operator '&': deprecated between enumerations of different types
Pick-to: 5.15
Change-Id: I4e48a44f089d3eaca5d3f876da01335051192b28
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to fix an API mistake there: there is no reason why these
functions should take pointers to non-const widgets, as that
actually preventing reasonable code (e.g. finding out the index
of "this" inside a const method of a QWidget subclass).
Unfortunately, indexOf(QWidget*) is also virtual, meaning that
changing its signature is an API break. Hopefully, there are
only few users that override this method (Woboq says 0).
[ChangeLog][Potentially Source-Incompatible Changes]
The QLayout::indexOf(QWidget *) virtual function has changed
signature, becoming QLayout::indexOf(const QWidget *).
This is source incompatible, although the fix (for the few
users that do override indexOf() in their layouts) is
straightforward.
Change-Id: Id2183f5ecd9dc7e2a37c7355266e8494ef7929f2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove obsolete functions and enumeration values
- Remove QObject * parameter from QMetaProperty accessors
- Fix renamed enumerations in QSsl
- Fix list items to be \li
- Fix function signatures and variable names
Change-Id: I37c7e6bf2c8ff92bc7b82620bae0a27796f866ab
Reviewed-by: Paul Wicking <paul.wicking@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>
|
|
|
|
|
|
|
|
|
|
|
| |
QDesktopWidget is not a public class anymore and only exists for
compatibility reasons. So we might just as well move the only method
used by other classes out of QDesktopWidgetPrivate, and get rid of the
friend declarations and the access-to-private code in QApplication.
Change-Id: I74ff14233e59912e0930f98995f8af60dbadfdb6
Task-number: QTBUG-62094
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follows the QWindow semantics, and is a replacement for creating
a QWidget with a QDesktopScreenWidget as the parent.
We can now remove much of the special handling of QDesktopWidget and
the Qt::Desktop window type, and get rid of QDesktopScreenWidget.
Add a manual test that allows local testing. Our CI environments
only have a single screen, and no multi-head display server setup
which is the primary case where QWidget::setScreen is interesting.
For the more common case of a virtual desktop, QWidget::setScreen
has no real impact (just as QWindow::setScreen doesn't).
Change-Id: Id0099e069d316741bacd8c795c396ccad37be297
Fixes: QTBUG-85483
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
|
|
|
|
|
|
| |
Change-Id: I68df86314cb8c3602d7ddbcf1e4527cf247d5fa1
Pick-to: 5.15
Reviewed-by: Paul Wicking <paul.wicking@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>
|