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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
It was added in 2011 and has not seen any development since, and was
never included in the build system.
The OpenWFD use-case is covered by EGLFS, which has a dedicated
OpenWFD backend.
Change-Id: Id08c505e2d869a96255163cae2ede51b9efeb73f
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
We want every QInputEvent to carry a valid device pointer. It may be
some time until all QPA plugins are sending it, but it's necessary to
provide the functions for them to start doing that.
We now try to maintain the same order of arguments to all the functions.
handleTouchEvent(window, timestamp, device, the rest) was already there
(except "device" has changed type now), and is used in a lot of platform
plugins; so it seems easiest to let that set the precedent, and modify
the rest to match. We do that by adding new functions; we can deprecate
the older functions after it becomes clear that the new ones work well.
However the handleGestureEvent functions have only ever been used in
the cocoa plugin, so it's easy to change their argument order right now.
Modify tst_qwindow::tabletEvents() to test new tablet event API.
Task-number: QTBUG-46412
Change-Id: I1828b61183cf51f3a08774936156c6a91cfc9a12
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We have seen during the Qt 5 series that QMouseEvent::source() does
not provide enough information: if it is synthesized, it could have
come from any device for which mouse events are synthesized, not only
from a touchscreen. By providing in every QInputEvent as complete
information about the actual source device as possible, we will enable
very fine-tuned behavior in the object that handles each event.
Further, we would like to support multiple keyboards, pointing devices,
and named groups of devices that are known as "seats" in Wayland.
In Qt 5, QPA plugins registered each touchscreen as it was discovered.
Now we extend this pattern to all input devices. This new requirement
can be implemented gradually; for now, if a QTWSI input event is
received wtihout a device pointer, a default "core" device will be
created on-the-fly, and a warning emitted.
In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when
multiple devices were in use simultaneously. Now that each event
identifies the device it came from, this hack is no longer needed.
A stub of the new QPointerEvent is added; it will be developed further
in subsequent patches.
[ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer
to an instance of QInputDevice, or the subclass QPointingDevice in case
of mouse, touch and tablet events. Each platform plugin is expected to
create the device instances, register them, and provide valid pointers
with all input events. If this is not done, warnings are emitted and
default devices are created as necessary. When the device has accurate
information, it provides the opportunity to fine-tune behavior depending
on device type and capabilities: for example if a QMouseEvent is
synthesized from a touchscreen, the recipient can see which touchscreen
it came from. Each device also has a seatName to distinguish users on
multi-user windowing systems. Touchpoint IDs are no longer unique on
their own, but the combination of ID and device is.
Fixes: QTBUG-46412
Fixes: QTBUG-72167
Task-number: QTBUG-69433
Task-number: QTBUG-52430
Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
And silence those warnings in code that emits those signals.
Change-Id: Ic9013648060c9b84b59c44bb5a8c77e48f82d24f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Many of these were generated by clazy using the new qevent-accessors check.
Change-Id: Ie17af17f50fdc9f47d7859d267c14568cc350fd0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Macros and the await helper function from qfunctions_winrt(_p).h are
needed in other Qt modules which use UWP APIs on desktop windows.
Task-number: QTBUG-84434
Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Rather than have a paletteChanged() signal which can be connected to for
tracking when the application palette has changed, then it is better to
use the event that is sent to all windows and the application itself.
That way it is easy for a window/widget or item that cares about the
change to the application font to catch it in the event() function.
[ChangeLog][QtGui][QGuiApplication] Deprecated paletteChanged() signal
in favor of QEvent::ApplicationPaletteChanged.
Change-Id: I95da211e30590e357007cc14d8ee266baceba7b3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It simplifies the API and reduces surprise to have rotation working by default.
On Android, the manifest specifies which orientations the application has
been designed to support; on iOS, it is controlled via the
UISupportedInterfaceOrientations property list key.
In addition, QWindow::contentOrientation() is another way to give
a hint to the window manager, or on iOS to directly control whether
the window's rotation is locked or not.
Task-number: QTBUG-35427
Task-number: QTBUG-38576
Task-number: QTBUG-44569
Task-number: QTBUG-51012
Task-number: QTBUG-83055
Change-Id: Ieed818497f686399db23813269af322bfdd237af
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When a change in logical DPI occurs due to the user changing the scaling
factor, the screen size in device independent pixels may change
due to High DPI choosing a different scale factor.
Factor out the commonly used code into QScreenPrivate methods
and use them from
QGuiApplicationPrivate::processScreenLogicalDotsPerInchChange().
Pick-to: 5.15
Task-number: QTBUG-76902
Task-number: QTBUG-79248
Change-Id: I241a0f52d8236a65084d501fb4d8f9faeea89c0f
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Rather than have a fontChanged() signal which can be connected to for
tracking when the application font has changed, then it is better to
use the event that is sent to all windows and the application itself.
That way it is easy for a window/widget or item that cares about the
change to the application font to catch it in the event() function.
[ChangeLog][QtGui][QGuiApplication] Deprecated fontChanged() signal in
favor of QEvent::ApplicationFontChanged.
Change-Id: Iae8e832238fc85e385a52305bc04f16e597454b0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is required, so that QHash and QSet can hold more
than 2^32 items on 64 bit platforms.
The actual hashing functions for strings are still 32bit, this will
be changed in a follow-up commit.
Change-Id: I4372125252486075ff3a0b45ecfa818359fe103b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Conflicts:
examples/opengl/doc/src/cube.qdoc
src/corelib/global/qlibraryinfo.cpp
src/corelib/text/qbytearray_p.h
src/corelib/text/qlocale_data_p.h
src/corelib/time/qhijricalendar_data_p.h
src/corelib/time/qjalalicalendar_data_p.h
src/corelib/time/qromancalendar_data_p.h
src/network/ssl/qsslcertificate.h
src/widgets/doc/src/graphicsview.qdoc
src/widgets/widgets/qcombobox.cpp
src/widgets/widgets/qcombobox.h
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp
tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro
tests/manual/diaglib/debugproxystyle.cpp
tests/manual/diaglib/qwidgetdump.cpp
tests/manual/diaglib/qwindowdump.cpp
tests/manual/diaglib/textdump.cpp
util/locale_database/cldr2qlocalexml.py
util/locale_database/qlocalexml.py
util/locale_database/qlocalexml2cpp.py
Resolution of util/locale_database/ are based on:
https://codereview.qt-project.org/c/qt/qtbase/+/294250
and src/corelib/{text,time}/*_data_p.h were then regenerated by
running those scripts.
Updated CMakeLists.txt in each of
tests/auto/corelib/serialization/qcborstreamreader/
tests/auto/corelib/serialization/qcborvalue/
tests/auto/gui/kernel/
and generated new ones in each of
tests/auto/gui/kernel/qaddpostroutine/
tests/auto/gui/kernel/qhighdpiscaling/
tests/libfuzzer/corelib/text/qregularexpression/optimize/
tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/
tests/libfuzzer/gui/text/qtextdocument/sethtml/
tests/libfuzzer/gui/text/qtextdocument/setmarkdown/
tests/libfuzzer/gui/text/qtextlayout/beginlayout/
by running util/cmake/pro2cmake.py on their changed .pro files.
Changed target name in
tests/auto/gui/kernel/qaction/qaction.pro
tests/auto/gui/kernel/qaction/qactiongroup.pro
tests/auto/gui/kernel/qshortcut/qshortcut.pro
to ensure unique target names for CMake
Changed tst_QComboBox::currentIndex to not test the
currentIndexChanged(QString), as that one does not exist in Qt 6
anymore.
Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
Currently depending if user uses QApplication
or QGuiApplication we end up in different behavior
when running post routines. For example QApplication
destructor calls post routines before stopping event dispatcher,
In case of QGuiApplication post routines are called
from QCoreApplication destructor, so no more event dispatcher.
This behavior is not consistent and creates troubles
when releasing resources of web engine.
Attached test will hang on windows with QGuiApplication,
however works fine with QApplication.
Task-number: QTBUG-79864
Change-Id: Ice05e66a467feaf3ad6addfbc14973649da8065e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
By sending it to all top level windows it will make it possible for
non widget based controls to listen for this event if it cares about it
so it can handle translation updates as appropriate.
Task-number: QTBUG-78141
Task-number: QTBUG-82020
Change-Id: I8f35cdcccd81a199ff780c3f4f3d2c663480d638
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Since the backend is async, the settings will not be ready to read/write
instantly as on other platforms, but only be ready after the
filesystem has been synced to the sandbox. This takes at least 250 to
500 ms. The QSettings status() or isWritable() can be used to discern when the
settings are ready for use.
This also fixes a crash in threaded wasm
Task-number: QTBUG-70002
Change-Id: I080bdb940aa8e9a126d7358b524f32477db151b6
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The static self pointer of QGuiApplicationPrivate was not reset at
destruction (in constrast to the corresponding
QGuiApplication::self). This could cause crashes when calling Qt API
after QGuiApplication destruction.
Fixing this revealed an issue with QGuiApplication::font(), which
would assert QGuiApplicationPrivate::self. But the QApplication
autotest actually calls this function with no QApplication
instance. That autotest passes only coincidentally, since another
QApplication instance has been created and deleted already, and
the dangling self pointer of that instance was never reset.
To improve the robustness of the api, replace the assert/crash with
just a warning and return an "empty" QFont.
(The assert was added for 5.0 for QTBUG-28306 in order to give a nicer
warning when mixing QWidget and QtCore/GuiApplication. However it
never got that effect in practice, since that issue was fixed at the
same time by another, better patch for the duplicate bug QTBUG-28076).
Fixes: QTBUG-81954
Change-Id: I3fa6cad1625a3e70631b5170d53119d63492b534
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Adds an opt-in experimental DirectWrite-based font database.
This cannot be the 100% replacement for GDI unfortunately, since
quite a few font formats used on Windows are still unsupported.
But it would be good to have it as an opt-in experimental feature
since it should make it easier to solve multiple font selection
issues we have on Windows.
In order to still share the DirectWrite-specific code between
the old and new database, this introduces a common base class.
Note that the feature depends on DirectWrite 3 support (Windows 10).
Fixes: QTBUG-74917
Change-Id: Ida08ec7ef4fda9fc78622ca4297909a727390a64
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Read the dark mode setting and make it accessible
via native interface.
Add a command line option to set the support level.
Task-number: QTBUG-72028
Change-Id: I1e9fe296a6b1bda81512d003183038b866b67545
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The logic is now mostly handled in QGuiApplication, with QApplication
only dealing with the widget-specific palettes and interaction between
the style and the palette.
The application now picks up changes to the platform theme and will
re-resolve the current application palette appropriately. This also
works even if an explicit application palette has been set, in which
case any missing roles are filled in by the theme.
The palette can now also be reset back to the default application
palette that's fully based on the theme, by passing in the default
constructed palette (or any palette that doesn't have any roles set).
This is also correctly reflected in the Qt::AA_SetPalette attribute.
Conceptually this means QGuiApplication and QApplication follow the
same behavior as QWidget, where the palette falls back to a base or
inherited palette for roles that are not set, in this case the theme.
Behavior-wise this means that the default application palette of the
application does not have any roles set, but clients should not have
relied on this, nor does QWidget rely on that internally.
It also means that setting a palette on the application and then
getting it back again will not produce the same palette as set,
since the palette was resolved against the theme in the meantime.
This is the same behavior as for QWidget, and although it's a
behavior change it's one towards a more sane behavior, so we
accept it.
[ChangeLog] Application palettes are now resolved against the platform's
theme palette, the same way widget palettes are resolved against their
parents, and the application palette. This means the application palette
reflected through QGuiApplication::palette() may not be exactly the same
palette as set via QGuiApplication::setPalette().
Change-Id: I76b99fcd27285e564899548349aa2a5713e5965d
Reviewed-by: Vitaly Fanaskov <vitaly.fanaskov@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Sort alphabetically and add recent relevant options with version
information.
Change-Id: I10c8cc82ce357775ed68cb811a0c906cd38633a5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change the default rounding policy to "Round" so that 2 is used
for 150% (144DPI) on Windows, as it was in 5.13.
Fixes: QTBUG-80934
Change-Id: I0cba986ce6afc9e2737c656000ad854c07844360
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Conflicts:
src/corelib/tools/qvector.h
Make QVector(DataPointer dd) public to be able to properly merge
5b4b437b30 from 5.15 into dev.
src/widgets/kernel/qapplication.cpp
tests/auto/tools/moc/allmocs_baseline_in.json
Done-With: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Change-Id: I929ba7c036d570382d0454c2c75f6f0d96ddbc01
Don’t reset highDpicaleFactorRoundingPolicy in the
QGuiApplication destructior. This is a static property,
independent of the application object lifetime.
Change-Id: Ibf55e2a6ea1ae6429fce3f0e9d58323111aac374
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Qt 5.14 introduced QApplication::scaleFactorRoundingPolicy,
where the default policy rounds the scale factor to
an integer, which matches Qt's behavior on Windows and X11.
However, Qt has never rounded scale factors on Android.
Restore the historical behavior and document the platform
difference.
Change-Id: I0f8e8fb65e3874338ea290bbb12da350da22f099
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The two static setPalette methods in QApplication and QGuiApplication
should have the same behavior in terms of what signals and events
they emit.
Change-Id: I54579d490e31f3783e2d4fea689ca799a070ff1d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
After 8fb881900c it's tracked by AA_SetPalette. Since the latter
is publicly observable we remove the internal flag instead.
Change-Id: Ie69799f1b45d68017cb9eaab2a9986cc9ac9ca38
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Move away from using 0 as pointer literal.
Done using clang-tidy. This is not complete as
run-clang-tidy can't handle all of qtbase in one go.
Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Amends qtbase/af2daafde72db02454d24b7d691aa6861525ab99.
Where applicable, port over to member initialization, thus also
fixing nullptr warnings.
Change-Id: Iaaf2dbbbcf2952253390b8839fd15a1b17be32c0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Since the backend is async, the settings will not be ready to read/write
instantly as on other platforms, but only be ready after the
filesystem has been synced to the sandbox. This takes at least 250 to
500 ms. The QSettings status() or isWritable() can be used to discern when the
settings are ready for use.
This also fixes a crash in threaded wasm
Task-number: QTBUG-70002
Fixes: QTBUG-63923
Fixes: QTBUG-79650
Change-Id: If24c6ada1b91b2a565ed6733da74972c3027f622
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Instead of having each platform plugin deal with application termination
in their own weird ways, we now have a QPA API to signal that the system
requested the application to terminate.
On the QGuiApplication side this results in a Quit event being sent to
the application, which triggers the default behavior of closing all app
windows, and then finally calling QCoreApplication::quit().
The quit event replaces the misuse of a close event being sent to the
application. Close events are documented as being sent to windows.
The close events that are sent to individual windows as part of the
quit process can be ignored. This will skip the final quit() of
the application, and also inform the platform that the quit was
not accepted, in case that should be propagated further.
In the future the logic for closing windows should be unified
between the various approaches in closeAllWindows, shouldQuit,
and friends.
Change-Id: I0ed7f1c0d3f0bf1a755e1dd4066e1575fc3a28e1
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The base WindowSystemEvent has had an eventAccepted flag since 2014.
Change-Id: Ia0aa795083cd98ece83a4c1cc010d3a25e2489fd
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We want to ensure that the qt4D and qt4O members are still initialized
the same way whenever deprecated constructors are used; and we want to
be able to verify it using qDebug. So we merely suppress these
warnings.
Change-Id: Ic2e5f0dd6feeabe81f06f9c31693c550ac0781e3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QGuiApplication::screenAt() is documented "If the point maps to more
than one set of virtual siblings, the first match is returned."
But in many cases it's possible to start from a known screen and
consider only its siblings, as when deciding where to open a QMenu
from a QMenuBar: the QMenuBar is already shown on some screen(s),
so the QMenu must be shown on a sibling from that set. This function
should be useful in other such cases too, hence it might as well
be public API.
Task-number: QTBUG-76162
Change-Id: I83c74b40eb53f56fb285a6074a3dc2c0ea9c570b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is to inform Qt Quick when a stationary touchpoint is delivered
that it is because of a changed property. Qt Quick still needs to avoid
delivering item-customized events (with only the touch points that occur
inside the item) that contain only stationary touch points without
changed properties. To be able to check this private flag,
QQuickPointerTouchEvent needs to be a friend.
Task-number: QTBUG-77142
Change-Id: I6ee0dffbbeca9e513c77227b757252e2eec6a4ef
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In QImageReader, also replace a QMutex with a QBasicMutex, making the
code similar to the corresponding code in QPicture.
Change-Id: Ia1cd546eccd3662837762e506235e350b7a08647
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
src/corelib/global/qnamespace.qdoc:3279: (qdoc) warning: Can't link to 'QGuiApplication::setHighDdpiScaleFactorRoundingPolicy()'
src/corelib/time/qislamiccivilcalendar.cpp:49: (qdoc) warning: Can't link to 'QJijriCalendar'
src/network/ssl/qsslsocket.cpp:1510: (qdoc) warning: Can't link to 'QSslConfiguration::defaultCaCertificates()'
src/network/access/qhttp2configuration.cpp:49: (qdoc) warning: '\brief' statement does not end with a full stop.
src/gui/text/qtextformat.cpp:532: (qdoc) warning: Undocumented enum item 'TableBorderCollapse' in QTextFormat::Property
src/gui/text/qtextdocument.cpp:2066: (qdoc) warning: Undocumented enum item 'UnknownResource' in QTextDocument::ResourceType
src/gui/kernel/qguiapplication.cpp:3500: (qdoc) warning: Undocumented parameter 'policy' in QGuiApplication::setHighDpiScaleFactorRoundingPolicy()
Change-Id: I3573ef98cf9b58d16525c356270fe009fdffcf45
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
As a rule, we don't deliver touch events containing only stationary
touchpoints. To fix QTBUG-52510 we added an exception in
1bd0ab7050 : if the velocity changed,
deliver it anyway. Now we need to do the same if the pressure changed.
Also, on the customer's hardware, pressure is indicated via ABS_MT_PRESSURE.
Change-Id: If7f7088df055d686cdd86967b999e38024f8170f
Fixes: QTBUG-77142
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Emitting a signal executes an unknowable amount of code. We shouldn't
hold a mutex while doing so. E.g., if the signal emission causes
another call to QGuiApplication::setFont(), the old code would
deadlock, since applicationFontMutex is not recursive.
Fix by taking a copy of the application font under mutex protection,
then dropping the lock for the emission of the signal.
Change-Id: Ib2569b3a08af6ef5f38459a19f74cb0db27b7772
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This API enables tuning of how Qt rounds fractional scale factors, and
corresponds to the QT_SCALE_FACTOR_ROUNDING_POLICY environment
variable
New API:
Qt::HighDPiScaleFactorRoundingPolicy
QGuiApplication::setHighDpiScaleFactorRoundingPolicy()
QGuiApplication::highDpiScaleFactorRoundingPolicy()
Done-with: Friedemann Kleint <Friedemann.Kleint@qt.io>
Task-number: QTBUG-53022
Change-Id: Ic360f26a173caa757e4ebde35ce08a6b74290b7d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
In the case that no plugins are specified, the above code would assert
since we are not checking whether there is a value in the variable name.
Change-Id: Ia5922a6936aff179ca19fdd10e335133cd30daf4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In Qt 5.0, delta() and orientation() were already marked obsolete,
but Widgets and tests have kept on depending on them all this time.
We now start using alternative API so they can really be deprecated.
All constructors except the newest one are also deprecated.
The plan is for all events from pointing devices to have
QPointF position() and globalPosition(), so we deprecate
the other position accessors.
[ChangeLog][QtGui] Obsolete constructors and accessors in QWheelEvent
now have proper deprecation macros. What is left is intended to be
compatible with planned changes in Qt 6.
Change-Id: I26250dc90922b60a6ed20d7f65f38019da3e139e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Additionally, we also add a Q_TRACE_EXIT which runs a trace point when
the scope is exited, leveraging qScopeGuard behind the scenes.
Q_TRACE_SCOPE uses Q_TRACE_EXIT internally - the difference is that
the _SCOPE version enforces the naming scheme of _entry / _exit for the
tracepoints, whereas Q_TRACE_EXIT can be used generically.
Change-Id: I4a2f5ea09f451fcf664d07fd493b679f7527ac06
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace null and '\c nullptr' with \nullptr in the documentation.
Change-Id: I58934eea06943309ba895833f1991629870ab45b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Qt for Python users reading the documentation assume that int(0) can
be passed for pointer parameters. Use the newly introduced \nullptr to
disambiguate this.
In a follow-up step, the \nullptr macro can be defined as None
when generating the Qt for Python documentation.
Task-number: PYSIDE-903
Change-Id: I3a45f87175a0668ab5f3f95f0aff409f7e3ef027
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Christian Tismer <tismer@stackless.com>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
corelib/serialization/qcbormap.h:176:14: warning: Missing reference in range-for with non trivial type (QPair<QCborValue, QCborValue>)
corelib/serialization/qjsoncbor.cpp:820:10: warning: Missing reference in range-for with non trivial type (QJsonValue)
gui/kernel/qguiapplication.cpp:1171:10: warning: Missing reference in range-for with non trivial type (QString)
printsupport/dialogs/qprintdialog_unix.cpp:741:10: warning: Missing reference in range-for with non trivial type (QString)
printsupport/kernel/qprinter.cpp:1851:10: warning: Missing reference in range-for with non trivial type (QVariant)
tools/qlalr/cppgenerator.cpp:463:8: warning: Missing reference in range-for with non trivial type (Name)
Change-Id: I327b0f116e329e55952ed5740a5f5af4b2918392
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If a tooltip was shown on an application modal dialog then it would end
up blocking mouse events to the dialog while the tooltip was visible.
Since tooltips are special in this case, they should not cause mouse
events to be blocked.
Fixes: QTBUG-65599
Change-Id: Ibf1729ca4942f5854e4f9687c5586382e23c1c31
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Move the checking logic from QGuiApplicationPrivate::_q_updateFocusObject()
to QInputMethodPrivate::objectAcceptsInputMethod(), which is also called
from QWidget::updateMicroFocus() via QInputMethod::update().
Fixes: QTBUG-56767
Change-Id: Ia4cce5e7e766008df891537048d5daf739c010ff
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Snap now uses xdg-desktop-portal for portal support. Add check for apps
running in Snap and make them use portals by default. We also should be
using different name for the platform theme used by sandboxed apps.
Change-Id: Ibaa35b7549b3d94775d7edb937f729a300d071b6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is the squashed diff from wip/webassembly to dev.
Done-with: Peng Wu <peng.wu@intopalo.com>
Done-with: Sami Enne <sami.enne@intopalo.com>
Done-with: Morten Johan Sørvig <morten.sorvig@qt.io>
Started-by: Andrew Knight <andrew.knight@intopalo.com>
Change-Id: I6562433c0a38d6ec49ab675e0f104f2665f3392d
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
According to MSDN, AltGr key presses are sent as a
sequence of SYS left Ctrl + right Alt.
Add an option to detect AltGr as modifier key.
Task-number: QTBUG-69317
Change-Id: I30ce169d2e6dbbae194ff714abfbc732b53652ce
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The platform may emit screen changes for child windows before top-level
windows, so we need to update the top level screen as soon as possible.
Change-Id: I090c620725c9c3171f5b038708d78ddfeec8512d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use CamelCase, like the API they're tracing.
Change-Id: Ie718ab624d17c9186bcf05cc1276c8eccad7f454
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
This was a regression from Qt4 and also is the documented behavior.
In addition this patch fixes various issues with cursor shape updating
that were discovered along the way and that are necessary for testing
the new changes.
The code in QGuiApplicationPrivate::processDrag() also needed a fixup,
particularly the resetting of QGuiApplicationPrivate::currentDragWindow.
Without this fix we would get DragMove (the one that immediately follows
the DragEnter) only for the first DragEnter event. For example when dnd
starts on mouse press then for mouse click we would get:
<click> DragEnter->DragMove->DragLeave <click> DragEnter->DragLeave
but the expected is:
<click> DragEnter->DragMove->DragLeave <click> DragEnter->DragMove->DragLeave
Task-number: QTBUG-34331
Change-Id: I3cc96c87d1fd5d1342c7f6c9438802ab30076e9e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
[ChangeLog][Wayland] In Qt 5.11.0, support for selecting a platform plugin based
on the XDG_SESSION_TYPE environment variable was added. On gnome-shell, however,
bugs—in both Qt and gnome-shell—made many widget applications almost unusable.
So until those bugs are fixed XDG_SESSION_TYPE=wayland is now ignored on
gnome-shell.
Task-number: QTBUG-68619
Change-Id: I902acd1c4fc996f46e8431c12c0a5cdbab883abf
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We move QInternalMimeData to a separate file, because this class is
used, even if draganddrop is disabled. From now on, include
qinternalmimedata_p.h instead of qdnd_p.h for QInternalMimeData.
Change-Id: I594e08e2e90d574dc445119091686b4b69e4731b
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
... instead of using a hack of directly accessing QGuiApplication
members.
The current QPA API was bad for two reasons:
1) It expects platform plugin authors to know about
internals of Qt Gui, particularly that QGuiApplication
uses QGuiApplication::{mouseButtons,keyboardModifiers}
to construct QDragMoveEvent and QDropEvent events. Which
results in the second reason why this is bad.
2) Platform plugins should not directly access member
variables of QGuiApplication, just to make sure that
QDragMoveEvent and QDropEvent events contain correct state.
Platform plugins should instead use QWindowSystemInterface
to communicate with Qt Gui (which is also the solution here).
The solution is to extend QWindowSystemInterface::handle{Drag,Drop}
to require mouse/keyboard state. We already do this for
some of the other methods, so it is nothing extraordinary.
This type of interface is also _required_ to support
drag-n-drops from other processes. We can't use
QGuiApplication::{mouseButtons,keyboardModifiers} when the
drag originates from another process, instead we need to
query mouse/keyboard state from the system.
This patch fixes drag-n-drops from others processes on XCB
platform plugin.
Task-number: QTBUG-57168
Change-Id: I3f8b0d2f76e9a32ae157622fef801829d629921d
Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Makes Qt application try to launch using wayland in a wayland session,
even if it was a default desktop build.
Change-Id: Ib7d4a79fbe777527d1862bd775627afae10b1e9e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since we have this documentation for the Windows platform plugin,
it makes sense to also have it for Cocoa.
Task-number: QTBUG-67372
Change-Id: I170ae251572c8e209643a582cdd7350aaf5c7ccd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
-geometry, -title and -icon for xcb did not work if the platform string had
arguments or there were fallback platforms.
Only accept the arguments if xcb is the default platform. I.e. ignore the
arguments if xcb is a fallback.
This now works:
./application -platform "xcb:someArg=value" -title specialXcbTitle
./application -platform "xcb;wayland" -title specialXcbTitle
./application -platform "xcb:someArg=value;wayland" -title specialXcbTitle
But this does not:
./application -platform "wayland;xcb:someArg=value" -title specialXcbTitle
Change-Id: I4ee20b1ed722bc98417a5e75db7d8c98ffcdfcfe
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
[ChangeLog][QtGui] QT_QPA_PLATFORM and the -platform argument now support a
list of platform plugins in prioritized order. Platforms are separated by
semicolons.
The plugins are tried in the order they are specified as long as all preceding
platforms fail gracefully by returning nullptr in the implementation of
QPlatformIntegrationPlugin::create()
This is useful on Linux distributions where the Wayland plugin may be
installed, but is not supported by the current session. i.e. if X11 is running
or if the compositor does not provide a compatible shell extension.
Example usage:
QT_QPA_PLATFORM="wayland;xcb" ./application
or
./application -platform "wayland;xcb"
Task-number: QTBUG-59762
Change-Id: Ia3f034ec522ed6729d71acf971d172da9e68a5a0
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
This makes the documentation match the implementation.
-platform overrides QT_QPA_PLATFORM, not the other way around. Similarly
for the other arguments.
Change-Id: Iffaf8bb1134bc57e5b682f37b9cc1a713872ede1
Reviewed-by: Martin Smith <martin.smith@qt.io>
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Conflicts:
src/corelib/tools/qvarlengtharray.qdoc
src/corelib/tools/qvector.qdoc
Resolved documentation changes in favor of 017569f702,
which keeps the move overloads along with its const-ref sibling.
Change-Id: I0835b0b3211a418e5e50defc4cf315f0964fab79
WindowScreenChanged events might be reported repeatedly from the QPA backends
until the event has reached GuiApplicationPrivate::processWindowScreenChangedEvent()
which sets the screen. Ignore events in case the screen is already correct.
Task-number: QTBUG-65580
Task-number: QTBUG-62971
Change-Id: Ie5fc9830771e816db942355efbe5a48e829914cb
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
This commit introduces minimal support for instrumentation within Qt.
Currently, only LTTNG/Linux and ETW/Windows are supported.
Change-Id: I59b48cf83acf5532a998bb493e6379e9177e14c8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The Embedded Android build (Boot to Qt Android injection) is defined by
having both Q_OS_ANDROID and Q_OS_ANDROID_EMBEDDED flags defined,
as well as having Qt config android-embedded.
This commit enables the possibility to build embedded Android builds.
(i.e. Qt build for Android baselayer only, without JNI)
Change-Id: I8406e959fdf1c8d9efebbbe53f1a391fa25f336a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
This removes the need to install an event filter on qApp just for this.
A similar thing was done with setPalette to reduce the number of event filters
in e.g. SystemPalette and Quick Controls.
[ChangeLog][QtGui][QGuiApplication] Added fontChanged signal
Change-Id: Ifa843aa42b91ac63ab17c3b064ac0e764aac77d3
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Unconditionally apply window cursors restoreOverrideCursor() also for
platforms with override cursor capability in case
a cursor was changed while the override cursor was active.
Amends b05d1c2ebf.
Task-number: QTBUG-65001
Change-Id: I7fd38a27dcf045f2fb48a16abb484342feaab5df
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Adds support for FileChooser Flatpak portal. To support them we just do
specific DBus calls, which are then caught and forwarded by xdg-desktop-
portal daemon/service. This is needed for Qt applications running in
sandbox.
[ChangeLog][Platform Specific Changes][Linux] Added support for flatpak
portals. Flatpak is a software utility for software deployment and
package management. It provides a sandbox environment in which users
can run applications in isolation from the rest of the system. To
communicate with the system flatpak uses portals, which are designed to
be a bridge between sandboxed applications and desktop/system running on
user's computer. Flatpak runs this service (called xdg-desktop-portal)
automatically. It exports the portals via DBus and they are visible by
default to all applications running under Flatpak.
Change-Id: I4de1402434ba7cbcc805eab51c30f84f8ba0c5c5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is one of the most frequent problems users ask for help with, and they
don't even know if the plugin was found but not loaded or simply not found.
Qt knows what happened, so communicate it to the user.
Change-Id: I6003ed4ab3d147a5d159b2002004e53c251cb512
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The safe area margins of a window represent the area that is safe to
place content within, without intersecting areas of the screen where
system UI is placed, or where a screen bezel may cover the content.
QWidget will incorporate the safe area margins into its contents margins,
so that they are are never smaller than the safe area margins. This can be
disabled by unsetting the Qt::WA_ContentsMarginsRespectsSafeArea widget
attribute, which is set by default.
QLayouts will automatically use the contents area of a widget for their
layout, unless the Qt::WA_LayoutOnEntireRect attribute has been set. This
can be used, along with a contents margin of 0 on the actual layout,
to allow e.g. a background image to underlay the status bar and other
system areas on an iOS device, while still allowing child widgets of
that background to be inset based on the safe area.
[ChangeLog][iOS/tvOS] Qt will now take the safe area margins of the
device into account when computing layouts for QtWidgets.
Change-Id: Ife3827ab663f0625c1451e75b14fb8eeffb00754
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Check for QWindowPrivate::blockedByModalWindow in
QGuiApplicationPrivate::processDrag().
Task-number: QTBUG-46287
Change-Id: I8f43de8389f34458f9e10b37b94806b47a50d40a
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
... that become apparent after switching qtestlib to use enhanced mouse
event (a37785ec76). With the old code path,
where QGuiApplication was deducing event type it would deduce mouse release
event even when there wasn't one. The new code path doesn't do that, which
revealed an obscure problem when mixing QTest::mouse* APIs (where QWindow
overload goes through QWindowSystemInterface API and QWidget overload goes
through QApplication::notify() and sets mouse_buttons from there). What
happened in this specific test case "./tst_qtreeview selection statusTip" was:
// tst_QTreeView::selection sets mouse_buttons = Qt::LeftButton from QApplication::notify
QTest::mousePress(widget, Qt::LeftButton, ..)
// tst_QTreeView::statusTip
QTest::mouseMove(window, )
The old code path sees that position and state has changed, creates a fake
mouse event, which gets deduced as mouse release even if there wasn't one.
And by luck this happened to set mouse_buttons=Qt::NoButton. So when we use
mouse_buttons later to create QMouseEvent everything works as expected. With
the enhanced mouse we don't clear the pressed button from mouse_buttons (set
in tst_QTreeView::selection) as this is done only from press/release events,
then pass it to QMouseEvent and later because of that QApplicationPrivate::
pickMouseReceiver() returns nullptr.
The fix here is to use e->buttons when constructing QMouseEvent, instead of
relying on mouse_buttons which gets changed from various places and has other
issues that can not be solved without invalidating the current documentation
of QGuiApplication::mouseButtons() (e.g QTBUG-33161). Tests and any Qt code
in general should avoid using the fragile QGuiApplication::mouseButtons() API.
This patch does not affect the old code path (it continues working as before)
and fixes the issue described above for the enhanced mouse API. The enhanced
mouse API actually is better in a way that it does not get affected by button
state from test functions that run earlier, as opposed to the old code path
where every subsequent test function uses mouse_buttons in whatever state it
was left by the test functions that run earlier.
Not relying on mouse_buttons when creating QMouseEvent helped also to discover
other logic error. This caused an in incorrect button state for a mouse move
event that is generated for a release event that simultaneously changes a mouse
position.
Task-number: QTBUG-64043
Change-Id: I6ad8e49d8437ab0858180c2d0d45694f3b3c2d60
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
All the required data is just there, few lines above. Instead of
throwing it away and then deducing again in mouse event handler,
use the enhanced mouse constructor.
Tablet event handler was the last remaining user of the obsolete
mouse event constructor. This patch removes the now unused construtor.
Change-Id: I0df7f1b82f0e768f651aa7fbe2d4efce93e992fa
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The documentation for AA_SynthesizeMouseForUnhandledTouchEvents states:
"All touch events that are not accepted by the application will be
translated to left button mouse events instead."
This is exactly what this patch does. With the enhanced mouse event,
we can simply pass event details as necessary. This should not conflict
with the code doing its own mouse synthesis (as long as custom event
handler accepts QEvent::Touch{Begin,Update,End}).
What was wrong with the previous implementation:
It was sharing the same state variable (mouse_buttons) to deduce button
state/type on physical mouse and emulated mouse. This was wrong, you
can't track state of two input devices by sharing one variable. Moreover,
this variable is intended for tracking state of a hardware mouse only.
Button state on physical mouse (as a separate pointer device) is
irrelevant for touch input (which is another "pointer device"). The
current API does not support multiple pointer devices, thus button state
on one pointer device should not affect state on other pointer device.
Task-number: QTBUG-57465
Task-number: QTBUG-52102
Change-Id: Id45d815508918b4e52319baddb2c9564d52ad783
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
... and deprecate QWSI APIs that accepts mouse event without mouse button/
type data.
In the early days of Qt5 it was decided to centralize mouse button/type
handling in QGuiApplication (because of limitation of some now unknown
platform). This has proven to be problematic as mouse handling details
differ across platforms (e.g on X11 we do not receive mouse release event
when closing popup windows or ordinary windows that are closed from the
mouse press event). Instead of hacking around platform specific behaviors
in Qt Gui, we should move this task back to platform plugins (similar to
how this was done in Qt4 with native APIs sending mouse details directly
to QApplication). There are even cases where it simply is not possible
to deduce (from QGuiApplication) which button caused the event (e.g. when
more than one button is involved and some event goes missing). Besisdes,
throwing away information which is already available at QPA level (for free)
and trying to deduce it again at Qt Gui level seems impractical, fagile
(as probably noticed by people fixing all the unexpected issues) and adds
unnecessary complexity.
Note:
Removing the deprecated QWSI APIs from offscreen plugin depends on fixing
autotests that rely on QOffscreenCursor::setPos() logic.
For the convenience of testing use QT_QPA_DISABLE_ENHANCED_MOUSE to restore
to the old code path where QGuiApplication does the mouse state deducing.
Other platforms have similar issues. I do not have all supported platform
available on my desk, so other platform maintainers will need to take care
of porting those platforms to the new APIs. And mainly, I don't want to deal
with all the hacks that other platforms have added to workaround this broken
mouse logic.
In Qt6 we need to remove deprecated code path from QGuiApplication.
This patch:
- Extends QWindowSystemInterfacePrivate::MouseEvent ctor with QEvent::Type
and Qt::MouseButton. We use this extra data when processing mouse events in
QGuiApplication. This actually is similar to KeyEvent, where we do pass the
type (press or release) to QtGui.
- Refactors QGuiApplicationPrivate::processMouseEvent and qtestlib to use
the new APIs.
Task-number: QTBUG-59277
Task-number: QTBUG-62329
Task-number: QTBUG-63467
Change-Id: If94fd46a7cccfea8264dcb1368804c73334558b8
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Non client area mouse events are mouse events too. There is no need
for a dedicated event type in QWindowSystemInterface.
Instead we pass the state through a 'nonClientArea' variable of the
mouse event, corresponding to QEvent::NonClientArea{Press,Release,Move}.
Change-Id: Ia0a188400787506c8fe0cfe58aee0776c1ab13c7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QtQuick is beginning to have a use for this, to distinguish native
gestures which come from actual trackpad rather than from the "core pointer".
It might as well use a real device ID instead of making one up,
as it has to do for the core pointer.
So far on macOS, the device ID isn't a real one; but that can be fixed,
as the qCDebug lines demonstrate (different trackpads have different IDs).
Change-Id: I5841deb1c4cc0b77a3b1df70904f70b3d2d71853
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
[ChangeLog][QtGui] It's now possible to retrieve the screen
at a given point via QGuiApplication::screenAt().
Change-Id: Ic09514ec731d8cce5d453833e98fcd118a70600e
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Błażej Szczygieł <spaz16@wp.pl>
LRESULT on Windows 64 is a 64bit type, adapt filter functions of
QAbstractNativeEventFilter and QAbstractEventDispatcher accordingly.
Fixes: QTBUG-72968
Change-Id: Ie53193e355f0b8e9bd59fa377f43e2b4664a2ded
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Conflicts:
tests/auto/widgets/itemviews/qheaderview/tst_qheaderview.cpp
Added tests/auto/testlib/selftests/expected_crashes_5.txt to work
round the output of the crashes test (which exercises UB, see
QTBUG-73903) being truncated on one test platform.
Change-Id: I9cd3f2639b4e50c3c4513e14629a40bdca8f8273
Adds QColorSpace and QColorTransform classes,
and parsing of a common subset of ICC profiles
found in images, and also parses the ICC profiles
in PNG and JPEGs.
For backwards compatibility no automatic color
handling is done by this patch.
[ChangeLog][QtGui] A QColorSpace class has been added,
and color spaces are now parsed from PNG and JPEG images.
No automatic color space conversion is done however, and
applications must request it.
Change-Id: Ic09935f84640a716467fa3a9ed1e73c02daf3675
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The logic of deciding whether or not to send resize and move events
has been centralized in QGuiApplication. This ensures that if a
window with geometry 100,100+200x200 is moved and resized to e.g.
0,0+100x100, but the window manager denies the request (because the
window would e.g. overlap with system UI), and issues a geometry
update with the original geometry, 100,100+200x200, we will still
treat that as warrant of a move/resize event to the application,
so the application knows that its position and size is as before.
[ChangeLog][Qt Gui][QPA] QWindowSystemInterfacePrivate::handleGeometryChange
no longer takes the old geometry as an argument.
Task-number: QTBUG-57608
Change-Id: I1d471cc7a257fef958bdb1e56184fa95489403a3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
QPA is modeled on the assumption that the cursor is a property
of the window and therefore sets the override cursors on all windows.
However, on macOS and Windows, the cursor is set per application (or
screen). On these platforms, the per window cursor setting needs
to be emulated which is a source of bugs especially for override
cursors.
Add new virtuals to QPlatformCursor allowing to set override
cursors which can be implemented by directly setting the cursor
on those platforms.
Task-number: QTBUG-40122
Task-number: QTBUG-61133
Change-Id: I31d6a927128d22bb1620a8ace35988c0e126236e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Running:
tst_qapplication focusMouseClick touchEventPropagation
produced:
FAIL! : tst_QApplication::touchEventPropagation() 'window.seenMouseEvent' returned FALSE. ()
since QGuiApplicationPrivate::mouse_buttons was not cleared
when destroying and re-instantiating QGuiApplication.
Add more initialization and clear screen list on exit.
Change-Id: I0d814852c362d4a86f1ff5d6a94ab00d32ed30b9
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
This variable was introducing during Qt 5.0 Q{Gui}Application
refactoring days (2011 or even before) and since then has been
used interchangeably with QGuiApplicationPrivate::mouse_buttons.
This patch removes the duplicate member variable as it is
redundant and could be a source of potential errors.
Initially I was thinking that ::buttons might be used for
the purpose of QTestLib, but it is not. QTestLib delivers
mouse events directly via qApp->notify() (mouse button state
is update via QGuiApplicationPrivate::mouse_buttons from notify()),
or via window system interface QWindowSystemInterface::handleMouseEvent
(which goes through QGuiApplication::processMouseEvent).
Looking at QGuiApplication, it is clear that ::buttons
and ::mouse_buttons always have the same value, as there
is only one assignment to these members in QGuiApplication:
mouse_buttons = buttons = e->buttons;
And there are no other places that would assign to
QGuiApplicationPrivate::buttons.
Change-Id: Ib60d366bf056a98b15bb4538a569693e7bd022e2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
So that any objects autoreleased during application initialization are
released. Otherwise they will end up in the root level pool and only
be released when the application exits and the application goes out
of scope.
Change-Id: If02d24fd70098f9b4b1b0ea3218e0a15e438b9db
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Add simple Win32-API based menus (not owner-drawn).
Native menus are implemented using Win32 API and are simpler than
QMenu-based menus in for example that they do allow for placing widgets on
them or changing properties like fonts and do not provide hover signals.
They are mainly intended for Qt Quick. By default, they will be used if the
application is not an instance of QApplication or for Qt Quick Controls
2 applications.
In addition, the command line option -platform windows:menus=native
will unconditionally activate them and -platform windows:menus=no
turns them off.
[ChangeLog][QtGui][Windows] Native menus have been implemented.
Task-number: QTBUG-55967
Change-Id: I439a7d949745debea3eb0e5789cf42288a0d526f
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Don't quit on Back key release when Back shortcut was accepted and
likewise for the Menu key, don't trigger the platform menubar if Menu
shortcut was accepted.
Change-Id: Ifde87cbc2d95be1beb90ca59f55889b83a90ff02
Task-number: QTBUG-59670
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The code compared a QString* with a QString, which only compiled
because the QStringRef(const QString*) ctor was implicit. We're going
to fix that, and it's nice to see that the change exposes bugs like
this one.
The fix is to deref the QString* argument, which we know from previous
checks to be non-nullptr, to enable normal QString/QString comparison.
Change-Id: Idc7b214cb26e8b7c18ee1ba0a2b7236f814f0810
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
For the windows file system engine, we add an extra macro to use
library loading if configured to do so, but avoid it on WinRT, as
none of the symbols would be found.
We also QT_REQUIRE_CONFIG(library) in the library headers and
exclude the sources from the build if library loading is disabled.
This, in turn, makes it necessary to clean up some header inclusions.
Change-Id: I2b152cb5b47a2658996b6f4702b038536a5704ec
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The previous logic relied on QPlatformWindow::setWindowState() being
synchronous and delivering the QPA event before returning to QWindow,
in which case window->windowState() would still refer to the old
state. Async platforms can now report the previous state correctly.
Change-Id: Ib9148fe23fb62be55b7e3a0ccf63d32c71dc2ad3
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The comment says "don't send event if nothing changed", but the
condition it is attached to reads if (velocityOnly), which is
totally opaque.
Change the variable name to stationaryTouchPointChangedVelocity
and drop the then-branch of the if, because it is duplicated in
the following default case of the switch.
The comment makes sense again, and GCC 7 is happy, too, because
this whole issue was pointed out by its -Wimplicit-fallthrough,
which is why I added the fall-through attribute, too.
Change-Id: I0631a381095f8897c55d9440304f6aefbc021a9a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Sérgio Martins <sergio.martins@kdab.com>
Change 333f641622 modified
QGuiApplication::topLevelWindows() to no longer include embedded windows.
This causes the blocked handling in Active Qt to no longer be triggered.
Fix this by iterating over the list using the same condition as before,
avoiding the construction of a temporary list as a side effect.
Task-number: QTBUG-18099
Change-Id: I06a1a4e324fea9f543ceb5274bb064734f8d56af
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
[ChangeLog][QtBase][General] Removed support for WinRT/Windows Phone 8.1.
Task-number: QTBUG-57288
Change-Id: Ifd6d6780cbbdb710d99556ba3d2fb2e514d4f789
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Don't block the event that Qt depends on to close popups.
This is the same fix as 5b65698248,
but for touch this time.
Task-number: QTBUG-57292
Change-Id: I47bc19883c2e2b5dc9615c12dc6c198193c055cf
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
It makes assignment a bit more succinct and efficient since they
are usually set together.
Since we store the diameters and the points separately, we
no longer need to worry about updating rects by moving their centers.
QGuiApplication and QApplication don't need to alter the diameters:
they are set once when the event is constructed.
Also fix the initialization of pressure and rotation:
418b6f6899 did it by casting a
double to qreal, whereas a plain integer constant will be
auto-converted by the compiler anyway.
Change-Id: Ib9956d2def21278b8ae042147d917da156e77e52
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
It was very confusing to debug a problem involving detached touchpoints
and not very clear how startPos is stored in activeTouchPoints.
Change-Id: I5c04fb6b5647493a731774e0a1765404cbc8c7d6
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The contact patch of a finger on a touchscreen tends to be roughly
elliptical. If we model it as a QRectF, it's not clear whether the
ellipse should be considered to be inscribed in the rectangle and then
rotated, or whether the rectangle represents the outer bounds of the
rotated ellipse. In practice, since most touchscreens can't measure
rotation, it is effectively the latter. But modeling it that way means
information is lost if the touchscreen can measure rotation: you can
determine the bounds of a rotated ellipse, but you cannot derive the
rotated ellipse from its bounds. So it's better to model the axes
of the ellipse explicitly. This has the added benefit of saving a
little storage space: we replace 3 QRectF instances, whose width
and height will normally be the same, with 3 positions (bringing the
total to 12 QPointF's) and one set of axes. Further, most applications
only care about the center of each contact patch, so it's better to
store that explicitly instead of calculating QRectF::center() repeatedly.
In the past there may have been an assumption that the width of the rect is
the same as the horizontalDiameter of the ellipse, so the rect could be
considered to be rotated, and the ellipse to be inscribed. But in
d0b1c646b4 and
40e4949674 the point was made that the rect
is actually the bounding box of the rotated ellipse.
[ChangeLog][QtGui][QTouchEvent] TouchPoint::rect(), sceneRect() and
screenRect() are deprecated; a touchpoint is now modeled as an ellipse,
so please use pos(), scenePos(), screenPos(), horizontalDiameter()
and verticalDiameter() instead.
Change-Id: Ic06f6165e2d90fc9d4cc19cf4938d4faf5766bb4
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Johan Klokkhammer Helsing
Shawn Rutledge
Tor Arne Vestbø
Lars Knoll
Andreas Hartmetz
Morten Johan Sørvig
Volker Hilsheimer
Nicolas Guichard
Michal Klocek
Andre de la Rocha
Friedemann Kleint
Jarek Kobus
Lars Schmertmann
Oliver Wolff
Andy Shaw
Qt Forward Merge Bot
Tor Arne Vestbø
Liang Qi
Lorn Potter
Yuhang Zhao
Eirik Aavitsland
Eskil Abrahamsen Blomfeldt
Allan Sandfeld Jensen
Simon Hausmann
Marc Mutz
Alexandru Croitor
Leander Beernaert
Mikhail Svetkin
Alexander Volkov
Milian Wolff
Christian Ehrlicher
Gatis Paeglis
Alessandro Portale
Timur Pocheptsov
Steve Mokris
Sergio Martins
David Faure
Jan Grulich
Giuseppe D'Angelo
Joerg Bornemann
Rafael Roquetto
Otto Ryynänen
Kai Uwe Broulik
Kevin Funk
Stephan Binner
J-P Nurmi
Ulf Hermann
Maurice Kalinowski
Paul Olav Tvete