Cache the return value of QIBaseResult::record() to avoid the recreation
(e.g. when using QSqlQuery::value(QString) instead index-based ones).
Change-Id: I88568d99ba96e19ae6b661d058e7709ebc5ef2a2
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 71880c018fe98854948a6c7dd9049e4ba0ddb8e6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... instead Q_CC_MSVC to be in sync with qlocale_tools_p.h and avoid
compiler erros when used with msvc versions not providing int128
support.
Change-Id: Ia2166a6260a9340a5e5bbca3f46c3b77a9f8d50d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 694ce1772db45d115ad02019a46ad2db4c3abeab)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The previous patch missed the handling of SQL_INT128 in
qIBaseTypeName2().
This amends 373ae6cbd2
Change-Id: I646bd5af23c14761195f9c1089dc4cbbe2e94790
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Andreas Bacher <andi.bacher@outlook.com>
(cherry picked from commit f6bb8f832442a2e70b3d4718fb06807cfe98511b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Based on the documentation, the numeric keypad key 5 is commonly mapped
to Qt::Key_Clear, when Num Lock is off. Previously the number 5 was
returned also when the Num Lock is off which caused an ui application
being unable to disable the numpad key number 5 when numlock is off.
Fixes: QTBUG-125958
Pick-to: 6.7 6.5
Change-Id: I62f7521376890a201cd11abf78847bcb0eb1752a
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
(cherry picked from commit cc89c4c76567184b2887952dfe44375ff3ebd28d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Do not try to access non the existent input element when there is no touchscreen,
as we do not use it in that instance.
Fixes: QTBUG-125120
Pick-to: 6.7 6.7.1
Change-Id: Iedac1890d13b348ef12690947779347e3c2f8476
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
* Unify the default identifier creation for QAccessibleInterface on
all platforms to be the same as the previous identifier on Linux.
This may change some identifiers on Windows.
[ChangeLog][QAccessible][QAccessibleInterface] Add possibility to
add unique identifier to QAccessibleInterface to give a11y elements
consistent identifiers.
Task-number: QTBUG-123361
Change-Id: I8c42956a4c497e71909d71dcb27bc87433937b69
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When our Metal layer changes its bounds or contents scale, for
example as a result of a window resize, or moving a window between
screens of different device-pixel-ratios, the layer will be marked
as needing display.
The changes to the layer will then make their way to the screen
as part of committing the root level CATransaction, managed by
the macOS display cycle, which synchronizes the presentation of
the bounds or scale changes to the screen's vertical sync.
By default, presenting a Metal drawable to a Metal layer ignores
any ongoing transactions, so the drawable ends up on the screen
as fast as possible. The downside to this is that the drawable
size or scale may be based on the yet-to-be presented bounds or
scale changes of the layer, as these happen when the display
cycle commits its transaction.
To ensure that the layer properties and content changes in lock
step we can enable the presentsWithTransaction property on the
Metal layer. We do so selectively when the layer is asked to
display, which happens during the display cycle, but not for
update requests (via our display-link).
This would normally be enough to ensure smooth and glitch free
resizing, as long as everything happens on the main thread.
Unfortunately, the [MTLCommandBuffer presentDrawable:] API we
use to present a Metal drawable when rendering in response to
update requests is actually scheduling the presentation on a
secondary thread com.Metal.CompletionQueueDispatch queue. The
result of this is that the presentation on the secondary thread
might race against a presentation on the main thread initiated
from the display-cycle, presenting too early, or overwriting
the layer's content with stale content.
To fix this we use [MTLCommandBuffer addScheduledHandler:]
explicitly instead, which lets us control what happens during
the presentation on the secondary thread. We then add a lock
to the layer that we lock as soon as the layer needs display,
and use this lock to skip presentations that should not step
on the toes of the display-cycle presentation. Once the display
cycle ends we unlock the lock.
The lock is a read-write lock, to ensure we prioritize the main
thread's display-cycle over any other presentations in case of
contention. We also defer update requests if we detect that the
lock is held, as there is no point in rendering a frame if we
are likely not going to present it. Doing this also prevents
the update-requests from starving the main thread from getting
its drawables.
The final case we have to account for is where the display
of the layer during the display-cycle is implemented by asking
another thread to do the rendering, as is the case with the
Qt Quick threaded render loop. In this case the main thread
is blocked while it waits for the render thread to complete
drawing and presenting a frame. But the actual presentation
of the Metal drawable still has to happen on the Main thread
for it to be part of the display-cycle's transaction.
To ensure the latter, we move the presentation of the drawable
to a block, that we schedule to be run on the main thread. Once
displayLayer is done with the expose event it processes the
deferred presentation, on the main thread.
Finally, to mitigate Qt Quick's threaded renderer running
animators without any coordination with the main thread, and
thereby starving it from drawables, we expose the inLiveResize
property on QNativeInterface::Private::QCocoaWindow, so that
the threaded render loop can step back during live resizing
and drive animators via the main thread's update request.
The QT_MTL_NO_TRANSACTION environment variable has been
kept, as an opt-out in case the new machinery breaks somehow.
It will disable the locked Metal layer, and all code paths
that depend on it.
[ChangeLog][macOS] Metal layers are now presented with
transactions during the display-cycle, which should fix
issues with the layer's content being out of sync with
the layer bounds or scale. If this causes issues, set the
QT_MTL_NO_TRANSACTION environment variable to opt out.
Fixes: QTBUG-107198
Fixes: QTBUG-114351
Change-Id: I765e11051c3a4d44b60ff10e787589feec8917a0
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
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>
For compatibility reasons, QPaintDevice needs to query subclasses for
device metrics as int values. To report fractional DPR values, they
have been multiplied with a large constant and divided back
afterwards. However, the loss of accuracy introduced by this, though
tiny, could still lead to rounding errors and painting artefacts when
the values where multiplied up for large coordinates.
Avoid this issue by adding a metric query that transports the full
floating point value encoded as two ints.
[ChangeLog][QtGui] Added new QPaintDevice metrics for querying
fractional device pixel ratios with high precision. Custom paintdevice
classes that support fractional DPRs are recommended to implement
support for these queries in metric(). Others can ignore them.
Fixes: QTBUG-124342
Change-Id: Ia6fa46e68e9fe981bdcbafb41daf080b4d1fb6d7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
With WinUI3 a new layout of the lineedit and buttons was introduced. The
buttons are now aligned horizontally instead of vertically. Trying to
mimic that layout in widgets results in too few space for the text in
the lineedit. This patch increases the minimum width when using the
QWindows11Style for QAbstractSpinBox elements and saves the original
width in a property in case the style is changed at runtime to restore
the original geometry.
Fixes: QTBUG-124235
Fixes: QTBUG-124150
Pick-to: 6.7
Change-Id: I8067b338fa4a2c1efd0a1b0644fb8a563601385b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We reflect both the NSView's own safeAreaInsets as well as the screen's
safeAreaInsets mapped to the view. This covers both in-window views that
obscure the view, e.g. toolbars or the titlebar, as well as areas outside
of the window that affect the window if it has geometry that overlaps
these areas (such as the notch on MacBook Pro laptops).
Fixes: QTBUG-125372
Change-Id: I17af7f456ade83eef910ef5b0eaeab7cd8075263
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We were only handling the case where uri-list was a file.
This fixes a regression.
Also - add dragging url into the clipboard manual test
Pick-to: 6.7 6.7.1
Change-Id: Ifbd087ffd157463b6b903199e3ff22c2de1c4942
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
QMimeData::retrieveData() checks whether the returned QVariant value is
valid, i.e. the variant contains some data. If the variant contains an
empty QByteArray, it will be considered valid.
So retrieveData_sys() should return QVariant() in case data with the
specified mime type cannot be retrieved.
Fixes: QTBUG-125531
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: I0a668ca7ad5b2c5430335e8554cc597747287173
Reviewed-by: Liang Qi <liang.qi@qt.io>
This patch enables the handling of spatialEvents from SwiftUI. Since
these events do not have ObjectiveC structs, for now we serialize them
to JSON and pass them to Qt for usage later in Spatial applications.
These events just cover the built-in gestures like pinch "clicking"
etc.
Change-Id: I8368683259eb64277083cf345ca3a5ed9af32ecf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When we use GetWindowPlacement, the showCmd parameter will NOT be
SW_HIDE, even if the window is hidden. To prevent showing a hidden window
with SetWindowPlacement, change showCmd if the window is currently hidden.
Amends 21e4116874
Fixes: QTBUG-120415
Pick-to: 6.7
Change-Id: Ib7de369a6d1a530fdeb5ff930097ae06e25761f3
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Zhao Yuhang <yuhangzhao@deepin.org>
Drag-dropping and image from for example photoshop didn't work in Qt6
due to a (probably?) copy paste error in the commit
8fa91c75ad
Pick-to: 6.7 6.5
Change-Id: I18dedc09596fe590e915e3aa526131f2d6957d8b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Implement partial support for SQL_INT128 datatype which is used for
DECIMAL/NUMERIC columns with a precision > 18. This support is only
available when QT_SUPPORTS_INT128 is defined and for MSVC.
Binding values to columns which need SQL_INT128 is supported but
numbers given as QString will be converted to doubles even if
QSql::HighPrecision is set.
[ChangeLog][SQL][IBASE] Added support for SQL_INT128 datatype.
Task-number: QTBUG-124575
Change-Id: If3fb1eb0f19dc60f000d163f3bf45da7acb08c87
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andreas Bacher <andi.bacher@outlook.com>
This prevents e.g. gtk3 platformtheme from hanging.
Pick-to: 6.7
Change-Id: I68593ad54fa5530366d590309c10621e5a48bd22
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Updated Gradle to 8.7
Updated AGP to 8.4.0
Updated same versions in examples and docs macros
Task-number: QTBUG-113383
Change-Id: Ib2e841f2e57e576c5d689a208a275ce5e9e4b80f
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When connecting to an old Firebird instence with a Qt Firebird plugin
linked against Firebird >= 4 the timezone table is not available and
therefore open() will fail. Therefore downgrade the non-existence of
this table to a qCInfo().
Fixes: QTBUG-125467
Change-Id: Iae6d110bc2a48b5b90ffb9cb38f3fba60f30770f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Andreas Bacher <andi.bacher@outlook.com>
Bump the minimum supported Android API from 23 to 28 i.e.
Android Oreo 9. This is done to focus more and more on
recent versions.
Fixes: QTBUG-125023
Task-number: QTBUG-124890
Change-Id: I4d510b771f413e5711dd44de454211e019c63db6
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
We weren't handling it at all, emscripten already supports it.
Fixes: QTBUG-125222
Pick-to: 6.7
Change-Id: I761eed2c8c034604cd02ba436db68cec4fdeb784
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This bridges the 2 currently existing attribute types for
the newly added QAccessibleAttributesInterface to UIA.
As described in the AT-SPI bridge implementation already,
QAccessible::Attribute::Level semantically matches
the "aria-level" ARIA attribute, and is mapped to
a "level" property for the UIA_AriaPropertiesPropertyId
as described in the Core Accessibility API Mappings
specification for both, headings [1] and non-headings [2].
Map all attributes set in QAccessible::Attribute::Custom
to that property as well, keeping key and value as they
are.
As described in the UIA Element Properties Identifiers
doc [3] for UIA_AriaPropertiesPropertyId:
> AriaProperties is a collection of Name/Value pairs with
> delimiters of = (equals) and ; (semicolon), for example,
> "checked=true;disabled=false".
In addition, if the level attribute is set for an object
of role heading, report the corresponding
StyleId_Heading for UIA_StyleIdAttributeId, as also
described in the Core Accessibility API Mappings spec [1].
For MingW, add UIA_StyleIdAttributeId and
StyleId_Heading<NUMBER> defines
to qwindowsuiautomation.h, as the MingW headers
apparently don't have them yet (see log of
failed MingW builds without those defines: [4] [5]).
[1] https://www.w3.org/TR/core-aam-1.2/#ariaLevelHeading
[2] https://www.w3.org/TR/core-aam-1.2/#ariaLevel
[3] https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-automation-element-propids
[4] 051e46739b/build_1716364832/log.txt.gz
[5] b8e6241678/build_1716370445/log.txt.gz
Fixes: QTBUG-119057
Change-Id: I00b15e95c35c0f31ba34161bc061a3085fc28682
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Even if dark mode has been requested by the application explicitly,
a style, like the Vista style, might polish the palette to be light.
In that case, the frame should be light as well.
Amends 95d4e6baba.
Task-number: QTBUG-124490
Change-Id: I7ddb0a80a5f043e98cf184537bffe75e917c3d38
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When creating a QWindows11Style with QStyleFactory::create() the current
colorSchemeIndex and highContrastTheme usage is not set. Those values
are now queried and set also in the Constructor of QWindows11Style.
Fixes: QTBUG-124524
Pick-to: 6.7
Change-Id: I42a3aa5bafb0ff4193b8644ac1895a78b8c82120
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Since the new functionality interface feature has removed all calls to
qtActivityDelegate, this is no longer needed.
Task-number: QTBUG-118874
Change-Id: Ibf65f953be8c4694b543610b405b65b91f3ec9ee
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Interface for input-related actions, based off of QtInputDelegate.
Implements all the QtInputDelegate functions called from native code
plus an extra function that allows the native side to get a
QtInputConnectionListener object for QtWindow creation.
Removed some unused functions and unmarked @UsedFromNativeCode in some
that are no longer called from native, but still used from java.
Added QtInputConnectionListener null checks in QtInputConnection, due
to the possibility of a non-existent InputInterface returning a null
QtInputConnectionListener for the QtInputConnection constructor.
Task-number: QTBUG-118874
Change-Id: I8d4cde3e0c735471d0fa30d16db20eb13542cdaa
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Small interface, just for QtLayout. This is used in
QtAndroid::qtLayout(), which is called by functions handling the
virtual keyboard and the keyboard handles.
Task-number: QTBUG-118874
Change-Id: Ib9b2830136d05dfd70c9c6ca86ac29be36cc5c30
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Implements interface for context menu in QtActivityDelegate and
QtEmbeddedDelegate.
Task-number: QTBUG-118874
Change-Id: I799ad1aca4beb789b87830b720abf0963ca09274
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
This will provide the JNI API used by QtAndroidAccessibility namespace
via QtAndroid namespace.
Removed unnecessary functions like createAccessibilityDelegate from
QtEmbeddedDelegate, moved the interface extension to where it is
actually supported: QtActivityDelegate.
Until now, QtActivityDelegateBase has called the QtEmbeddedDelegate
implementation on createAccessibilityDelegate() in order to create a
QtAccessibilityDelegate - which has not actually created the delegate -
and then done a null check before trying to call the - always null -
QtAccessibilityDelegate member.
The embedding and service-embedding usecases are now dealt with via the
interface validity checks on the C++ side, until an actual
implementation for those is completed.
Task-number: QTBUG-118874
Change-Id: Iea3db0e17ae80c0443e9027bdfe36bba311eed2b
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Add QtWindowInterface interface, to access native functionality related
to windows.
QtActivityBase now follows QtNative.onAppStateDetailsChanged in order
to register and unregister functionalities of QtActivityDelegate.
Task-number: QTBUG-118874
Change-Id: Ifad33bd7aac7683081f026f0591ef496909be095
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This class will be used by java delegates to register their supported
functionalities to the Qt/C++ side.
It registers two native functions: register- and
unregisterBackend, which will be used by the aforementioned
delegates.
It will be used by C++ classes which currently use
QtAndroid::qtActivityDelegate() to access a JNI object which implements
all these features in one big class.
Task-number: QTBUG-118874
Change-Id: I23a7e433104c20b96c08b682a96cfaec98ecb4a9
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Since the change to use compose render-to-texture widgets through QRhi,
the RasterGLSurface is not existing anymore and it was used in QNX QPA
to check the support for using backingstore with non-raster windows.
With the use of QRhiBackingstore the QNX QPA now supports
render-to-texture widgets for non-raster surface windows.
Fixes: QTBUG-114938
Task-number: QTBUG-114938
Pick-to: 6.5 6.6 6.7
Change-Id: I01d4a34efe4902a527051776b0460ccf22e5d232
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Marianne Yrjänä <marianne.yrjana@qt.io>
Use new term in examples, code comments, error messages and and mime types.
Task-number: QTBUG-122253
Change-Id: I355452d6eb02a7a0ffbb20acf82ddb8ebbfa4837
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The QWindowsScreenManager's m_displayChangeObserver window would still
be alive at the time ~QWindowsContext would unregister window classes,
resulting in a warning that was hidden by the default verbosity of
QWindowsContext::verbose. The result was that we would get a warning
when then trying to re-register the already registered window class.
We now do what we do for m_powerNotification and m_powerDummyWindow,
which is to destroy them explicitly before unregistering their class.
Fixes: QTBUG-125058
Pick-to: 6.7 6.5
Change-Id: Id3b02237fdd81f734a58a2314a157cad1289a82c
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Parse the -qpa configure argument as list and translate it to the
QT_QPA_PLATFORMS cmake variable. This variable is new to the Qt build
procedure. The QT_QPA_DEFAULT_PLATFORM variable supposed to get
multiple values, but this didn't work at all, since the variable value
then was used in the compile definition that is expected to be a single
value QPA platfrom definition. This inconsistency forced to introduce
a new variable.
The QT_QPA_DEFAULT_PLATFORM variable now controls the first-choice QPA
plugin for the GUI applications. The new configure argument
-default-qpa is now translated to the QT_QPA_DEFAULT_PLATFORM variable
instead the of -qpa one. The -qpa configure argument is now translated
to the QT_QPA_PLATFORMS variable, which is new one as well. The
variable contains the list of QPA plugins that are "default" for this
Qt configuration. The meaning of the "default" plugins is related to
the DEFAULT_IF argument of qt_internal_add_plugin command. Plugins
that are listed in the QT_QPA_PLATFORMS variable will be treated as
default by the build system and will be deployed within user
applications when using deployment API or linked statically when using
static Qt.
The QT_QPA_DEFAULT_PLATFORM falls back to the QT_QPA_PLATFORMS first
value in the list if it's not set explicitly and either
'-DQT_QPA_PLATFORMS' or '-qpa' arguments are specified.
[ChangeLog][CMake] Added QT_QPA_PLATFORMS variable which controls the
list of QPA plugins that will be deployed within the applications by
default.
[ChangeLog][CMake] The '-qpa' configure argument now is mapped to the
QT_QPA_PLATFORMS variable and has different functionality. It doesn't
control the platform plugin that the GUI application is using by
default, but controls the list of QPA plugins that will be deployed
within the applications by default.
[ChangeLog][CMake] Added '-default-qpa' argument which replaces the
'-qpa' one. The argument is translated to the QT_DEFAULT_QPA_PLATFORM
CMake variable and selects the default platform that should be used
by GUI application if QT_QPA_PLATFORM environment variable is not set.
Task-number: QTBUG-124265
Task-number: QTBUG-87805
Task-number: QTBUG-124449
Change-Id: Ibcebaccc535aaed6374f15ccfeddb3e6128f5ce0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
WinUI3 changed the behavior of Sliders by not using steps anymore but
by absolute change.
Fixes: QTBUG-125154
Pick-to: 6.7 6.7.1
Change-Id: I708f2584432b277b0c1fc0b2587137ce71714e69
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Bridge the newly added QAccessibleAnnouncementEvent on macOS
by calling NSAccessibilityPostNotificationWithUserInfo with
param NSAccessibilityAnnouncementRequestedNotification [1] and
a dict containing the message and priority as data.
Post the notification on the application element, as the
comment for NSAccessibilityAnnouncementRequestedNotification
in the NSAccessibilityConstants.h header says:
"This notification allows an application to request that an announcement be made
to the user by an assistive application such as VoiceOver. The notification
requires a user info dictionary with the key NSAccessibilityAnnouncementKey and
the announcement as a localized string. In addition, the key
NSAccessibilityAnnouncementPriorityKey should also be used to help an assistive
application determine the importance of this announcement. This notification
should be posted for the application element."
This makes the announcement from the example app attached
to QTBUG-75003 work when using the VoiceOver screen reader
on macOS.
[1] https://developer.apple.com/documentation/appkit/nsaccessibilityannouncementrequestednotification
Task-number: QTBUG-75003
Change-Id: Iabd9acf8267b0fef00706004f17d48ebc3ecc161
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Bridge the newly added QAccessibleAnnouncementEvent to UIA
on Windows, by calling UiaRaiseNotificationEvent [1].
This makes the announcement from the example app attached
to QTBUG-75003 work when using the NVDA screen reader on Windows.
As described in commit d25d9f2c26,
implement the UiaRaiseNotificationEvent function for MingW
in qwindowsuiautomation as MingW doesn't provide that
itself yet (see the earlier MingW build failure without
that "kludge" in place: [2]).
[1] https://learn.microsoft.com/en-us/windows/win32/api/uiautomationcoreapi/nf-uiautomationcoreapi-uiaraisenotificationevent
[2] a2e63edda6/build_1714142084/log.txt.gz
Fixes: QTBUG-75003
Change-Id: Ia32d49276e0dd33cff5113b4169ee317869390e7
Reviewed-by: Oliver Wolff <oliver.wolff@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>
Applications can request the color scheme to be either explicitly light
or dark, or to follow the system default by setting the scheme to
Qt::ColorScheme::Unknown.
Setting the color scheme will make the request to the QPlatformTheme
implementation, which can then use the appropriate implementation to
set the application's appearance so that both palette and window
decoration follow the requested color scheme. This should trigger
theme change and palette change events. A change to the effective
scheme should then call back into QStyleHintsPrivate::updateColorScheme,
which will emit the changed signal for the property.
Implement this for macOS (Cocoa), iOS, Android, and Windows.
On macOS, we have to use deprecated AppKit APIs; the replacements for
those APIs are not suitable for this use case. On iOS, the setting is
for each UIWindow, which we can update or initialize based on an
explicitly requested scheme.
On Android we can piggy-back on the logic added when dark theme support
was introduced in b4a9bb1f6a.
On Windows, we have to fake a dark palette if the dark scheme is
requested on a light system, as there is no API to read a dark palette.
However, we also have to ignore any application preference if a high-
contrast accessibility theme is selected by the user (we report the
color scheme as unknown; there are both light and dark high-contrast
themes), and read the system palette using the GetSysColor API, which
is used for light mode. And we need to initialize windows with the
correct frame if the application explicitly overrides the system color
scheme.
Add an auto-test to the QApplication test, as that gives us the most
coverage to confirm that QStyleHints emits the changed signal, and that
Theme- and PaletteChange events are received by the toplevel widget
when the color scheme actually changes. This test has to be skipped
on platforms where we cannot set the color scheme programmatically.
Add the option to explicitly select the color scheme to the widget
gallery example, and default it to dark mode.
Fixes: QTBUG-124490
Change-Id: I7302993c0121284bf9d3b72e3149c6abbe6bd261
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We rely on setParent for parenting top level windows into our desktop
manager view, so we can't condition the call on having a parent window,
like we do on other platforms.
This was a regression from 988039729f.
Fixes: QTBUG-125142
Pick-to: 6.7
Change-Id: I2884d77db09cba5371ccd77eabda7ce38c0292de
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If the QWindow::handle() has not been created yet we will add
a zero page pointer to the allwindows list.
One possible symptom is that emscripten::val complains
in context2d() that it is accessed by the wrong thread.
what happens is that the this pointer points to the first
page.
Seen in the documentviewer example
Change-Id: I2b08176ebdd7c35d5105194f7fd9f4f6d45b77e5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We don't need to create UTTypes from identifiers when we can now
directly add the UTType to the array. In fact this way was causing an
exception since it couldn't cast a UTType to a NSString type.
Change-Id: I34d44422c102df84a625945af218b9c25c1a6895
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Accessing the keyWindow through UIApplication keyWindow was causing a
crash.
Fixes: QTBUG-125089
Change-Id: Ie02afd7875b490c1f72ff2e827ffa2204d0e9e81
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Fixes: QTBUG-121924
Change-Id: I20a4a41a16ac3d7855f359df020564bfc7435c57
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Even Oscar Andersen <even.oscar.andersen@qt.io>
There are two cases in which we let the style polish a palette:
- after merging the system palette and the style's standard palette
- or when a widget-class specific palette gets set
A style needs to know which colors of the palette it can safely
overwrite with style-specific preferences. For that to work, we
need to reset the resolve mask of the synthesized palette (first
case) to 0 before polishing. Palettes set explicitly by application
code will then have resolve bits set, and the polishing can
respect those colors and not overwrite them.
Simplify the polish() implementation then to check whether the
respective color's resolve bit is set, and only overwrite it with
the style's preferred color if the bit is clear. Move that logic
into a macro for simplification.
This amends b733d31f27 and makes
sure that colors that are set by the application explicitly don't
get overridden by the style.
Task-number: QTBUG-124490
Task-number: QTBUG-124286
Change-Id: I69e1e3da93f661ebdafee0b62adbb3d411322443
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The handleSettingsChange handler is usually already executed through the
event loop. And if it is called directly e.g. when changing settings
programmatically, then all side effects of the change should be in
effect immediately.
Task-number: QTBUG-124490
Change-Id: I243772860b1137ef9fe712c4b0d1c88593d2bdb4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
A round trip through querying the window attribute to avoid a
call to the setter is overkill, we can assume that the setter won't
do anything if the value of the attribute doesn't change.
Also, don't check whether QWindowsIntegration::darkModeHandling
is overridden before calling setDarkMode, which checks that flag
already. The flag will be very rarely cleared (and we might want
to remove support for this obscure mechanism soon).
Task-number: QTBUG-124490
Change-Id: I7e027fd53f556200edfd127eaf5f2b97f027528e
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
With this support applications can claim to be handler for
specific custom scheme URLs such as "com.my.app"
This requires that the scheme is listed in the plist file
(CFBundleURLTypes and CFBundleURLSchemes).
One notable usage example is the use of OAuth redirect_uris.
[ChangeLog][macOS] Added support for custom uri scheme handling
Task-number: QTBUG-124340
Change-Id: Ia04e9b89b53ee6f24129f9dd5ee8fbc5c0f0516c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
With this support applications can claim to be handler for
specific https URLs. This requires that an appropriate AASA
(apple-app-site-association) JSON file is hosted and accessible.
One notable usage example is the use of OAuth redirect_uris,
which are often required to use "https" URI scheme.
[ChangeLog][macOS] Added support for https/universal links handling
Task-number: QTBUG-124340
Change-Id: I91c725fcf209b295dc1b2687a52cd0a547aff1c8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Looks like the CI does not compile the IBase/Firebird plugin so this
compile error slipped through.
Change-Id: I2e20088e10baa91f2e1e5e2b5656dfb7bdf42896
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Make the functions populating the palette static class members so
that they can access private helpers.
Encapsulate logic that overrides the system or (later) explicitly set
color scheme into a helper that always respects the presence of a
high-contrast theme.
Task-number: QTBUG-124490
Change-Id: I7ad09596bb308b17b4c6ec34bb02cb6cf4b8c1bb
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Since the color scheme is a tri-state (it might be Unknown when
a high-contrast theme is active), don't store a "darkMode" value,
but the color scheme.
Make the query-functions private to the theme, the external API
should always return the stored value, which gets updated when
a theme change is processed.
Task-number: QTBUG-124490
Change-Id: I41e6336773a3bb426b406dce370ef81c20e513ee
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Use the platform theme or QStyleHints instead.
Task-number: QTBUG-124490
Change-Id: Iab12faa726d3031d6a250664468dac333c2c2e0c
Reviewed-by: Doris Verria <doris.verria@qt.io>
Enabling OpenGL, ThreadedOpenGL and ForeignWindows capabilities for all
cases where we have a valid Android context.
Also enable createPlatformOpenGLContext and createPlatformWindow in the
same circumstance.
This allows service-embedded contexts to create and manipulate windows
and surfaces.
Task-number: QTBUG-118874
Change-Id: I34a3153865cc1263973b8ddf67a82d61b2266bca
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
In non-Activity contexts, do not register the QPlatformServices class
as an intent listener, as only Qt applications based on Qt Activities
will receive new Intents. Calling getIntent on a non-Activity context
will also cause an error, as getIntent is a method of Activity, not
Context.
Skip both when constructing QPlatformServices for applications without
an Activity context.
Task-number: QTBUG-118874
Change-Id: Ide64bd6a90d8db0a7654968ff42cdaa5da1d3b51
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
When embedding QML into an Android service, Qt is not actually running
as a service. Avoid checking for QtAndroid::Service() and assuming that
means we are running as a service.
Task-number: QTBUG-118874
Change-Id: I5eea32b9fc200c4f34f1507d591aa1a483849118
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Since the parent window wraps the QtView, it should always be destroyed
when the QtView is, and live inside QtView rather than the delegate.
Destroying the parent window will always destroy the child window, so
do not destroy the child window separately.
Move createRootWindow and deleteWindow native functions to QtView.
Fixes: QTBUG-124908
Change-Id: Ib6b3c6388a9dd3f74d16fa09a442b0a6f8ccb336
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
QWindows11Style inherits from QWindowsVistaStyle for which StyleSheet
theming is deactivated. QWindows11Style draws most elements with
QPainter and should therefore be able to use overrides by StyleSheets.
This patch checks, whether QWindows11Style is used and enables the
theming by declaring it not to be a QPixmap based style. Further drawing
routines for QComboBox, QPushButton and QLineEdit are now drawing always
the base background and when they are hovered a alpha mask is used to
overdraw the elemens to create a highlight effect.
Fixes: QTBUG-124286
Pick-to: 6.7 6.7.1
Change-Id: I65436493bc2b1572c0d9423a066caea3ba9e1459
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The Windows 11 style checks for QProgressBar type and gets the
respective orientation required for rendering. This creates an issue
when we use QStyleItemDelegate as it's not QProgressBar type. This patch
removes that condition and gets the orientation information through the
style option similar to Windows Vista style.
Fixes: QTBUG-124447
Pick-to: 6.7
Change-Id: Ic2b36d79d7af017262e44dd2800ad45fbe63f8f2
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Makes it possible to enable debug log outputs via QLoggingCategory.
Earlier it was only possible via buid time flags.
Change-Id: Iaec732e7acdf44a74c9d7c806bf0e6f5a5f87b1c
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Move the calculation of the decimal scale into own function and preserve
HighPrecision string values by not converting them into doubles before.
Change-Id: I839923189e9f6b1f8fb9ce234c987423703b79bf
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The Android QPA picks between two types of Views that can provide a
Surface for it, SurfaceView and TextureView. Normally, SurfaceView
is used if there's just one window in the app, and TextureView is
used for any additional windows, since it allows better control
over the z order between the windows. Add an environment variable
QT_ANDROID_SURFACE_CONTAINER_TYPE that can be used to
override the normal choosing strategy, and force the application
to use either one of the View classes for all the windows of the
app.
This helps with testing changes to the Android QPA windowing,
as you can use the same app to test both Surface Views easily.
Pick-to: 6.7
Change-Id: Icc15fd9675175b854354a379b6ffa7ae5532408e
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Print a warning when we encounter an unsupported data type.
Pick-to: 6.7 6.5
Change-Id: If35ac4dfdf29e555ec406f592c1001b5e16f8ff2
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
In some circumstances our application badge code seems to throw an
exception. The issue is hard to reproduce but just catching the
exception should be enough to fall back to the "non-winrt" version of
the code.
Fixes: QTBUG-117091
Pick-to: 6.5 6.7
Change-Id: I61f4e59f7309e2bb47b50a6ca6f3099ed9cd0af1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Consider the following QML code:
import QtQuick
import QtQuick.Controls
ApplicationWindow {
visible: true
Menu {
id: menu
MenuItem {
text: "Some action"
}
}
TapHandler {
acceptedButtons: Qt.RightButton
onTapped: {
exitAppTimer.start()
menu.open()
}
}
Timer {
id: exitAppTimer
interval: 1000
onTriggered: Qt.quit()
}
}
With the new native Qt Quick Menu, this will create a native menu on
platforms like macOS. When the user right clicks on the window, a timer
is started and a native menu opened. After 1 second, Qt.quit() is
called while the menu is still open. As popUpContextMenu is blocking,
when the menu is finally closed (by user interaction), control returns
to QCocoaMenu::showPopup, but the QCocoaWindow has since been
destroyed.
Account for this by storing the window in a QPointer.
It's not possible to test this as native menus can't be auto-tested.
Fixes: QTBUG-124551
Pick-to: 6.5 6.7
Change-Id: I14a97073f350c38828b3e16bb157439aeeeb6529
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When using QWindows11Style, the viewports background has to be set to
Qt::transparent to have the effect of rounded corners in ItemViews and
Combobox flyouts. Other Windows styles do not make use of transparent
windows, so this polishment needs to be reverted in case the style
changes. Other styles also do not manipulate the
QAbstractScrollArea::viewport palette and thus changing color schemes
results in not applying the new color scheme.
Fixes: QTBUG-123928
Pick-to: 6.7 6.7.1
Change-Id: Icb529124f63587e75bb56e40e8b1fcfe3c61c55d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Sending an ObjectShow event, e.g. by setting QQuickItem::visible to
true, has to trigger a refresh of the screen reader hierarchy. If the
signal is ignored the source of the signal will be ignored by the
screen reader.
Fixes: QTBUG-122436
Pick-to: 6.5 6.7
Change-Id: I32ee2e8b2602cd0dd9b9a83ff1fe426d88d137a8
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
It unnecessarily duplicates and distributes logic for reporting whether
the application should run in dark or light mode.
Task-number: QTBUG-124490
Change-Id: I227660cf3e1f21afd5fd9b3d6452f6109f3cf799
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Move storage of whether dark mode is set into a static class member
of QWindowsTheme, and remove QWindowsContext::isDarkMode; ask the
theme instead using the colorScheme() implementation, which will return
the stored value.
Move the code handling settings changes into QWindowsTheme as well.
Task-number: QTBUG-124490
Change-Id: I4795e80b6ab2c94701385dc84771e9ad5578cf32
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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 mouseDown() and mouseUp() methods in androidjniinput.cpp hardcoded
Qt::LeftButton to all mouse-press / release events.
If a mouse is connected to an android device, all three buttons are
mapped to the left button.
Extend both mehtods' signature by a mouse button state.
Add a converter method to map from Android button states to
Qt::MouseButtons. Add a sendMouseButtonEvents method, that iterates
through all buttons pressed/released and sends the respective events
to QWSI.
Adapt the mouse handler in java, to obtain and pass the button state
to C++.
The patch can't be verified in an autotest. Testlib's mouse emulation
injects into QWSI.
Fixes: QTBUG-99106
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: I933f490901928db9761d2ef254ae1e5b4f473f28
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Qt and application code expects that QScreen geometry
should be available early in main(), after the QApplication
constructor returns.
This is not the case if onLoaded is called at later
point in time, since the container element for the
screen is typically made visible when onLoaded is called,
and does not have valid geometry before.
Change-Id: I62d87f01fce1cd601e7a70d842e22a61814c9db7
Reviewed-by: Even Oscar Andersen <even.oscar.andersen@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
The documentation of `QStyle::drawControl()` states that
"The widget argument is optional" so it must not be used
unconditionally.
Pick-to: 6.7
Change-Id: I8b5a8ed421c0ae2c667925e448c9a029b6deedfd
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We now adopt the UIScene lifecycle, where we react to iOS creating
UIWindowScenes for connected screens, which we then configure with
a single instance of our QUIWindow, that in turn contains the
QIOSViewController and QIOSDesktopManagerView that we depend on
for our window management.
As a result, we can now create and show QWindows on visionOS,
which doesn't have UIScreen and hence failed with our old strategy
managing our UIWindow via UISScreen.
We still do not declare a UIApplicationSceneManifest in our Info.plist,
or report UIApplicationSupportsMultipleScenes, as this adds another
level to the window management that we're not ready for yet.
Task-number: QTBUG-121781
Change-Id: Ic02f43aa6b205289a3f3c8e72c2a6ef575031d9a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We used to set a private _q_foreignWinId property on QWindow when
creating foreign windows, and this was the mechanism which we then
passed the foreign winId to the platform plugin.
With c585802e94 this was removed,
since we now were passing the winId through via explicit QPA
APIs, and since 0c6911e5cd removed
the ability to explicitly destroy() a foreign window.
But when closing a QWindow, we destroy both the window itself,
and all its children, including foreign windows. In this case
we still want to support recreating the foreign window, for
example when the parent window is shown again. To enable this
we restore the _q_foreignWinId private property, but keep
the limitation of not being able to explicitly destroy a
foreign window.
Pick-to: 6.7 6.5
Fixes: QTBUG-124160
Change-Id: Ia885ba9f043e64fb21eedd2b4c344679726f1b5c
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
They're not wanted and Axivion (SV71) grumbles about the lack of copy
and move operators and constructors otherwise. Do the same in all
derived classes. Some of these needed their default constructors made
overt as a result. Similar for QAbstractFileEngineHandlerList.
Task-number: QTBUG-122619
Change-Id: Iff016940f8c4884bd65dd781354b9bcda9b7cdd8
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Subscribe to SettingChanged signal from xdg-desktop-portal to get info
when color scheme changes and update it on runtime.
Fixes: QTBUG-116197
Pick-to: 6.7 6.6
Change-Id: I7803ea76bc1ac0749d60ee55c1c0d9051dad210a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Use xdg-desktop-portal to get color scheme used by GNOME. Recent GNOME
versions use this as primary way to switch between light and dark theme.
Make this a preferred way to get color scheme and fallback to previous
methods in case xdg-desktop-portal cannot be used. Also update app theme
on runtime when color scheme changes, not only when theme is changed.
[ChangeLog][Platform Specific Changes][Linux] Add support for
xdg-desktop-portal to get color scheme in QGtk3Theme.
Fixes: QTBUG-116197
Change-Id: Ib3ffad405bc795ed6f4de4af411efc45721662b9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
In the Windows 11 style, it's better to include the headers for specific
widget types at the expense of compile time, than to pay a regular
runtime cost from using expensive inherits().
Add const, fix style, and break excessively long lines related to this
change.
Pick-to: 6.7
Change-Id: I2c8c6d98267d9ff3542decda71e08e462cf9807c
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Pavel Dubsky <pavel.dubsky@qt.io>
As of Qt 6 (3e12951c0b, the QScreen's
orientation() property is supposed to represent the orientation
of the screen from a window management perspective, and not the
orientation of the actual device, as in Qt 5 times.
For iOS, when the orientation of the app is locked to a orientation
via the Info.plist or [UIViewController supportedInterfaceOrientations],
the UIDevice API will keep reporting the actual orientation of the device,
which is wrong for the Qt 6 definition of the API.
We currently don't have an API in QScreen to represent the always
updating physical rotation of the device. For this use-case the
supported API is QOrientationReading in Qt Sensors.
[ChangeLog][iOS] QScreen::orientation() will no longer report the
device's physical orientation when orientation has been locked
to a subset of the available orientations, but will instead
match the primary orientation.
Task-number: QTBUG-38576
Task-number: QTBUG-121781
Change-Id: I251a039a618656466cbfd1d836a5b49a6be8e736
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The [UIApplication setStatusBarOrientation:animated] API has been
deprecated since iOS 8, and a no-op since iOS 13. It is no longer
possible to report the orientation of a view or view controller
independently of the orientation of the view itself.
This was problematic because we were applying additional logic
to our screen geometry mapping based on the assumption that the
API was still doing something, resulting in broken auto rotation
when calling reportContentOrientationChange().
Removing the iOS implementation for reportContentOrientationChange
makes this API a no-op on QWindow as well, as no other platforms
seem to implement it. We should perhaps consider re-thinking the
screen orientation APIs in this light.
[ChangeLog][iOS] QWindow::reportContentOrientationChange no
longer has any effect on iOS, as the APIs used to implement
this on iOS are no longer available.
Task-number: QTBUG-38576
Task-number: QTBUG-121781
Change-Id: I5b129d21c990332170599c2580e389e252140d6f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Ideally we would report the available geometry of our screen in a way
that reflects the safe area margins of a potentially full screen window,
but doing so requires that we manage UIWindows via QScreen/UIScreen,
which is not in line with modern iOS window management.
We still apply safe area margins to maximized windows, as before,
but do so when applying the maximized state in QIOSWindow::setWindowState
Task-number: QTBUG-121781
Change-Id: If7b9855aea47014f01e23dfe197b7057a1305a68
Reviewed-by: Amr Elsayed <amr.elsayed@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
We still fall back to m_uiWindow for grabbing the entire screen, but
the rest of the logic is now agnostic to where the window of the view
is coming from.
Task-number: QTBUG-121781
Change-Id: If8815f62d22a1d4bbdfe6fe24ddadce2223c8623
Reviewed-by: Amr Elsayed <amr.elsayed@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We're moving away from the screen managing a UIWindow, so let's track
the UIWindow via the focus window instead.
Task-number: QTBUG-121781
Change-Id: I943b1d501f743c51b3f1484aecbe008c6dae8cd4
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Amr Elsayed <amr.elsayed@qt.io>
This change adds QComObject as base to QWindowsUiaMainProvider in order
to reuse its implementation of IUnknown.
Change-Id: I48808262364992f90f18fc881594f151eeb29a3f
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
It's the gbm_bo_get_user_data() function that takes ownership of the
FrameBuffer object, not the caller of the function, so release() into
gbm_bo_set_user_data() not into the return. This threw Coverity off,
which complained about a leak of the return value in the caller.
Amends 2f0fa59d59, but not picking
through all the refactorings the code has since seen.
Pick-to: 6.7 6.6 6.5
Coverity-Id: 444117
Change-Id: I5f058e4a42942349193eecfd8c00ec9499ef4886
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Qt already runs on Vision Pro as "Designed for iPad", using Qt
for iOS. This change enables building Qt for visionOS directly,
which opens the door to visionOS specific APIs and use-cases
such as volumes and immersive spaces.
The platform removes some APIs we depend on, notably UIScreen,
so some code paths have been disabled or mocked to get something
up and running.
As our current window management approach on UIKit platforms
depends on UIWindow and UIScreen there is currently no way to
bring up QWindows. This will improve once we refactor our
window management to use window scenes.
To configure for visionOS, pass -platform macx-visionos-clang,
and optionally add -sdk xrsimulator to build for the simulator.
Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The threee enumerations
- PM_DialogButtonsSeparator
- PM_DialogButtonsButtonWidth
- PM_DialogButtonsButtonHeight
Are not documented since Qt3 times and also not used anywhere. Therefore
deprecated them and remove the logic to handle them.
Change-Id: Ia59fe15482e744123e7fbf04b8d44661afb58b5c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This reverts commit 220afb358f.
The change caused segfault after menus or dialogs were closed.
The global raster compositing context is still being used by root
window and cannot be deleted from child window.
Pick-to: 6.7
Fixes: QTBUG-123962
Change-Id: Ie88925052f0f424617382388c587ae47570d13a7
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Ctrl+(Shift/Option/Cmd)+Tab presses are not handled as a regular key
events, and are not seen by our NSView.keyDown implementation. But
they are delivered to a performKeyEquivalent implementation, so if we
see a Tab key being pressed with the Ctrl modifier down, then send
a shortcut event and stop processing if that event got accepted by Qt.
Pick-to: 6.7
Fixes: QTBUG-113492
Task-number: QTBUG-8596
Change-Id: Id3aa7021a689b94d97eb881b19ddf7cb039e1bd2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Currently the icon used by document-properties is a gear icon, on
Windows, the actual icon used by explorer's context menu for the
properties menu option is the wrench icon. This patch change the icon to
the wrench icon.
Fixes: QTBUG-124085
Pick-to: 6.7
Change-Id: Ife49ad64d23b73b7676bc39330887e2cb320dcf9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
qinputcontrol refused to accept the character since
text part of key was empty
This caused the tabkey to always switch focus instead
Fixes: QTBUG-12423
Change-Id: I9ea7f02831cc88479b4e15d25eac278547f6f711
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Use the categorized logger qt.sql.mimer
Change-Id: I1b0d149a1a6317eec3b821dee99d952ef1000c28
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Fredrik Ålund <fredrik.alund@mimer.com>
To avoid usage errors like fixed with
7e5a0b54f0
Pick-to: 6.7
Change-Id: I33af9721a04e80541c027fa6da8630070a5957ac
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Fill with the "window" color of the palette as passed in through
the style option, which takes care of active vs inactive color
selection.
The title bar of a docked dockwidget is a bit lighter than the
main window title and unified toolbar background, but identical
to the color of the title of an undocked dock widget. This is now
the case for both dark mode and light modes.
Also remove the gradient fill from the status bar, just fill it
with the window brush.
Remove the now unused helper functions for the title bar
gradient.
Fixes: QTBUG-92855
Pick-to: 6.7
Change-Id: Ia04c630201b288c0107567d3f459f66129693c82
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use a solid fill with the "button" color of the palette also for active
title bars, which is then the same color as the frame, and gives the
window a consistent look in both dark and light mode.
Fixes: QTBUG-123162
Pick-to: 6.7
Change-Id: Iac26fdb1518ffe4f8255e01bedf7329be40ac258
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
.. by playing it safe and taking the QVariant by copy
Pick-to: 6.7 6.5
Change-Id: I24e0507a912388b7fb17e838a22e8d4c449bcf5b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a system tray icon on Windows wasn't visible (hidden behind the ^
icon in the task bar) our previous implementation gave different
results on Windows 10 and Windows 11.
On Windows 10 the geometry returned the geometry of the ^ icon itself
while we returned a geometry outside of the screen geometry on Windows
11 (that was what the Windows API gave us).
We work around this problem by using version specific hacks to be able
to check for the visibility of the system tray icon itself. If the icon
is hidden we just return QRect().
[ChangeLog][Windows] The geometry of a hidden QSystemTrayIcon was
unified over different Windows versions. It will always return QRect()
now.
Change-Id: Iee7dea184936a13a9221df9c421400ba304a4c38
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
QVariant is rather big for passing by value; and no caller has any
further use for the QVariant it's passing in.
Pick-to: 6.7 6.5
Task-number: QTBUG-122619
Change-Id: I2751745e715aacfa8982ac97b4ae777fde5e88de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Axivion (SV546) points out (based on a clazy "rule of three" that
might be rule of five by now) the lack of move and copy assignment and
construction. We don't want those anyway, so tell the compiler not to
create them.
Pick-to: 6.7 6.5
Task-number: QTBUG-122619
Change-Id: Ie951a2c3d60d76ad3448310d3f9bbda22190015b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If IM is enabled we send key events through the macOS text input system,
and we do this for all key pressed, including the ones with modifiers
pressed. The latter allows the input method to respond to shortcut
key combinations to switch its own mode or do more advanced operations
on the text.
We were relying on the IM to call doCommandBySelector with a noop
selector if the shortcut didn't match any of its own internal key
sequences, but this fails for key events with more than one modifier
pressed.
Instead of using [NSView interpretKeyEvents:] to pass the key event
to the system IM we now go directly to the NSInputContext, which the
former method is just a wrapper for. This allows us to use the result
of [NSInputContext handleEvent:] to determine if the system IM consumed
the event or not. For key events with multiple modifiers this will be
false, which we interpret to send the event as a regular QKeyEvent
instead.
Fixes: QTBUG-123848
Fixes: QTBUG-106516
Pick-to: 6.7 6.5 6.2
Change-Id: I14a43c2029149514515dd9ece881aed3f6500a4e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Following up on 2 commits that fixed static linking for MSVC but left
out MINGW:
230c53ad9dd9820b0207
Pick-to: 6.6 6.7
Fixes: QTBUG-114243
Change-Id: I12853355ffa1a62acce15ff660478f618c42e0a6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Seems to have been left out by 874f5c1f463cad61f49e0ff7007852a73fd93e7c
Pick-to: 6.7
Fixes: QTBUG-123478
Change-Id: Ic028c3786203cbc1c3d7316c1ae22c12a928b170
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
QWindowsComBase is now replaced with QComObject, let's remove the
former since it's a duplication.
Change-Id: I7f911fa036c1f2eaaee168250b8294170430cc5d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We must not try to escape a driver string, the user has to make sure
that everything is correctly escaped when passing a complete driver
string. This fixes a regression from QTBUG-122642.
Pick-to: 6.7
Fixes: QTBUG-123444
Change-Id: I43316c7a09060f5c8117fdc3c464d239e37d9cdf
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
... but use QStringView instead in setConnectionOptions() and the
dependent functions.
Also remove the (undocumented) ability to pass the connection options in
non-uppercase - this was never supported and all other plugins don't
support this either.
[ChangeLog][SQL][ODBC] All options must now be upper-cased as documented. Lower-cased options are no longer supported.
Change-Id: I822db1ddf205c22fe939299c4ab741bbe9b56d65
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
With the introduction of CMYK32 the old logic of assuming depth
meant compatible alpha version no longer works. So change the logic
to more explicitly return compatible opaque or alpha versions and
remove the now invalid qt_maybeAlphaVersionWithSameDepth.
Change-Id: Ib1f7b76b0ce0eae7d49a0dfe369918a746bbe2b4
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Follow the established convention that byte-oriented image formats
have the "8888" suffix, not "32". The old enum name is temporarily
left to help port other submodules.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Change-Id: I4b6f10cb22312b614cb9cf4b0ac439907276c538
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Since any window resize events originating from Qt side are ran in the
Qt thread, having the one originating from Android run in the Android
thread can lead to race conditions especially during orientation changes.
Pick-to: 6.7
Change-Id: Iebebec2fffdaf9181b01fc1e8f539c7bc232996d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Previously, we have set the size of the QWindow to match the QtView.
Also set its x and y coordinate to match, just to keep the window and
the view in sync.
Pick-to: 6.7
Change-Id: I0ea89a11e4526a0a996e7b62ac126808358b6bc7
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The parent window created from the QtView had an
empty size. Also set its size when creating the window,
and when resizing the QtView. Replace parent window show()
call with showNormal() to avoid switching it to a fullscreen
window.
As a drive-by, use setGeometry() instead of setting the width
and height separately to trigger only one geometry update
for the platform window.
Pick-to: 6.7
Change-Id: I91e350c1748a9e76879faa8bfcab7575f6155f02
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
I'm not familiar with CUPS APIs, so missing better judgment or a
code comment, handle the possibility for a failure.
Change-Id: I6f9afa9fdccaadbe199ce307f79e1d6050aa2939
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Draw the glyph directly in the paint() override, and use that
from the scaledPixmap implementation. This avoids a pixmap
creation just for drawing an icon with an existing painter.
Pick-to: 6.7
Change-Id: Iece0083a3a9f3625d843bc6e9d836baf9b5d84f8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We don't use that in the XCB library or plugin anywhere.
Pick-to: 6.7
Change-Id: I5f663c2f9f4149af84fefffd17be8c7f3bd7bd14
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Remove unused code.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Change-Id: I3db7705b3963d7a7669f8c9b284d3d35a2a7da92
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
JPEG part 6 defines CMYK support. This commit adds such support to the
JPEG plugin.
A *very* interesting discovery is the fact that Photoshop inverts the
meaning of the CMYK color channels when saving into JPEG: 0 means "full
ink", and 255 means "no ink". Most other image viewers/editors follow
the same interpretation, I imagine for compatibility.
But others, like Adobe Reader, don't (???) -- a PDF expects a DCT
encoding with 0 meaning "no ink". I am adding a SubType to the image I/O
handler to let the user choose what they want, defaulting to Photoshop
behavior.
Also, turns out that Qt was already loading CMYK files and converting
them to RGB. I don't think we should do automatic, lossy conversions (we
were not taking into account an eventual colorspace...), so I'm changing
that loading to yield a CMYK QImage.
Finally: save the colorspace, even if it's a CMYK image.
QColorSpace doesn't support anything but RGB matrix-based colorspaces.
Yet, it can load an arbitrary ICC profile, and will store it even if
it's unable to use it. We can use this fact to preserve the colorspace
embedded in CMYK images, or let users set an arbitrary ICC profile on
them through Qt APIs, and then saving the result in JPEG.
[ChangeLog][QtGui][JPEG] Added support for loading and saving of JPEG
files in 8-bit CMYK format. When loading a CMYK JPEG file, Qt used to
convert it automatically to a RGB image; now instead it's kept as-is.
This work has been kindly sponsored by the QGIS project
(https://qgis.org/).
Change-Id: Ibdbfa16aa35814f5dba28c2df89577175162b731
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Input events have a timestamp. When dispatching an event through QPA, a
platform plugin can either provide it, or QPA will use an internal
QElapsedTimer to provide a timestamp.
Windows input messages do come with a timestamp already, so we can use
that instead of the QPA.
The two methods are not equivalent.
For instance: for various reasons, Qt does not honor Windows' "double
clicked" message, but uses the delta between two mouse events to
establish if the second click is actually a double click.
Now suppose that the user double clicks on a widget. On the first click,
the application does something that freezes it for a bit (e.g. some
heavy repainting or whatever). Does the second click register as a
double click or not?
* If we're using Qt's own timer, the answer is NO; the event is pulled
from the WM queue after the freeze, given a timestamp far away from
the last click, and so it will be deemed another single click
* If we use the OS' timestamps, then the second click will be seen as
"close" to the first click, and correctly registered as second click.
This reasoning can be extended to many other QPA events, but looks like
the APIs for some are missing (e.g. enter events), so I'm not tackling
them here.
This commit reverts ade96ff644.
Task-number: QTBUG-109833
Task-number: QTBUG-122226
Change-Id: I5f3fba029b44c618ef622bacdc4bcc3928e04867
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
Change the invalid static_cast<std::int16_t>(i)+1
to the correct static_cast<std::int16_t>(i+1).
Change-Id: I5d3e17d29deb2a70fa0d7d7838531a3dc80b4e45
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Calling data() for parameters of the type bigint
failed in combination with stored procedures with
output parameters. Cast the result to qlonglong to
fix it.
Pick-to: 6.7 6.6
Change-Id: I84ef04ed26821b92ef7c5bcdf12b778e91450e0b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
We're not guaranteed to get into any of the code paths that call
removePopupMonitor() before the app goes away. In a plugin-scenario,
this may cause crashes when our monitor then gets a callback and
we try to access QGuiApplicationPrivate::instance().
Pick-to: 6.7 6.6 6.5 6.2
Fixes: QTBUG-123959
Change-Id: I287b91ff261a8aab74adbbad8c63a042daf944d5
Reviewed-by: Doris Verria <doris.verria@qt.io>
What was done:
* Removed headers in src/gui/accessible/windows/apisupport: as of
v13.1.0, MinGW supports most of the definitions in these headers.
Including uiautomation.h should be enough.
* Removed the QWindowsUiaWrapper class: it's not meant to be extended
or itself instantiated, is an "ultra-thin" layer (it even preserves
the "all-caps" Win types of function args), and is in effect only a
MinGW-bound "kludge". Instead of this class, use the UI Automation
API directly, with the assumption that it's available and fully
functional, as specified in the MS docs. Any gaps between this
assumption and what is delivered by MinGW are bridged with specific
(and explicit) temporary "kludges".
* Implemented said specific "kludges" in qwindowsuiautomation. For
Windows builds, the header just includes uiautomation.h, and the
.cpp is empty. For MinGW, the header contains definitions still
missing from uiautomation.h, and the .cpp implements functions
of the UI Automation core library through imports from the
uiautomationcore DLL.
* Windows plugins (and tst_qaccessibility): use the UI Automation API
definitions directly, instead of the "ultra-thin" wrapper.
* Windows plugin builds: use uiautomationcore library, if found.
What's intended:
* Unburden Gui of the Windows UI Automation COM interfaces and other
definitions that are copied in the uia*.h headers.
* Make the Windows plugins independent of MinGW shortcomings.
* Remove the QWindowsUiaWrapper class that essentially only hides these
shortcomings and the "kludge" code needed to overcome them.
* As MinGW adds further support to the UI Automation API over time,
make it noticeable which workarounds are no longer needed. The
current approach of hiding "kludges" in a wrapper class will also
hide the fact that they're no longer needed, if/when that time comes.
Change-Id: I0070636817d5de81d0b106e9179e2d0442362e2a
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
These options are declared with TYPE enum and a MAPPING that's supposed
to control the feature 'system-zlib' or 'system-sqlite'. Since only
inputs of type boolean control features now, we need to somehow declare
that this non-boolean input controls a feature.
We do this by adding the keyword CONTROLS_FEATURE to
qt_commandline_option. For example,
qt_commandline_option(zlib
CONTROLS_FEATURE
TYPE enum
NAME system-zlib
MAPPING system yes qt no
)
declares
- commandline option "zlib" sets the input "system-zlib",
because of the "NAME system-zlib" argument
- accepted input values are "system" and "qt", because
we have "TYPE enum" and the odd values of MAPPING
- those values are translated to yes/no, because of the
even values of MAPPING
- CONTROLS_FEATURE forces the translated input's type
to boolean, and with that it will set the corresponding
feature 'system-zlib'
Luckily, only qtbase has command line options with MAPPING declared.
Change-Id: I82d06cec43ece3b002c8f5dd414c68dc730909af
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And try to not call Q_ASSERT() to avoid crash.
Fixes: QTBUG-123554
Pick-to: 6.7 6.6 6.5
Change-Id: I9443c5f0ab4ca7a858df9b328f517b48ab8f122d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
There is a limit in WebGL that OpenGL context sharing is not supported.
There is a proposal from 2013
(https://www.khronos.org/webgl/wiki/SharedResouces), but it seems that
it never was implemented.
There is an additional limit in that there is exactly one WebGL context
for each canvas (i.e. window).
A part of the problem here is that the identifier for an OpenGL context
is essentially a surface-thread-context triplet. And the thread part
might be more difficult to handle in a javascript setting.
Regardless of why, we need to have an opinion about what the
consequences are, and what we support to what extent.
As such this commit:
1) Adds a comment on the QOpenGLContext describing the limitations
2) Adds a qWarning() on the first activation of a shared context.
The second item is not complete. We will have problems with multiple
individual contexts also, It is just not possible to warn for these
cases. The second item covers, maybe, the most common case.
Change-Id: I51550a6acb0a7f6f6fa5e9e2c3da080a1d2b498f
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This is probably a remnant from when QAbstractFileEngine was public API
since it's been changed to private API, just use QFile::FileTime.
Pick-to: 6.7
Change-Id: I60d3d4ff811f95434b81d5ca115f5d43cfff8b15
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This makes the ownership of the returned pointer clearer. It also
matches reality, some call sites were already storing the pointer in a
unique_ptr.
Also shorten the function name to "createLegacyEngine", you have to read
its docs anyway to figure out what it does.
Drive-by changes: less magic numbers; use sliced(); return nullptr
instead of `0`.
Change-Id: I637759b4160b28b15adf5f6548de336887338dab
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The Qt::WA_ShowWithoutActivating flag was not respected
Added test in the part of the code that calls
requestActivateWindow
Added selenium focus test
Fixes: QTBUG-122776
Change-Id: I1a248ed4352f86376d615a4cb7022e7ea095d4e7
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
And remove hasNext/next() methods. This remodels QAFEI to be like
QFileSystemIterator. This better fits the logic in the newly added
QDirListing class (which uses STL-style iterators).
QFSFileEngineIterator:
Initialize the internal nativeIterator in the constructor; also replace
the advance() private method with an override for the advance() method
inherited from the base class.
QResourceFileEngineIterator:
Override currentFileInfo(), with a QResouces the QFileInfo is created
on demand if/when this method is called.
This is the backend/private API, and QDirListing is the public API that
can be used in a ranged-for to iterate over directory entries.
Change-Id: I93eb7bdd64823ac01eea2dcaaa6bcc8ad868b2c4
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There is no concept of a screen on visionOS, and hence no concept of
screen-relative system UI that we should keep top level windows away
from.
As UIWindow and UIScreen on visionOS report the exact same bounds, we
can't use the same code path we use for iOS/iPadOS to detect whether
to apply the safe area insets, so skip the logic entirely.
We still report the safe area insets on a QWindow level, so applications
can avoid rendering content close to UI elements such as the window
move and window close buttons.
Task-number: QTBUG-121781
Change-Id: I20ad02390564972a3715c27f351689b79ad579d8
Reviewed-by: Amr Elsayed <amr.elsayed@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The API has been deprecated for a long time, and doesn't have the same
semantics as we want for modern iOS apps that may run in windowed mode
on iPad, macOS, or visionOS.
Instead we base the availableGeometry exclusively on the safeAreaInsets
of the screen's UIWindow. But we only do so if the UIWindow bounds match
the bounds of the UIScreen in each dimension. This means that iOS apps
that take up the entire screen, or run in Split View on iPad, will get
a smaller availableGeometry, but apps that run in Slide Over on iPad,
or windowed in Stage Manager on iPad, will get an availableGeometry that
matches the entire screen.
It's then up to the QWindow to take the safeAreaMargins into account
when rendering, to stay out of any UI elements that the OS may add.
We do this for QWidgets with layouts automatically, and the plan is
to do this for Qt Quick Controls as well. As the current situation
is quite broken anyways, we take the first step now, and then follow
up with the Quick changes later on.
Task-number: QTBUG-121781
Change-Id: I7728e117969474654fcccdb19a6c954bb0eea3f9
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
12203e94f5 exposes the issue in xcb
qpa plugin.
We should not recreate xcb window via the call of focusWindow->winId().
Fixes: QTBUG-123032
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: I6da4f3e64a9d7a92a2aab714591986c5d128fbd4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Christian Ehrlicher
Tuomas Vaarala
Lorn Potter
Jens Trillmann
Tor Arne Vestbø
Shawn Rutledge
Eirik Aavitsland
Wladimir Leuschner
Vlad Zahorodnii
Andy Nichols
Timothée Keller
Viktor Arvidsson
Ilya Fedin
Rami Potinkara
Assam Boudjelthia
Michael Weghorn
Volker Hilsheimer
Lucie Gérard
Petri Virkkunen
Kai Köhne
Alexey Edelev
Even Oscar Andersen
Doris Verria
Piotr Wierciński
Juha Vuolle
Santhosh Kumar
Tinja Paavoseppä
Oliver Wolff
Mitch Curtis
Axel Spoerl
Morten Sørvig
Marius Kittler
Pavel Dubsky
Edward Welbourne
Jan Grulich
Marc Mutz
Samuli Piippo
Gary Wang
Dennis Oberst
Mark Brand
Allan Sandfeld Jensen
Giuseppe D'Angelo
Thiago Macieira
Fredrik Ålund
Miguel Costa
Joerg Bornemann
Liang Qi
Ahmad Samir