This reverts commit 2e711e47e0fedd636af2116c56622cc7be958808.
After closer investigation, it turns out that menus in Quick before 6.8
does infact forward pointer events outside the popup to the item under
the mouse. Only if the popup is modal will this be blocked. So blocking
this from QGuiApplication will cause a difference between Popup.Item and
Popup.Window, and needs more investigation.
Change-Id: I7d21258cb8fafd7380786fed0d6370e0a9090188
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If a popup is visible, we're not supposed to send pointer events
to other windows than the popup. It doesn't matter if the popup
doesn't want it. But currently we end up doing so anyway, which
mean that we would trigger items elsewhere in the UI.
This patch will instead make sure that always return from
processMouseEvent() after sending, or forwarding, it to the
active popup.
Note: some styles in Controls (e.g macOS) has a menu window that
is actually substantially bigger than what it appears like on
screen (to make room for a drop-shadow). This means that a mouse
press can happen outside the visual borders of the menu, but still
inside the popup window that contains it. And this is also a
reason why some bugs related to forwarding of mouse events only
surfaced on some platforms (Ubuntu), but not on others (macOS).
E.g for a Menu in a MenuBar, the menu window on macOS would actually
be placed on top of the MenuBar and block pointer events from reaching
it (because of the menu shadow). While on Ubuntu, since the menu has no
shadow, the press would instead trigger the MenuItem in the MenuBar.
But by never forwarding pointer events to windows other than the
active popup, such differences will never happen.
Note: we should actually forward pointer events to the window under
the mouse if QPlatformIntegration::ReplayMousePressOutsidePopup is
set (and WA_NoMouseReplay is not set). But this API is currently not
reimplemented after QGuiApplication was refactored to support popup
windows also in Qt Quick. And ReplayMousePressOutsidePopup seems to
be false on all platforms other than Windows.
Change-Id: I55692cf2cae4c8f9e46976b105660bca96bd65e6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
(cherry picked from commit fc9af570507bf067a182ab3f1c2f51a29f59e38c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
With the introduction of QQuickPopupWindow in 6.8, much of our popup
management had to be moved from QApplication to QGuiApplication.
Most of this was done in e4ef0f03e6, but
closing popups on window deactivation and orientation changes, were
left in QApplication. This code path was used to close popups when the
user clicks outside of a window, on platforms suchs as wayland, were
QWindow::setMouseGrabEnabled(true) doesn't work properly.
As it turns out QApplication::notify() never calls
QGuiapplication::notify(), which is why I'm duplicating the code from
QApplication into QGuiApplication, instead of simply moving it.
Task-number: QTBUG-121363
Change-Id: I36bebd029a2f8e3ec0cdbab40971682cf948d438
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit 914c2ef4fb926c16e8874c9c3691401f7e22ae22)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When the list view of a QCompleter is visible, it receives mouse events.
A mouse press event outside the completer hid it.
If a virtual keyboard was active, it did not receive mouse press/release
events in case the completer's list view was active.
Add a helper to QGuiApplicationPrivate, that detects a virtual keyboard
under a mouse event position, and forwards the event if needed.
Adapt QCompleter::eventFilter() to use the helper.
If a virtual keyboard one exists and a mouse press event occurs inside
it, don't hide the completer and forward the event.
Add handling of mouse release events, and also forward them to the
virtual keyboard, using the helper.
Add logging.
Fixes: QTBUG-126752
Pick-to: 6.7 6.5 6.2
Change-Id: I613523a9c83b319810397770c43b2eb4ae01c31a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 93ce8f13fc8042eac976a3c911af7d7664e8d5dc)
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Warning messages are by default emitted for qt.* logging categories. But
neither the end user nor the application developer can do anything about
this particular warning (which gets emitted on macOS when using the
touch pad) - it's only useful for Qt developers.
So change the logging level to debug.
Pick-to: 6.7 6.5
Fixes: QTBUG-125589
Change-Id: I36e6e553494054488209139e3238b7bd11bd170a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 2b021b2f927eaabbb3b7892b3dfe35d41368cf32)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Some platforms, such as macOS, do not natively have icons in menus,
except in a few specific cases, so the default for AA_DontShowIconsInMenus
and in turn QAction.iconVisibleInMenu should be to not show the icon.
QActions with iconVisibleInMenu explicitly set to true will still show
the icon, even if the user does not override AA_DontShowIconsInMenus.
[ChangeLog][QtGui] The default value of Qt::AA_DontShowIconsInMenus is
now determined based on the platform. On macOS icons will not show by
default. To override, use QAction.iconVisibleInMenu for individual
menu actions, or set Qt::AA_DontShowIconsInMenus to false.
Pick-to: 6.7
Change-Id: Ie4fb3e6618486233d64a7818be19a42ed9a2a852
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit d671e1af3b736ee7d866323246fc2190fc5e076a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When QGuiApplicationPrivate::processTouchEvent() sees that the
touch event was not handled, and calls processMouseEvent(), the latter
uses the QEventPoint with pointId 0 regardless of the original
touchpoint ID. Now it updates the persistent QEventPoint from the
original touchpoint so that a double-click event will not be ruled out
because of the timestamp delta or position delta (movement since press)
being too large.
Fixes: QTBUG-125993
Pick-to: 6.7 6.5
Change-Id: I8e9b007818107ac2329454e0ccfb2ac9e506b617
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 2a0b907f11b9c0ad46322ba06482861423246d93)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We need to be able to have true popup windows in Qt Quick and Controls,
including handling the press-drag-release sequence to select one entry
from a menu or combobox. After the mouse press, a new window is created.
On some platforms (such as xcb), the new window gets window system grabs
of both keyboard and mouse (QApplicationPrivate::openPopup() calls
grabForPopup() and it actually works); while on others, the pre-existing
window continues to get the whole sequence of mouse events until the
release. In the latter case, Qt needs to forward events from the
original window to the popup. Until now, the list of popups was
QApplicationPrivate::popupWidgets.
Now we track the open popups as a list of QWindows rather than QWidgets,
in QGuiApplicationPrivate::popup_list, and add a set of static functions
to manage that list. Functions such as QApplication::activePopupWidget()
QApplicationPrivate::openPopup() and closePopup() are rewritten to make
requests to QGuiApplicationPrivate.
276943c8b7 made
QGuiApplicationPrivate::closeAllPopups() virtual. That is now reverted,
because we're putting QGuiApplication in charge of popup management
and trying to minimize widget-specific behavior. So far,
QApplicationPrivate::closePopup() is still overridden to take care
of focus changes.
So far, QtGui does not take care of closing popups when the user
clicks outside: the active popup window gets those events, and needs
to close itself if the click occurs outside. An attempt to move this
logic raised some issues with legacy widget test cases.
Using a touchscreen to press on QMenuBar and open a QMenu, drag to
a menu item and release, is temporarily broken for now. The plan is
to fix it in a subsequent patch.
Task-number: QTBUG-68080
Task-number: QTBUG-69777
Change-Id: I02b5034987b5ee8909917d305f414c8b0db9c7f5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The QNativeInterface::QVisionOSApplication interface allows opening
and dismissing an immersive space, as well as registering a compositor
layer implementation that can be used to configure the compositor
layer and render to it with Metal.
The compositor layer implementation is consulted both for immersive
spaces triggered explicitly, and when the default scene of the app
is set to CPSceneSessionRoleImmersiveSpaceApplication via the
UIApplicationPreferredDefaultSceneSessionRole in the Info.plist.
All of this requires that the application follows the SwiftUI app
lifecyle, so our application entrypoint is now a SwiftUI app. The
existing qt_main_wrapper used for the QIOSEventDispatcher handles
this transparently, so there is no change for the user, who will
still receive a callback to main() when the Swift app is ready
to build its UI hierarchy.
Change-Id: Ic295010d714e90cd4d3f66bd90f321438659f3a6
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Add Qt::ContextMenuTrigger enum used with
QStyleHints::setContextMenuTrigger() to override default platform
behavior when to trigger context menu event.
The default is to show context menu on mouse press on
UNIX systems and on mouse release on Windows.
Give developer a possibility to override platform default behavior
to make cross platform application that behaves the same way on all
platforms
Task-number: QTBUG-93486
Change-Id: Ic832d3d8a7c355a8adb46868fff9cfd19988cf3c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The code polshing palettes needs to be able to rely on an updated
value of the color scheme as reported by the QStyleHints, otherwise
styles might apply the incorrect polishing logic.
Update the style hints as part of processing theme change handling,
and do it as the first thing, before updating the palette.
Pick-to: 6.7
Task-number: QTBUG-124490
Change-Id: I393faa57ecfa6da94497ae93a4e8b5d2782ec42a
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
Use the platform theme or QStyleHints instead.
Task-number: QTBUG-124490
Change-Id: Iab12faa726d3031d6a250664468dac333c2c2e0c
Reviewed-by: Doris Verria <doris.verria@qt.io>
As part of df359bcb70 the semantics and
interaction between QEventLoopLocker and QGuiApplication was changed,
based on the assumption that these two mechanisms were independent
and should not affect each other.
This had a surprising regression where the use of QEventLoopLocker in
combination with the QCoreApplication::isQuitLockEnabled() automatic
quit would end up quitting the app, even if it had open windows, for
example when the last job of some internal job queue finished.
It could be argued that if the app has open windows that should not
be closed, they should ignore the Close event, and that an application
with running QEventLoopLocker jobs should maintain an active window
showing the progress of those jobs, but still, this is regression
that we want to fix.
We now bail out if !lastWindowClosed() in QGuiApplication's
canQuitAutomatically, which is triggered from QEventLoopLocker's
isQuitLockEnabled() behavior. And we do so regardless of whether
quitOnLastWindowClosed is set or not, as the latter property
determines the behavior when closing a window, not the behavior
when a QEventLoopLocker goes out of scope.
Similarly, we now block quitting of the application when triggered
by quitOnLastWindowClosed() if a QEventLoop is active, regardless of
the isQuitLockEnabled(), as the latter property is determining
whether we should trigger a quit, not whether we should block them.
[ChangeLog][Important behavior changes] Fixed a regression where
the last QEventLoopLocker going out of scope would quit the app,
even if there were open windows, if quitOnLastWindowClosed was
false.
[ChangeLog][Important behavior changes] Fixed a regression where
closing the last window would quit the app, even if there were
active QEventLoopLockers, if isQuitLockEnabled was false.
Fixes: QTBUG-124386
Pick-to: 6.7 6.5
Change-Id: I84fd0ddea78a2f417f3a17b326113c880079cf85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The current QStyleHintsPrivate::setColorScheme is called when the system
theme changes, handling the change and informing the application. It is
not a setter. When we add a public setter, that setter will have to go
through the QPlatformTheme to request an override for the application.
That will then result in a call back to the QStyleHints to update the
theme with the effective color scheme (or ignore the request for the
override, on some platforms).
Rename it (and similar misleading APIs in platform plugins) to
updateColorScheme, and adjust outdated comments in some of the platform
plugins.
Task-number: QTBUG-124490
Change-Id: I6a852211254993df86acf2e2d42cf345e7401f4f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
The rounding policy is used to calculate QScreen geometry
during startup. Changing it afterwards is not supported
since we don't have an update mechanism.
This restriction is already documented but printing
a warning makes sense since this is easy to miss.
Fixes: QTBUG-123102
Change-Id: Ib88511e61abbf97436a13dc5d38d3d1fbd5aab2c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The EventPointMap QPointingDevicePrivate::activePoints is actually a
QVarLengthFlatMap<., ., 20>, not 16, so copy the value instead of just
hard-coding something.
Amends 296ede3aab.
Change-Id: Ic8e83f4095f57be74f7708d5cec6a19971772b76
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Clang's `-Wimplicit-fallthrough` warnings are a little stricter than
gcc's interpretation:
switch (i) {
case 0:
foo();
case 4:
break;
}
While gcc accepts the implicit fallthrough, if the following statement
is a trivial `break`, clang will warn about it.
Pick-to: 6.7
Change-Id: I38e0817f1bc034fbb552aeac21de1516edcbcbb0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The number of windows in a windowing system is clearly small, even
smaller the number of windows that should be affected by a single
touch event, so QSet is overkill. Use the recently-added
QMinimalVarLengthFlatSet instead, backed by a QVLA<16>. Even though
insertion and lookup are now logarithmic instead of constant-time, the
saved memory allocations will make up for it.
Change-Id: Ie33ecf4a155e58db597c67ed9c78549255c48b99
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The GDI font backend is missing support for certain modern features,
and has a lot of work arounds for missing APIs. DirectWrite is the
modern way to handle fonts on Windows, so we make this the default
now, but keep the old backend as a fail safe.
Fixes: QTBUG-119420
Change-Id: I0ea5cdfdcd759ccc894efb01b2410826c44aa1ea
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
Using the presence of the wayland-client lib as a condition.
Fixes: QTBUG-117386
Change-Id: If4336965ea06e3f4b06e9af661efdec38ba46136
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A single QWindow is QGuiApplication::focusWindow() at a time, and this
window is typically also QWindow::isActive(), but other windows may also
be QWindow::isActive(). For example, we treat any sibling or ancestor
of the focusWindow as being QWindow::isActive() as well.
In addition, in the case of non-QWindow child windows, we may have to
query the platform for the activation state, which means we also need
a way for the platform to reflect changes in this state through QWSI.
The current API for this, QWSI::handleWindowActivated, is in practice
a focus window change API, so as a first step let's rename it to better
reflect what it's doing.
Task-number: QTBUG-119287
Change-Id: I381baf8505dd13a4a829c961095a8d2ed120092b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
There is no need to run the catch-all DPR update if
the window is not visible.
Pick-to: 6.6
Fixes: QTBUG-117762
Change-Id: Ib4e235fed4b21e5aa2ecafa960ab0900e2b68295
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QGuiApplicationPrivate::processMouseEvent() requires the following
conditions to be met in order to trigger a double click event:
1. The same button should be pressed (kept in mousePressButton member)
2. The time between two press events should not exceed doubleClickInterval
3. Movement between presses shouldn't be bigger than doubleClickDistance
Unfortunately, when we are processing *synthesized* mouse events (from
touch), in order to check criterion 2) we cannot rely on
QPointingDevicePrivate::pointById(0)->eventPoint.pressTimestamp();
because this was already updated in QGuiApplication::processTouchEvent(),
so it does not any longer reflect the *previous* press timestamp, but
the current one.
Therefore we could not reliably calculate the time between the previous
press and the current press (in fact, it never exceeded the
doubleClickInterval condition)
I suspect this occurs with all touchscreens, but at least it was
reproduced with e.g. a NVIDIA Terra / Thinkvision touch screen on
Windows 11 and Dell Express SVC touch screen on Windows 11.
=> Since QGuiApplication is a singleton, add a static local variable to
remember the time stamp of the last processed press event.
Autotesting has been modelled in PS7. However, QTest::touchEvent is
unable to synthesize hardware specific detection latency and stray
touch events, which actually reproduce the issue.
=> Not adding an autotest.
Fixes: QTBUG-112479
Fixes: QTBUG-119032
Fixes: QTBUG-100688
Pick-to: 6.6 6.5
Change-Id: Idc97fb9d49ed334f56d702d420451fc062e9b5a9
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Under some circumstances (e.g. setDesktopSettingsAware(false) on
windows) it may happen that the call to platformTheme::palette() returns
a nullptr which is not checked before dereferencing the pointer.
Therefore add a check for this to avoid a crash.
Fixes: QTBUG-111527
Change-Id: I6443d5d1a9b813f499d8f65b4fee55b0b8299b16
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The QKeyMapper class never got a platform integration companion.
As we might be adding more functionality here in the future, let's
fix that now, instead of adding more hooks directly to the platform
integration class.
The QKeyMapper will soon update its possibleKeys signature to
return QKeyCombination, but for now transform the result.
Change-Id: I88ef498180b2a8a7937a74627b7eb6b5156e872a
Reviewed-by: Liang Qi <liang.qi@qt.io>
The platform plugin should already DPR (or DPI) change
events, however if that does not happen we update in
the expose event as well as a last resort to make sure
the window's DPR value is in sync.
Also print a warning and ask for a bug report.
Pick-to: 6.6 6.0
Change-Id: Ibb144f163281a28216c2fa3353ed50237e91ce25
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
normally because new depedency of xcb-cursor0 or libxcb-cursor0 is
missing.
Pick-to: 6.6 6.5
Task-number: QTBUG-108796
Change-Id: I040e9c0932bbf1f9026b365ded462c7373b219b5
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
processWindowScreenChangedEvent() returns early if the
screen for the (top-level) window has already been updated,
for instance by a call to handleScreenRemoved(). This was
preventing us from updating the DPR and window geometry.
Move the code a slot connected to QWindow::screenChange,
which gets emitted for all windows (also child windows),
whenever the screen changes.
Pick-to: 6.6
Fixes: QTBUG-116232
Change-Id: I44701fd001ab1fd54efe9c8451c6a58cfc0b285f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Calling this function before we had a QGuiApplication instance, would
return an empty string, even if QT_QPA_DEFAULT_PLATFORM_NAME was defined
at compile time. We now return the default platform name
[ChangeLog][QtGui][QGuiApplication] QGuiApplication::platformName
now reports the default platform name if QGuiApplication hasn't been
instantiated yet. It used to return an empty string.
Pick-to: 6.6 6.5
Change-Id: Iffe7cde8943ed2d186bc494d0920b9cf79389dd0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Replace if-block with early return on null QWindow.
Pick-to: 6.6
Task-number: QTBUG-116232
Change-Id: Iaf402edfd9b03734b64fdf707834fa92c827a1dc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Setting color scheme before handling theme change provides incorrect
palette color when user switches from light to dark or dark to light.
This is visible when using Fusion style (or other style that supports
dark mode) in Windows. The change has been made as part of patchset
787038bb1d.
It also has to be noted that handling palette changes to make further changes to the palette (or the style sheet), is less likely than
Handling the colorScheme change signal and in this sense, this patch set
can also be considered as an improvement.
This patchset reverts that change and updates color scheme after palette change in the application.
[ChangeLog][QtGui][ColorScheme] Update colorScheme property after
palette change.
Fixes: QTBUG-112653
Pick-to: 6.5 6.6
Change-Id: I71bc413c56663fefdf9fe5871bbb19b7e6c3d9ff
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The GTK platform theme (and possibly others) emit theme change
when the named icon theme changes, but that was not propagated
to QIconLoader.
We now call QIconLoader::updateSystemTheme(), but note that
if a user theme has been set we ignore the system theme update
and will end up with a stale value, even if the user theme is
later cleared. This will be fixed in a follow up commit.
Pick-to: 6.6 6.5
Change-Id: I40b537f3618f44d396db0c7ca67e515dfcdfba44
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The desktop file name should not contain ".desktop" suffix, but some
applications still specify it anyway because of the ambiguity in the
documentation that was fixed in
0c5135a9df.
This change makes setDesktopFileName remove ".desktop" suffix so
desktopFileName always returns a desktop file name with correct format
and its users don't need to chop ".desktop".
Pick-to: 6.5
Change-Id: If5abccaf3bf976449cada8891fff887870e45b5f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Whislt the documentation says "base name" there are lots of examples in
the wild of clients using the wrong name here. Writing it explicitly
might help.
Task-number: QTBUG-75521
Pick-to: 6.5
Change-Id: Ic17ca161cf58449e85e25d9b6b8ace44fe14f18a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Propagate the accepted state from the QtGui event to
the QWindowsSystemInterface event. This makes it possible
for the platform plugins to propagate rejected wheel events
to the native OS.
Pick-to: 6.5
Task-number: QTBUG-107441
Change-Id: Ifa90ed2430e56120a1a04b6a5872a153d26aa6bc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
During QCoreApplication initialization, we create the main thread's event
dispatcher, which for a GUI app happens via QGuiApplicationPrivate's
createEventDispatcher() override. This in turn relies on the platform
integration to create the event dispatcher, but to do that it needs to
create the platform integration first. And this might result in calling
APIs that themselves initialize the main thread event dispatcher, such
as QEventLoop, which non-lazily creates an event dispatcher for the thread.
We already had a check to catch the platform integration setting the
QCoreApplictionPrivate::eventDispatcher member, but not anything for
checking the current thread data.
On macOS this resulted in a leak of QEventDispatcherUNIX because
QCocoaDrag contained a QEventLoop member. We now track the event
loop temproarily via a pointer instead, like we do in other places.
An alternative fix would be to defer the initialization of QCocoaDrag
until QCocoaIntegration::drag() is called, but that would run the
risk of something calling the function during platform initialization
and we'd be back to the same problem.
It's unclear why QEventLoop is not lazily ensuring the event dispatcher,
and this might be a wider fix for similar issues.
Pick-to: 6.5
Change-Id: I643010ddb09945936ce9b0b94de0df96f6fe218f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Drive-by change: use QByteArrayView instead of allocating a QByteArray.
Change-Id: Iaf7acbbdb4efbb101b73b30061ce38dd1fa99ca3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The window device pixel ratio may change when the DPI
changes. Call the DPR update function, which will poll
for the current value and update the cached value and
send DevicePixelRatioChanged events if needed.
Change-Id: I5d5ac5d24a693d06eb9b1f005a91677e703f8a58
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Make each QWindow instance cache the current DPR value.
This will make calling QWindow::devicePixelRatio() less
costly, since it now does not have to compute the DPR
value on each call.
The cache is invalidated when the DevicePixelRatioChange
event is sent. The common logic for handling this is
implemented in QWindowPrivate::updateDevicePixelRatio().
Change-Id: I97231a230347358d8e565d2fd62e8a398adaedfc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since Qt 6, qIconCache does not store null icons. In case an icon name
lookup is unsuccessful, the (expensive) lookup is repeated each time.
This patch reverts 9e7c567050, which
removes a null icon from the cache once it has been found in the cache.
In fact, that could no longer happen due to
4dc7102c84, which prevented null icons
from being cached at all. Therefore, it is also reverted by this patch.
The cache will be cleared when
- the system icon theme name changes or
- QGuiApplicationPrivate::processThemeChanged is called (e.g. due to
a change of the system's color scheme)
Fixes: QTBUG-112257
Pick-to: 6.5
Change-Id: I80cd21fa39dc31c4bae60a8e66e78d9da20e9b4b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This use the unity launcher specification which is defined here
https://wiki.ubuntu.com/Unity/LauncherAPI
This spec is used by Plasma and Unity. On other Linux desktop platform
where the unity DBus interface is not detected this is no-op.
Change-Id: I81a9b95fe4886ad597bb4e775641926b161c49a5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Since 68de00e0d4, the check doesn't work
with flatpak versions lesser than 1.13.1. Checking the file in the root
directory works since flatpak 0.6.10.
Pick-to: 6.5 6.2
Change-Id: Icc83ea5de4a962b52a737c9842248df3b60b1331
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make it easier to find the function that actually gives focus to
windows that need it.
Pick-to: 6.5
Change-Id: I0586b89b42a1be260e36e166c81b686e394d8b5e
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
If a window is blocked by another modal window, and we decide that as
a result we should not propagate the close event, we need to also
report this back to the platform plugin, so that it can tell the
operating system to not close the window.
This is a problem on macOS, where the system doesn't natively support
transient parents being blocked by a window-modal window, so the OS
will still allow interaction with the title bar close button, resulting
in a QWSI close event being delivered.
Fixes: QTBUG-104905
Pick-to: 6.5 6.2
Change-Id: I09ff15b0fbb1002a8f9d83d932ca766ed510f0a0
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Richard Moe Gustavsen
Oliver Eftevaag
Axel Spoerl
Volker Hilsheimer
Tor Arne Vestbø
Shawn Rutledge
Allan Sandfeld Jensen
Volodymyr Zibarov
Morten Sørvig
Marc Mutz
Ahmad Samir
Tim Blechmann
Eskil Abrahamsen Blomfeldt
David Redondo
Jan Arve Sæther
Christian Ehrlicher
Liang Qi
Anton Kudryavtsev
Pasi Petäjäjärvi
Santhosh Kumar
Ilya Fedin
Vlad Zahorodnii
David Edmundson
Tasuku Suzuki
Wladimir Leuschner
Carl Schwan
Mitch Curtis