Our logic in the edit menu tap recognizer for determining whether the
tap should trigger the edit menu only looks at the bounds of the input
area, and as long as the tap is within these bounds we trigger the edit
menu.
This doesn't take into account that there might be controls laid on top
of the input area, for example a button, where we don't want to trigger
the gesture.
The only related logic we have is a heuristic that checks whether the
cursor ends up moving as a result of the initial press, in which case
we treat it as the edit area "accepting" the touch press.
The proper fix to this is to handle the gesture recognizer delegate
callback gestureRecognizer:shouldReceiveTouch:, and do hit testing
there, but we don't have any machinery for that in our IM protocol,
nor in QWSI.
As a workaround, we treat the gesture recognizer as having failed,
even when we do detect a tap that should open the menu, so that the
recognizer doesn't eat the touch event. We then open the menu manually
instead of relying on the gesture recognizer changing state. This
should be safe, as sending a touch/mouse event down to the input
area should normally be a noop.
The workaround does result in a slight visual wart when clicking
buttons that live inside input areas, as the edit menu temporarily
opens, but the menu is quickly hidden again as the focus object is
transferred to the button. Compared to the current situation, where
the button is visually pressed, but doesn't do anything, and we
bring up the edit menu fully, this is an improvement, even with
the wart.
Note that the original problem outlined in this changed is not an
issue in practice for Qt Widgets, as we synthesize mouse events
from touch events, and (wrongly) synthesize a mouse release in
response to the touch cancel triggered by the gesture recognizer,
so the button is still activated.
Fixes: QTBUG-113975
Pick-to: 6.5 6.6
Change-Id: I41e850f20d69ad8e3247949644a389e1c61c4dcf
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The export name is now ${TARGET_NAME}Entry. This can also be overridden
by using QT_WASM_EXPORT_NAME, both in CMake and qmake
Change-Id: I59c97ae6e22f0b2720716e9d7eff7b6b13d37ab5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The lack of 0x adornment made hex confusing. `xinput list` shows device
IDs as decimal, and device IDs appear in decimal in some categorized
qt.qpa.input.devices log messages, so let's be consistent here too.
Also fixed one more that was inconsistent in that category:
"scroll event from unregistered device <x>"
Change-Id: I98a39b30b1bc030611d3cfe9dd5e95886faf48ff
Pick-to: 6.5 6.6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We want to pass the QPointingDevice* because we've already identified
it by its "system ID" (xinput device number). The other versions of
handleTabletEnterProximityEvent and handleTabletLeaveProximityEvent
try to identify the stylus by only its deviceType, pointerType and
unique ID, which can go wrong if there are multiple tablet devices and
the unique ID is not provided (as with N-trig and Wacom tablets being
used at the same time). Anyway this fixes a TODO comment from
6589f2ed0c
Leave a "deprecated" comment by the QWSI functions that should not
be used.
Pick-to: 6.6 6.5
Task-number: QTBUG-104878
Change-Id: Id9f19c60b54b7900b02d5f87b5d12f9a9189721d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It is possible for an application to trigger the unexpected result of
NSModalResponseContinue from our call to NSAlert::runModal, by showing
and hiding a modal dialog first, and processing events explicitly. This
at best only flashes the native message box, at worst it triggers an
assert from our processResponse function evaluating that response value
as impossible (via Q_UNREACHABLE).
We should never call processResponse with NSModalResponseContinue,
but instead keep the modal loop running and the dialog visible.
So introduce a wrapper to NSAlert::runModal that keeps calling that
method until we get a result other than NSModalResponseContinue.
Writing an auto test for this failed; a simple test didn't reproduce the
assert; trying to place the opening of the native message box into a
lambda that would be called by the event loop (simulating the button
press from the bug report's reproducer) resulted in the native message
box never closing and the test blocking (and still not triggering the
assert).
Fixes: QTBUG-114546
Pick-to: 6.5 6.6
Change-Id: Iab25eff55c48b103287d1881ac355e6cdd190f7a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This property can take a either a WebAssembly.Module
or a promise to a module, and we don't have to specify
the exact type in the property name.
Pick-to: 6.6
Change-Id: Iebaf52178253afe8c93cf78bbe0853461bf48b67
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
The test checks whether correct windows get correct keyboard input,
having been activated with mouse clicks.
Also fixes the event propagation error found. Key events would propagate
to parent windows, which is something that should not happen with
window managers.
Change-Id: I18bae8c14cce5ccae151c2a00c84ffdba3b4587f
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
When QXcbConnection::xi2SetupDevices() reacts to a device hierarchy
event and re-discovers an already-known slave device, it doesn't call
xi2SetupSlavePointerDevice() again. I.e. it won't attempt to add it to
m_touchDevices or m_tabletData because it was already known. So it
should not clear m_touchDevices or m_tabletData either, but only remove
the touch devices that are known to have disappeared. Tablet styli
normally come and go from proximity, so it's ok to avoid deleting the
corresponding device data.
Also fix some other failure cases after testing hotplugging more with
tests/manual/inputdevices: there should be no crashes, no duplicated
devices after plugging (although the QAIM might have a bug that makes
it look that way), no leftover instances after unplugging.
Amends 2a9d93efc6
Pick-to: 6.6 6.5 6.5.2
Fixes: QTBUG-114334
Change-Id: I30f5e532f7dd3a465d56ecdd34d893cbadbf0453
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Adding the "assets:" prefix to BaseName leads to wrong names returned by
QFileInfo{"assets:/path/to/file"}.fileName().
Instead to return "file" it returns "assets:/file" which is not the
expected result.
Fixes: QTBUG-114576
Fixes: QTBUG-114219
Fixes: QTBUG-112261
Pick-to: 6.6 6.5 6.5.2
Change-Id: I574bf325300c0aedef68b1b183fa837144ad63c6
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reworked the code to list supported ciphers for Schannel
backend to provide the proper cipher names and cipher
properties.
Note: restricting the used ciphers for a TLS connection
is only supported for TLS 1.2 yet!
[ChangeLog][QtNetwork][QSslConfiguration] Add support for
listing supported ciphers with Schannel backend.
Change-Id: Idfc17335ec489315387a3e84b7a76a263be22378
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Currently items can get stuck in a hovered state when all fingers are
lifted from a touchscreen. This is because we don't react to the
WM_POINTERLEAVE event from Windows. With this patch we translate a
WM_POINTERLEAVE event to a LeaveEvent to remove the hover state from
QtQuick items.
Fixes: QTBUG-62912
Pick-to: 6.5 6.6
Change-Id: I8a6fb6b7ec77457854a75e20277565d1eb89bab6
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Setting parents for WASM platform windows is now supported. This means
that windows now reside in a hierarchical window tree, with the screen
and individual windows being nodes (QWasmWindowTreeNode), each
maintaining their own child window stack.
The divs backing windows are properly reparented in response to Qt
window parent changes, so that the html structure reflects what is
happening in Qt.
Change-Id: I55c91d90caf58714342dcd747043967ebfdf96bb
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Apparently it is not enabled since the TLS backends became plugins,
which is unfortunate I wrote code in here that assumed it was.
Change-Id: I765435ce7d2c6fafa452d0453c705c27ff477be6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Having the generic qt_itemFired: as action would result in the whole
submenu tree closing if an item with a sub-menu was clicked on. This
is not how native applications behave. They respond by immediately
opening the submenu, or do nothing if the menu is already open.
By using submenuAction: as the selector we achieve the same behavior.
A complication here is that for some reason we defer associating the
submenu NSMenu to an NSMenuItem until QCocoaMenu::setAttachedItem(),
instead of doing it in QCocoaMenuItem::setMenu(), or even as part of
QCocoaMenuItem::sync().
As a result, AppKit's NSMenuValidation logic will conclude that the
item does neither have a submenu, nor a valid target/selector combo
to be validated, and will explicitly disable the item. This can be
debugged by passing -NSTrackMenuValidation YES to the application.
To work around this we explicitly enable the item once we have set
a valid submenu for the item.
Pick-to: 6.5 6.6
Fixes: QTBUG-114199
Change-Id: I7178e7687066b3fe082454c512ec9c7eab3bded4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Declaring it as an explicit dependency should hopefully make
the compilers order the object-files to be linked in the
correct order.
Task-number: QTBUG-114243
Pick-to: 6.6 6.5
Change-Id: I723fee468e58786f66d1bba50bc4086beb50adb1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
In case the current GTK3 theme has no monospace font defined, a
monospace font requested by a Qt application can trigger a GTK warning
"Theme parsing error: <data>:1:0: Expected a valid selector".
The warning is triggered by Qt requesting "{font-family: monospace;}".
In this case:
=> ensure fallback to GTK standard monospace font
=> request "* {font-family: monospace;}" to avoid the warning
Task-number: QTBUG-112896
Pick-to: 6.6 6.5
Change-Id: I24a8da62908af9b153245f53026af60e63a600d7
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Don't show a blank frame on app startup.
The wasm update request system supports two types of update
requests: Expose and UpdateRequest. It can happen that both
types of request are made for a single window, in which case
the current code prefers UpdateRequest, since those must be
delivered in order to keep QWindow in a consistent state.
However, if the window is visible but not yet exposed then
delivering the update request will not make the window paint
anything, and we end up with a blank frame.
Ideally this should be handled elsewhere and QWindow::requestUpdate()
should not be called for non-exposed windows, but in the
case does happen then sending an expose here allows us to
recover.
Pick-to: 6.5 6.6
Change-Id: Ib53050c33ad1769ea9b9ad678896af15f87a7ecb
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Use new api calls for calculating pixel size and physical size
of multi-display setups after some existing apis have been deprecated
in Android API 30 and 31. Also, do the physical size calculation outside
of the supported modes loop.
As for the physical size, this patch still uses xdpi/ydpi for the
calculation instead of densityDpi as suggested in [1] because from
testing few scenarios, the results returned from xdpi/ydpi are more
consistent with physical device specs.
[1] https://issuetracker.google.com/issues/194120500
Pick-to: 6.6 6.5
Task-number: QTBUG-112742
Change-Id: I0c8ef5185c8b6463830b528374954c324a32d657
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Since first requestActivate may happen before the window div is
actually displayed on-screen, we need to sync Qt's activation state
with DOM as soon as DOM element becomes visible. Focusing an
invisible element is impossible.
Fixes: QTBUG-79934
Change-Id: I04cf9b4ead006c9b8b135b3b6967d7938c581833
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
If the iOS virtual keyboard as lost focus because it was slided down,
the next touch event on an inactive screen area will be mapped to the
keyboard. This kicks an assertion, because the keyboard is expected to
be visible. The case that the keyboard has been deactivated by sliding
it down is not covered.
This patch replaces the assertion by setting self.enabled to NO, which
reflects the keyboard deactivation.
Fixes: QTBUG-112246
Pick-to: 6.6 6.5 6.2
Change-Id: I4873b7a702178acfd3cb8c988134facc050d642a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This is very useful for debugging.
Pick-to: 6.6
Change-Id: I4861afb9bd2b4e757a962d81583a8b12958f9f1c
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Documentation got outdated during review of the new qt loader.
Change-Id: I8e23016b9a42e5f003e88c58a8e546255b167983
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The screen's DPI need to be accounted for when calculating
the size in mm from pixels. This was missing after multi-displays
support was added for Android.
Amends fbf586db2c.
Fixes: QTBUG-112742
Pick-to: 6.5 6.6
Change-Id: I31814faa8de68e5193757d52e264b8ed90ae56b6
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Introduce message helper functions for get/set, sparing the translators
having to translate the data types.
As a drive-by, use UUID/CLOB/BLOB consistently.
Amends 0efd8854c4.
Task-number: QTBUG-111219
Pick-to: 6.6
Change-Id: I7a137c3797947523af5478b3add6ee0a26b295d7
Reviewed-by: Fredrik Ålund <fredrik.alund@mimer.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We now add NOMINMAX to PlatformCommonInternal target which will be
linked to everything else, so min/max will not be defined upon the
inclusion of `windows.h`, or other headers.
Pick-to: 6.5 6.6
Change-Id: I10016720dac7ce015e929885b7368ee86d8b6918
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Small adjustment made to previous patch to fix the following issues:
- restoreGeometry not being updated after moving the window from one
screen to the other with keyboard shortcuts.
- restoreGeometry's size not being changed when moving screens if
WM_GETDPISCALEDSIZE isn't sent.
Pick-to: 6.6 6.5
Task-number: QTBUG-112814
Change-Id: I9dd2340137ce57a731f8881d476e902323887e62
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Monitor index detection changed from comparing deviceNames to comparing
serialNumbers, to prevent the case where two monitors with identical
names might overwrite one another.
Fixes: QTBUG-112829
Pick-to: 6.6 6.5
Change-Id: Ibfad08e178774396c4b347acfcfbdb83ed4fe332
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
If we have only one item, we're not using beginDraggingSessionWithItems
which requires us to manage our own drag loop, and instead use good old
dragImage, which takes care of the drag loop on our behalf.
In both cases we end up in draggingSession:endedAtPoint, so we need
to explicitly check for the existence of a manually managed drag session.
Amends 8a359343621fa83941946cb4e661b54ca7a1c4cc.
Fixes: QTBUG-114236
Pick-to: 6.5 6.6
Change-Id: Ifa9110945e191c4ffebe099e3e4edf9c571ab376
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The UIAccessibilityScreenChangedNotification will result in iOS resetting
its state, focusing the first a11y element on the screen. We shouldn't
tie clearing the a11y cache to this notification, as those are two
separate actions.
In the case of adding or removing individual elements, we still likely
need to clear the cache, but can inform the system of the more granular
UIAccessibilityLayoutChangedNotification to have it re-read the a11y
tree.
We still handle additions and removal of a11y elements with Window
or Dialog roles as UIAccessibilityScreenChangedNotification, as these
likely involve major UI changes.
The implicit UIAccessibilityScreenChangedNotification on QIOSWindow
destruction has been removed, as it's assumed iOS will automatically
refresh its a11y tree when a UIWindow is destroyed, and in any case
it's up to the individual clients of QAccessible to send the relevant
QAccessibleEvent to inform about the situation.
Pick-to: 6.6 6.5
Fixes: QTBUG-100094
Change-Id: If7d5cb961743e5ca97d45553b05ae5e92f82d275
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This is a minimal version of qtloader. The load function accepts
the same arguments as emscripten runtime with a few additions:
- qt.environment
- qt.onExit
- qt.containerElements
- qt.fontDpi
- qt.onLoaded
- qt.entryFunction
State handling has been removed in favor of making the load async
(assume loading when the promise is live).
Public APIs getting crashed status, exit text and code have been
refactored into the new qt.onExit event fed to load. No need for
keeping the state in the loader.
The loader is integration-tested. A test module with test APIs
has been created as a test harness.
The runtime APIs exposed by Qt (font dpi and screen API) are handled
by the qtloader seamlessly.
Change-Id: Iaee65702667da0349a475feae6b83244d966d98d
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Regression after 4c78ef80ca, where
we moved the window titlebar button logic from QCocoaWindow's
windowStyleMask function to updateTitleBarButtons.
Fixes: QTBUG-114064
Pick-to: 6.5
Change-Id: Idb0870571e88fa2962af36decd9bc7b53c35664d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Also fix coding style in the operator.
Pick-to: 6.5
Change-Id: Ia8f85a7bb7aa2d6f55923c80f72b734fc8dbd693
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Antti Määttä <antti.maatta@qt.io>
Pick-to: 6.5
Change-Id: Iabb2621364b5256ac89ec8cb7fafb0a9d346515d
Reviewed-by: Antti Määttä <antti.maatta@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Pick-to: 6.5
Change-Id: Ic4b184e1ed51d8e30c2305a5ead619117a505518
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Antti Määttä <antti.maatta@qt.io>
The AccentColor role, added in Qt 6.6, is currently populated with a
default value.
This patch implements populating the brush with OS values for Windows
and macOS.
Change-Id: Ic243c3b8664d50db3a2096a034de6ba672d9e2d2
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This should be better than returning unknown if xdg-desktop-portal
is not running or its backend doesn't know color scheme
This also matches the pratice of all other
QXdgDesktopPortalTheme methods
Pick-to: 6.5
Change-Id: I352e091a019bc5b683c3f1dad223e55717888d02
Reviewed-by: Jan Grulich <jgrulich@redhat.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qwindowscombase.h pulls in windows.h so not guarding its content by
including qt_windows.h might cause hard to track down issues like
min/max macros being defined.
Pick-to: 6.5 6.2 5.15
Change-Id: I3c48660ed87122bb0c4f6830c8d0b288ec62a509
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Timothée Keller <timothee.keller@qt.io>
Use qsizetype. Invert fread arguments to get the read size.
Pick-to: 6.5
Change-Id: I20684dc7a30177394b387e8893198007dbf36eed
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
Not entirely clear why, but when building the certificate chain for a
peer the system certificate store is searched for root certificates.
General expectation is that after calling
`sslConfiguration.setCaCertificates()` the system certificates will
not be taken into consideration.
To work around this behavior, we do a manual check that the root of the
chain is part of the configured CA certificates.
Pick-to: 6.5 6.2 5.15
Change-Id: I03666a4d9b0eac39ae97e150b4743120611a11b3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In QAccessible's widget implementations, trees are treated as tables,
with a rowCount implementation that is based on the view's current
item content. That item content is the view's content, not the model's,
and it changes when tree branches are expanded.
The Cocoa bridge for accessibility allocates arrays of row data
structures based on the rowCount implementation. Those data structures
need to be invalidated and recreated when the view's content changes.
To do that, emit an accessibility event for a model reset when laying
out items changes the size of the view's item array. We don't know what
changed during that layout process to makes this any more granular.
Amends 11ae55e918, but the problem
with the data structure being stale and incorrect would have been there
before that chain of changes optimizing. It didn't trigger an assert,
but probably resulted in incorrect data being reported.
To make trees testable, we need to actually expose them as AXOutline
to the macOS accessibility framework. Until now, they have been treated
like plain QWidget, e.g. AXGroup. This made them in practice in-
accessible. With this change, VoiceOver works much better (although not
perfeclty yet).
Also remove an assert that could be triggered by an accessibility
client asking for a cell for an invalid index (which can be reproduced
by navigating around in a tree, following debug warnings from
QAccessibleTree::indexFromLogical: invalid index).
Pick-to: 6.5
Change-Id: I7650342aa0dcd7925a94ae6a36de5a0b344c467d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Force UTC date-time and use ISO date-time. Also isMonotonic is
always true so the conditionals can be removed.
Change-Id: I7419d62ee7a526c3c6d4b7628d52d45b601e84d6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If an application added an "About" menu action, and then loaded
the qtbase translations, we would try to match the incoming menu
title ("About") against QCoreApplication::translate("QCocoaMenuItem",
"About"), which since qtbase provides translation in the QCocoaMenuItem
context would fail, and we would not detect the menu item role
successfully.
For this to work, the application developer would need to add their
own translations for every menu item, and these translations would
have to match the QCocoaMenuItem translations in qtbase.
By also comparing the menu titles against the untranslated heuristics
we now account for the situation that the app has not translated
its menu items.
If the app does add translations of its menu items these still need
to match the QCocoaMenuItem context translations.
Change-Id: Ic2f019cd42b7e080187f9738840f84b0cec239df
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
As of Qt 6.5 the html document should not create canvas
elements directly, but instead create div container
elements and let Qt create and manage the canvas elements.
However, qtloaders.js has not been updated to match this
and is still creating canvas elements when given div
elements.
Remove the canvas creation code and invert the primary
and fallback case: config.containerElements is now passed
to instance.qtContainerElements. config.canvasElements
is copied to config.containerElements, if set.
Change-Id: I7372db93ee4de5b23a0a5d992597a3fbd9711a33
Pick-to: 6.5 6.5.1
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
AppKit will in some cases call this method, even if we are layer backed,
just because we implement it. We should remove the implementation, but
doing so requires us to also move from displayLayer to updateLayer for
the layer backed drawing, which requires more testing.
Pick-to: 6.5
Fixes: QTBUG-113500
Change-Id: I70bde34fdb433105d85ccea0514a5342e2c1e725
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Correctly return only the fileName portion from
AndroidContentFileEngineIterator::currentFileName(); which
QDirIteratorPrivate::matchesFilters() expects when looking for matches
of the file pattern provided to the QDirIterator.
Fixes: QTBUG-112738
Pick-to: 6.5 6.2 5.15
Change-Id: I98dba2df014b27f33cd7e54fab3ad2de8c7c1750
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
The reason this worked before is unclear. It could be suspected
that we have made a dpi awareness change or Microsoft changed
the behavior of the OpenThemeData function.
Regardless, we expect the result to match the primary display which
OpenThemeData doesn't do (anymore). Instead it returns a value based on
the hwnd screen (which btw didn't always match the widget) and the cache
system would then re-use that theme also for hwnds on other screens.
The most obvious solution is to use OpenThemeDataForDpi to make sure
we get a theme result matching the primary sceen. Then our correction
of the result by with multiplying
QWindowsStylePrivate::nativeMetricScaleFactor(widget)
works again.
This fix does not only fix QMenu sizes. It fixes the size for all
widgets that use this theme function, which could return near
random results before.
We load this library dynamically since MinGW 11.2.0 won't link with it.
[ChangeLog][QWidgets][QMenu] Fixed menu sizes on Windows systems
with more screens.
Fixes: QTBUG-112911
Pick-to: 6.5
Change-Id: I8fdfde2ef5b2aa407cbc74c85afe2c0b74026cff
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
If the event dispatcher is interrupted we propagate the interrupt to
lower event loop levels, in case they too need to be interrupted. And
we defer the actual interrupt of the NSApplication to the next time we
process Qt events, to avoid AppKit dropping queued events on the floor.
This logic relies on QCocoaEventDispatcher::processEvents() setting the
interrupt flag to false, which signals that we should not continue to
tear down any further event loops.
Unfortunately, native run loops such as running application modal
sessions, are not driven by QCocoaEventDispatcher::processEvents(),
so we never reset the interrupt, and end up ending the session
immediately.
To work around this we need to explicitly clear the interrupt flag
before starting native modal sessions. This also fixes the issue
seen in QTBUG-111524 with showing native alerts from nested event
loops.
Fixes: QTBUG-112697
Task-number: QTBUG-111524
Pick-to: 6.5 6.5.1
Change-Id: I6aaec97011fd18c4a513c1dde3173b1cc4d50112
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This commit implements the manufacturer, model, and serialNumber
properties of QScreen for the Windows operating system. These were not
available previously because the Display Devices API allows piecemeal
access to the EDID fields, and the GDI API only returns the i-th device
name, e.g. "\\.\DISPLAY1".
Accessing the EDID of a given screen is possible by, given a
WindowsScreenData instance storing the device path, pivoting from
SetupDiOpenDeviceInterfaceW and then extracting the corresponding blob
from the Registry through a key handle retrieved with
SetupDiOpenDevRegKey. This blob can be parsed just like in Linux with
the QEdidParser class. The resulting metadata is applied to
the WindowsScreenData instance.
Additionally, this commit implements support for clone groups by making
getPathInfo return a list of the matching DISPLAYCONFIG_PATH_INFO
instances, and then concatenating the monitorFriendlyDeviceName
and the EDID manufacturer, model and serialNumber properties.
This commit makes the Windows and Direct2D QPA plugins dependent on
setupapi, and extends the QEdidParser class availability condition to
include these platforms.
Pick-to: 6.5
Change-Id: I56886b035a3d15e6f90aad5d797aeda21f99ff74
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Add the missing functionality to the Schannel backend to
make QSslCertificate::importPkcs12() work on Windows.
[ChangeLog][QtNetwork][QSslCertificate] Add support for
PKCS12 import with Schannel backend.
Change-Id: Ibb501724d0dc78b0507ac8becf4776fbba0a0623
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The Android APIs expect the content url filenames to have
percent encoded spaces, so handle that internally, if missing,
under the content file engine.
Fixes: QTBUG-112663
Pick-to: 6.5 6.2 5.15
Change-Id: Ieb2ee41a2587f985b589ca54b88f1cff89992154
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Expose document and clientArea emscripten objects through
NativeInterface.
This is required by WebView implementation for wasm platform.
Task-number: QTBUG-75183
Change-Id: I6f2f084a9dbceb80d2186c7395c008f268a91e39
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
As described in 3bedeb837e, the way
menu items on macOS are typically set up they have an action, e.g.
copy:, but no target, and the system then takes care of finding the
right target at runtime, starting with the first responder, walking
the responder chain, and then moving on to other NSWindows, before
ending up in the NSApplication and its delegate.
As we (still) don't have a mechanism in Qt to forward generic
actions, such as the cut/copy/paste, or selectAll, so we rely on
mapping the actions back to QCocoaNSMenuItem that we can trace
back to a QPlatformMenuItem that we in turn emit activated() for.
Normally this works fine, but in the case where the Qt app is embedded
in a native UI, which has its own menu items with cut/copy/paste,
we'll get callbacks into QNSView for actions triggered by a generic
NSMenuItem.
In that case, we need to bail out, but we want to do so in a way
that lets AppKit continue to walk the responder chain. This is
possible by implementing supplementalTargetForAction:sender:,
where we have access to the sender. If sender doesn't match
the expected QCocoaNSMenuItem we let AppKit find a better match
up the chain.
Since the target we return needs to ultimately respond to the
selectors and/or forward them, we can't point the target back
to ourselves, nor can we point it to the application delegate
directly, as the menu items need to be validated in the context
of the view, so a new per-view QNSViewMenuHelper class has been
added to take the role of forwarding the menu actions.
The logic for forwarding the resulting actions to the application
delegate has been simplified and hardened a bit as well.
A possible scenario with this new approach is that the Qt app
has a line edit focused, and the user tries to activate the
menu item for Paste, but the item is grayed out because we
can not support the action. This is of course confusing for
the user, but less so than having an active menu item that
then doesn't do anything when activated.
Another scenario is that a responder later in the chain does
respond to the paste action, and the menu item will end up
pasting into something that is not the first responder.
This might also be confusing for the user, but it's generally
recommended that implementers of actions like paste only
allow the action if the view is the first responder, and
this is something views have to deal with anyways, so it
doesn't change anything that we're now bailing out earlier
in not accepting the paste.
One benefit of allowing AppKit to find a better target for the
action is that if no target is found, and the user presses the
key equivalent of the disabled menu item, the key event will
be delivered as a normal keyDown to our QNSView, which we do
forward, allowing the Qt app to respond to the action, even
though the action came from a generic menu item. With our old
approach this would not happen, as we would claim to support
the action for our QNSView, but then drop it on the floor when
AppKit tried to deliver it to us.
Change-Id: I609db42df6a107a49e287f435e8808812c83d43e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Since the required minimum version of Qt is Windows 10 (1809),
the deprecated SCHANNEL_CRED code path to initialize TLS
connections can be removed and the SCH_CREDENTIALS based
path is used for all connections.
Change-Id: I2aef919a45373e55ae96405b7c6f2264378f4464
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
For now these will be used in QtQuick Flickable.
Task-number: QTBUG-35608
Task-number: QTBUG-35609
Task-number: QTBUG-97055
Pick-to: 6.5
Change-Id: I944d7f0271d535822ceeef610f232f56c85e0938
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
To fix the broken sliders reported in QTBUG-98093 a workaround was
added by 4bee9cdc0a where we would
call initWithFrame on an already initialized NSSlider.
This breaks the contract of object initialization in Objective-C,
as the class is free to allocate and prepare resources for the
instance without freeing previously acquired resources first.
As noted by the Object Initialization chapter of the Concepts
in Objective-C Programming guide, "Once an object is initialized,
you should not initialize it again.":
https://tinyurl.com/objc-object-init
And as observed in QTBUG-112899, the additional initialization
resulted in a memory leak.
The other part of 4bee9cdc0a
was that we now called startTrackingAt twice when drawing.
Both from setupSlider, for all consumers, and from
drawComplexControl, and as it turns out, this is the key
thing that "fixes" the pressed knob drawing of NSSlider.
For some reason, NSSlider needs the duplicate startTrackingAt
call both to draw the knob as pressed, and to not let one
drawing pass affect another drawing pass. This would benefit
from further investigation, but for now the removed leak
is an improvement.
Fixes: QTBUG-112899
Task-number: QTBUG-98093
Pick-to: 6.5
Change-Id: Ia7e6ef963910f1858d2fdb10e0323fc5bb3b2eda
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The crash is caused by the cleanup sending trace messages when the
plugin has already been destroyed. Add shutdown callback to the plugin
to indicate this has happened. We can't use signals since that also
generetes trace event.
Pick-to: 6.5
Change-Id: I2e490fc51c2aaa97c240c1496a528a6ff6077bd0
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Populate a subset of the font families at startup if the local fonts
access API is supported, and the access permission has been given.
Since this code runs at app startup there is no opportunity to request
font access. That should be done in response to user action, for
example by having a "load local fonts" button in the application.
Pick-to: 6.5
Change-Id: Ib6826deeec06ee3def0e793dd1462977710462be
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Start tracking the window geometry before a mouse drag, so that we can
revert back to that geometry when we restore from maximised. Previously,
when dragging from maximised to maximised, the restore geometry would
end up being the final drag place before snapping to maximised, instead
of where the window was before the first maximised.
Fixes: QTBUG-112814
Pick-to: 6.5 6.2
Change-Id: Ic2ddf29d6c4abdc9e8b0c5161b17aa6ee9474ea3
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We should be able to just pass `0L` and avoid defining a None macro.
Pick-to: 6.5
Change-Id: I513d726120454523627a1e66515a5a533c0238b1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Make a manual call to the geometry change handling function after a
WM_DPICHANGED event if the window is frameless, since WM_SIZE and
WM_MOVE will not be called.
Fixes: QTBUG-109429
Pick-to: 6.5
Change-Id: I79b9f386fe120ee3d06d6490d3f31a7a5d7121b0
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
In some rare situations the display link may fail to create, or will
be created in an uninitialized state:
https://bugzilla.mozilla.org/show_bug.cgi?id=1201401#c123
When the latter happens the display link thread will crash in
CVCGDisplayLink::getDisplayTimes(). Based on the Mozilla bug
report, and subsequent patch, we can detect this situation via
CVDisplayLinkGetCurrentCGDisplay(), so we follow the same
approach, and then bail out:
https://bugzilla.mozilla.org/show_bug.cgi?id=1201401#c158
Once we bail out we fall back to the timer based approach
to delivering the update request. The next requestUpdate()
will try to use the display link again, which will likely
work this time around, as the display has had time to fully
initialize.
Pick-to: 6.5
Change-Id: Ib80fd792516d1e4e7f863a82755cbf00d1eb6c34
Reviewed-by: Robert Griebl <robert.griebl@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
In 939b7bfe66 we synced up the NSMenuItem's
title to that of the corresponding NSMenu, as AppKit was observed to use
the NSMenuItem title for its heuristics of when to add dictation and
emoji entries to the menu.
But AppKit's heuristics are based on the localized name of the edit menu,
so we need to follow suit and look up AppKit's own localizations. This
is of course fragile, as we're relying on this localization continuing
to live in the InputManager table, but if that changes we'll just fall
back to using the title from the NSMenu, as we did before.
In addition, AppKit's heuristics also look for menu items in the menu
that match selectors such as copy:, paste:, etc, so even if our lookup
of the localized title fails, the additional heuristics would in most
cases still succeed in detecting the edit menu.
Task-number: QTBUG-53085
Task-number: QTBUG-79565
Pick-to: 6.5
Change-Id: I5e12973b86ab35f10a8f7434bcae8a4cf134ecfd
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
In QEglFSCursor::draw, There are two missing pipeline states
SCISSOR and STENCIL.
Fixes: QTBUG-110080
Pick-to: 6.5 6.2
Change-Id: Ifb2495de2685b7a2f80f8d39ab57d5985fe0eec1
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When a tab was moved by dragging, the tab's rectangle was drawn empty,
without the tab text. When a tab was moved by animated snap back to
its original position, the tab text was already drawn on the original
position, while the rectangle was still moving due to animation.
Adds the enum value QStyleOptionTab::TabPosition::Moving
When this option is set, QCommonStyle draws the tab text at the
current position instead of the original home position of the tab.
The QMacStyle switches over the TabPosition enum. As a moving tab
is laid out like the last tab in the given orientation, the enum value
Moving is treated like End.
Fixes: QTBUG-112277
Change-Id: I42a2d9c269dadfe9819c12dbc69e3ae995a45b09
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The gtk_fixed widget was used as a reference to obtain a fixed font
and HeaderViewFont.
This is a mistake, because the gtk_fixed widget is a container for
other widgets with fixed geometries and no layouting.
This patch makes the default style being used for a fixed font and, as
a drive-by, the combo box as a reference for a header view font.
A monospace based css provider as explicitly added to the style
context, in case a fixed font is requested. The provider is removed
afterwards.
Task-number: QTBUG-112896
Pick-to: 6.5
Change-Id: I6bfb2ee9e7befdd2102bdcc6e53ced954a024034
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
If not excluded, `VK_USE_PLATFORM_ANDROID_KHR` might end up being
undefined due to the order of includes.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: Ib7bbf42af319568bc39db0b9e5c796d25db3c364
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Turn some of the static variables into private static data members to
avoid symbol duplication during the unity build.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I9e3ee18f6e85a0f806de77f753d89a45ceaff7ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There are several duplicate symbols defined across android source files.
For now, excluding the conflicting files allows us to continue working
on bringing unity build to CI. I added some explanation and TODO's on
what I think can be done for resolving the conflict.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: Ic0b31c4ae845c69570ea5dd86316e5a795c166c4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 2991c66b75.
Reason for revert: it caused a regression with translucent Qt Quick windows. We need to find alternative way how to fix QTBUG-106583
taking into account QQuickWindow's own color property.
Fixes: QTBUG-112473
Fixes: QTBUG-112537
Fixes: QTBUG-111969
Fixes: QTBUG-112524
Pick-to: 6.5
Change-Id: I34258f4c8b045b63c8462e325b09fff927684223
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
- handle only winrt::hresult_error exceptions, as this is the only
reported cases, so we don't need ellipsis there
- print relevant warnings
Pick-to: 6.5
Change-Id: Ibf18a7eab7862e2c20f5729545387ddc7ca42952
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QIOSTracker registers itself as handlers for system notifications about
changes of the screen environment. If no QIOSIntegration instance
exists, newly detected screens are not added to the list of known
screens (see screenConnected()). This, in turn, will result in a crash
if a screen is disconnected and removed in screenDisconnected() as it
is not known to qtPlatformScreenFor() and the function returns a
nullptr.
Consider the QIOSIntegration also whenever a screen is "changed". This
is more of a safety measure do avoid crashes for unknown screens.
This situation occurs if an iOS device is used to mirror the display
via AirPlay and no actual QGuiApplication exists, e.g. Qt is only
embedded in a Framework.
Pick-to: 6.5 6.2
Fixes: QTBUG-106701
Change-Id: Id778fc5afa7c284b0536ee02b1ba2c10321cc5b1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Schmertmann <lars.schmertmann@governikus.de>
Some Windows SDKs seem to throw an exception from winrt::check_hresult()
We need to handle this accordingly. Catch the exception and print relevant warning.
Fixes: QTBUG-110408
Pick-to: 6.5
Change-Id: I1434ec425f0d0e597308b53f25f4f15049640060
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This reverts commit c0b0c7bebb.
QPlatformTheme::MouseCursorTheme and MouseCursorSize was added in
qtbase a823366f77 and qtwayland client
supports it in 1c25db5e3f23d48e330170f41b94fbd532932b02.
Pick-to: 6.5
Change-Id: Icef2f50d495ac802e3a591d92c222523972b2066
Reviewed-by: Liang Qi <liang.qi@qt.io>
This reverts commit d42cfeb84f.
Trying to help AppKit by adding the dictation and emoji edit menu items
ourselves resulted in sometimes adding the entries twice, when we failed
to detect the existing entries, or AppKit failed to detect our entries
as a reason to not add its own.
In addition, even if the entries we added were detected by AppKit and
AppKit was smart enough to not add its own, our entries were relying
on the developer to provide translation, instead of building on the
translations that AppKit already provides. And the keyboard shortcut
we set for our entries were not following system and user preferences
for which keyboard combination should trigger the entries.
Fixes: QTBUG-104709
Task-number: QTBUG-79565
Pick-to: 6.5
Change-Id: I3fabc41f85df917dbb669253ad441bccea8a5e35
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Removed the two identical functions and directly call the `static_cast`
in their place. This is to resolve a build issue when doing unity build.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I174b601e06c4acdea45cc66495c09aafba6f48f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It's unlikely we will ever use pro2cmake at this project stage,
so it doesn't make any sense to keep the 'special case' markers
in the CMake scripts. Remove them and replace with TODO where
needed.
Change-Id: I84290c20679dabbfdec3c5937ce0428fecb3e5a7
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When the DPI of a window changes due to being moved to another screen,
or the current screen reconfiguring, the mask we've set earlier is no
longer correct, as the mask was set based on the original screen's
scale factor and in relation to the former platform geometry of the
window, which now has changed.
Like the geometry of a QWindow, the mask is expressed by the user in
the QtGui coordinate system, so it's the platform's job to transform
this into the platform coordinate system and update it when needed.
Add a manual test that users a QWidget and a Q(Raster)Window side by
side.
There's still an issue with the screen change being triggered to
early, via QWindow::setGeometry, instead of when the window has
actually moved to the new screen, resulting in the paint event
flushing to a window and backingstore that is in the wrong state,
but this requires further research to fix.
Task-number: QTBUG-97642
Pick-to: 6.5 6.2
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Change-Id: I7ab2d267fbaf6ac32b507d05a418eb025b354a0b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The original issue for doing this was that invalidateCursorRectsForView
would not result in an updateCursor callback in certain scenarios on
macOS 11 and below.
In macOS 13, improvements to how tracking areas work now result in
also missing cursorUpdate calls when the mouse is pressed, which
makes sense for tracking areas in general (you don't want a drag
over a text field to reset the cursor to the I-bream), but not for
our specific case of setting a cursor synchronously.
To ensure the cursor is updated immediately, even if the mouse is
pressed, we synthesize a updateCursor event, just like we did for
the invalidateCursorRectsForView workaround.
It's up to clients of QWindow to manage their setCursor calls to
not happen during a drag operation, which we already manage in
Qt Widgets.
Pick-to: 6.5 6.2
Change-Id: I67d6e0f8e270b40da9879828455f4de943da7839
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Properly initialize outBinds - even it should be initialized by
mysql/mariadb client lib we should correctly initialize it with 0 to
avoid valgrind warnings about accessing uninitialized data.
Pick-to: 6.5 6.2 5.15
Change-Id: I85b99a7e639dad9f8d24f554cd96c5997a5838ae
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This saves us a few more roundtrips.
For rows and columns we could check if their accessibilityFrame
instersects with the table and so ignore rows and columns that
are outside of the view, but I'm observing weird corruptions in
the list returned by NSAccessibilityUnignoredChildren when
ignoring any objects.
Task-number: QTBUG-34337
Pick-to: 6.5
Change-Id: Ia2d13fff463ff26abb39acfceafcfa0761171203
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since macOS requires us to return an array with elements as the children
of a table's row. And it might ask for the children of many rows. This
is very costly, and results in a lot of QAccessibleInterface instances
being created unnecessary.
Instead, use unassociated QMacAccessibleElements as place holders for
cells, and place them in the column array of the QMacAccessibleElement
that represents the respective row. Those placeholder elements have the
synthesizedRole set to AXCell, and have the same axid as the table, for
as long as there is no corresponding QAccessibleTableCell created. Until
that point, they are in practice "managedByParent" just as the row and
column elements.
Since the place holder object knows about its column, row, and table, it
can respond to many inquiries directly without needing to create the
interface.
Once the QAccessibleInterface for the cell is required for an already
existing place holder, then we need to promote the place holder to an
independent element. We reset the synthesizedRole to nil, and change the
axid to the ID of the cell interface.
However, the cell interface might have been created and assocated with
an element before the placeholders were created when navigating through
the children of a row. So when we create an element for a table cell,
then we need to make sure that the table elements' corresponding row
is also populated, with the new element in the right place.
Pick-to: 6.5
Fixes: QTBUG-34337
Change-Id: Iff78e3b8335df8cf294fffb6579605bfeb8409ed
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We only need to compare elements to determine whether this element has
focus.
Task-number: QTBUG-34337
Pick-to: 6.5
Change-Id: Ic1388ac00381735acfbf1e5877a658f4bd534dfb
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Instead of explicitly creating an ID from an interface and then asking
for the element for the ID, ask for the element for the interface
directly.
In that helper we can also make sure that the created element is
correctly configured if the interface for which it was created was for a
table cell.
Task-number: QTBUG-34337
Pick-to: 6.5
Change-Id: Id0f9247b0b50195301b293dcabb8925c3fc2d2cf
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Store row and column in the QMacAccessibilityElement when creating it so
that we can avoid linearly looking for ourselves in the parent's data.
Row elements have their m_rowIndex set, Column elements the
m_columnIndex, and elements representing a cell have both set. Cells
are not managed by the table.
Task-number: QTBUG-34337
Pick-to: 6.5
Change-Id: I319fad1f1fda0cfa4c0b95e9e16c25c87df04351
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Make getting a QAccessibleInterface from a QMacAccessibilityElement a
member function that also tests for the validity of the interface, and
replace the respective code duplication.
Remove unused member functions accessibilityMin/MaxValue.
Task-number: QTBUG-34337
Pick-to: 6.5
Change-Id: Ie15cf0b71285e63cc485d87ced050dc541967c98
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Sync the IBASE driver behavior for primaryIndex() and record() with the
rest by assuming that the given table name has the correct casing.
Change the tests for these two function to pass an unescaped table name.
Change-Id: I6d96359f97e1acc6970b9a22fdf0e968a616b7bc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Fixes the macos build with the disabled opengl feature.
Include inttypes.h that used to be implicitly included by
qopenglcontext_p.h. It's needed for 'PRId64' macro.
Amends: ef27cc126c
Pick-to: 6.5
Fixes: QTBUG-112656
Change-Id: I970329c4aacc70790f50e1ff3a57ab2aa6f6bff7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the two options MYSQL_OPT_TLS_VERSION and MYSQL_OPT_SSL_MODE to
properly support encrypted connections to MySQL 8.0 servers.
MYSQL_OPT_SSL_MODE will not work when compiled against the MariaDB
C-Connector since it's not supported by the MariaDB client.
[ChangeLog][QtSql][MySQL] Added the two new connect options
MYSQL_OPT_TLS_VERSION and MYSQL_OPT_SSL_MODE.
Fixes: QTBUG-84797
Change-Id: Iec7d682fc00072ce5b2a824c4ea00fca4575a93e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
PostgreSQL supports the utf-8 encoding ('UNICODE') since at least
version 7.3 which is the oldest version we support. Therefore remove the
non utf-8 codepath completely.
Change-Id: I64b1a4e7b0b85141fe13f5f57e6f35f9eb7d542e
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>
The following warning is printed on systems using IBus:
qt.dbus.integration: Could not connect "org.freedesktop.IBus" to globalEngineChanged(QString)
It seems either the connection has never worked or moc has changed
Pick-to: 6.5 6.2
Change-Id: Ib96229c85c975603d28c76163fa144ddfe827b18
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When a window that has focus is destroyed we can end up calling
into nextResponder where the focus window is in the process of being
destroyed, so make sure we have a window with a valid platform window
before calling winId()
Fixes: QTBUG-110019
Pick-to: 6.5 6.4
Change-Id: I704c3597b46e465ddf2605bdb71a21cb36cb2a26
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
We should be able to just use NO_PCH_SOURCES under MINGW condition
and get the same result.
P.S. The problem with `qwindowspointerhandler.cpp`, most likely caused
due to symbol collision with `qwindowsmousehandler.cpp`. We've
encountered it again when we were building with unity.
Pick-to: 6.5
Change-Id: I20a5091d5d1a329228b5ddb4694f5fd61d803554
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We can now use NO_UNITY_BUILD_SOURCES instead, and we only need to
exclude one of the file to avoid the exclusion.
Task-number: QTBUG-109394
Pick-to: 6.5
Change-Id: I33642eece77e362f8a1de7400c14a30da7889239
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
minimumSize.width() was used instead of minimumSize.height() for the
lower bound of height
Change-Id: I330ea79de8ba39a6c55f5ed9b3210f1ff7d10fb6
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
QFileSelector::selectionHelper walks through the list of selectors
(on iOS, on my phone it's ("ios", "iOS", "en_NO", "unix", "darwin")),
creating paths and testing QDir::exists. This ends up in asset
file engine trying to load asset for something like:
"assets-library://assets/+iOS" etc. ALAssetsLibrary -assetForUrl:
returns nil for such url and we start iterating through the assets
library. On my phone (e.g.) this takes about ~6 seconds (to iterate
through pictures/videos I have), so the image picker is dismissed
~30 seconds after an image was actually selected in a picker view,
making an impression it's completely broken. Bail out early
on such url, we know we'll fail (with AssetsLibrary giving a warning
about invalid asset with UUID(null).
Pick-to: 6.5
Fixes: QTBUG-109120
Change-Id: Ia302f4151e3aade830e647a8a260479df2b29d4b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Both the full-width and partial-width paths in
QWasmBackingStore::updateTexture now correctly compute source and
target rects.
Task-number: QTBUG-112414
Change-Id: I30b0952609960f521119d3d628d2a8036f8b1fe5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We were missing the NSEventTypeMouseMoved in resolving the event type for
handleFrameStrutMouseEvent, resulting in passing on QEvent::None as the
event type to QWSI.
Pick-to: 6.5 6.2
Change-Id: I144b6459c5d4fda2839d25cd52ddb441dc7c3a47
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Some dead code was left after transferring event support to QWasmWindow.
Remove it now.
Change-Id: I40e15bc62bcbb6fff071f53c45223c8a2d12e348
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The handleMouseEvent function already takes a QEvent::Type, where clients
pass in the corresponding mouse press/release/move type. The same applies
to the handleFrameStrutMouseEvent.
To avoid the chance that clients call these functions with a conflicting
event type (handleFrameStrutMouseEvent with MouseButtonPress instead of
NonClientAreaMouseButtonPress e.g.), we remove handleFrameStrutMouseEvent
altogether and just let clients use the handleMouseEvent function directly
with the correct event type.
Change-Id: I4a0241c39aedac0d2d8d5163ba05cde72605959c
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
Right now, image picker view is shown first (it does
not require access to photos, since it's essentially
Photos app getting access to photos ...). Then, we use
AssetsLibrary to get asset for an url (using ALAssetsLibrarie's
-assetForURL method). This may trigger a permission-related alert, asking to:
a. Select more photos or ...
b. Allow access to all photos or ...
c. Deny access.
Showing this alert _after_ picker has selected an image makes little sense
(and probably was never intended this way anyway). Instead, we now use
Photos.framework to check the authorization and, if needed, we request
an authorization (when the current status is 'Nondetermined'). If authorization
is 'Granted' as a result, we show picker view and proceed as normal/before.
Pick-to: 6.5
Task-number: QTBUG-109120
Change-Id: I0acfd7b0476346360d75a5e37f5845aaf2d6e3e0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The end of a move or resize might happen with the mouse still inside
the non-client area of the window, in which case we correctly resolved
the type to QEvent::NonClientAreaMouseButtonRelease, but we sent it
via QWindowSystemInterface::handleMouseEvent, which sets nonClientArea
of the event to false. This in turn resulted in QGuiApplication sending
a synthetic QEvent::MouseMove in case the position was out of sync,
instead of the correct QEvent::NonClientAreaMouseMove.
This should really be cleaned up on the QWSI level, as there is no
reason to have a dedicated API for handleFrameStrutMouseEvent, when
handleMouseEvent already takes an event type, but for now we fix the
immediate issue in the Windows platform plugin.
Pick-to: 6.5 6.2
Change-Id: I8a831f5f19adb0625b29b50ebce9c0c6514e93f3
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The windows should not let events through to targets below (unless
they are Qt::WindowTransparentForInput, which is handled
independently). Therefore, stopPropagation and preventDefault are
now called regardless of whether the window has handled the event
or not. If the event is not handled explicitly, we still consume the
DOM event so that the windows/elements below don't get focus by
mistake.
Fixes: QTBUG-111706
Change-Id: Idc78ac5076e97992d9f6f13a1fa574d0df4178ac
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
A foreign window can be used both for embedding a Qt window into a
native window hierarchy, or for embedding a native window into a Qt
window hierarchy. In the former case, we should not modify the foreign
window in any way. Since the platform does not know anything about the
intended use case at the time of the foreign window creation, it should
avoid modifying the foreign window in any way, and should instead pick
up the foreign window state and reflect that through QWindow.
Pick-to: 6.5
Change-Id: Id2e39d101277ecebd656d615cea3e7f734a4b0a6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A foreign window is a single NSView, and unlike our QNSView, where we
in addition manage a NSWindow for top level windows we should treat
the foreign window as just an NSView. It's not our place to neither
create nor dispose of any NSWindows attached to the foreign window.
Pick-to: 6.5
Change-Id: I88aa796c679be0489abf4999829d1378ba054bdc
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Now that the browser compositor is used for rendering windows, the
method has become redundant, as windows that got resized during screen
resize will schedule their updates directly with the compositor.
This also fixes an assertion in QPlatformWindow::hasPendingUpdateRequest
as no windows without pending update requests will now have update
requests delivered.
Also offers a significant speedup with multiple restored window setups.
Fixes: QTBUG-112289
Change-Id: Ie5dff69c04d66c4aef8351adef0da8530daf7ab8
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The logic for this should ideally be handled in setParent(), but
for now let's clean up the code a tiny bit.
Pick-to: 6.5
Change-Id: Id2370d6704625038ab6b4fa246dea5d1c037371c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Initially attempted in 096b56f336,
but that broke QQuickWindow::grabWindow(), which at the time was
not prepared for grabbing non-visible windows.
This is no longer an issue, as QQuickWindow::grabWindow() has fallback
logic for non-renderable windows. QWidget::grab() also works fine,
as it grabs from the backingstore directly.
For top level windows we apply the visibility state to both the
NSWindow (orderIn/Out), and to the NSView (hidden=YES/NO).
Pick-to: 6.5
Change-Id: I617b292ca6bfba66e65b55941c5b002e415da88d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When compiling with CTF tracing, QTRACE_LOCATION not set warnigs are
printed constantly. Fix this by changing the log to info and default
log message level to warning.
Pick-to: 6.5
Change-Id: Ib167ec1b41ff0134fa9b3eba09394bb0bef54379
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
Reviewed-by: Antti Määttä <antti.maatta@qt.io>
During refactoring in 3850404114 the logic
was changed in a way that ended up sending non-client mouse events even
if frameStrutEventsEnabled() was not set on the platform window.
Pick-to: 6.5 6.2
Change-Id: Icbde51641020aeec99572d80859082fdcf656311
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The main responsibility of QCocoaWindow::recreateWindowIfNeeded() is
to decide if the platform window is top level or not, and if so needs
an NSWindow or NSPanel accompanying it.
Once that decision has been made, and we've created an NSWindow or
NSPanel, and made the view the content view of this window, we need
to apply the QWindow properties to the newly created NSWindow or
NSPanel. But doing so in recreateWindowIfNeeded increases the
complexity and responsibilities of the function, so we move the
logic to [QNSWindow setContentView:] instead. This is analogous
to applying the properties during [QNSWindow init], but since we
are now the content view we can use the same code paths to apply
the initial properties as we use when they are updated later on.
Pick-to: 6.5
Change-Id: Idb4c812f4b22a029030bf4638357cf8628caea40
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Add support for time zones in the IBASE driver, which was introduced in
firebird 4.x. TIMESTAMP WITH TIME ZONE data type is supported in order
to store and retrieve a QDateTime with the time zone.
Task-number: QTBUG-111879
Change-Id: I631b4262d17796a17630379b7d659f88244a23ad
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
...and the view is using a CAMetalLayer and a non-default contents
placement. (the default would be scaling/stretching of the content,
that hides a lot of out-of-sync size problems during resize, but
is not great for UIs so we never use that in practice)
This achieves two things:
- when presenting from the main thread with transactions (i.e. with
parent patch in place), resizing the window will be even nicer,
basically flicker free on the M1 Mini as well,
- when presenting from outside the main thread, resizing becomes
a lot smoother, even if the window background is still visible
from time to time due to the size not catching up and due to
Qt having to use NSViewLayerContentsPlacementTopLeft.
Thus resizing Qt Quick-based windows, which use the threaded render
loop by default and cannot use presentsWithTransaction, becomes a
nicer experience than before, even if not always perfect.
This comes at the expense of not animating during the live resize
operation whenever the size is not changed (because only a resize
triggers updates then, the CVDisplayLink-based updates are skipped
in order to reduce flicker due to out of sync sizes)
To force the old behavior, set QT_MAC_DISPLAY_LINK_UPDATE_IN_RESIZE.
Task-number: QTBUG-107198
Change-Id: I796c3a74119510c62f7245b0ebbe78797d2df03e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
on Windows virtual keyboard sends characters through the textInput handler,
we can use the same mechanism as Android to create an offscreen
input element and send the characters from there.
Fixes: QTBUG-107139
Pick-to: 6.5
Change-Id: I84a143aedf93d22521fcfa368532eed8c0e7d002
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
This mimics the behavior displayed by the Cocoa window
Fixes: QTBUG-111436
Change-Id: I800fd15e870e54cf2c22ba5bd7f0c8b3f7f85bbf
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
So far, the framele/tite-less window maximising has been done by
adjusting the MINMAXINFO to prevent them from covering the taskbar.
It does not work when moving the windows from one screen to another
using keyboard shortcuts, since the MINMAXINFO is that of the old
monitor. This moves the adjustment to the WM_SIZE message that occurs
after the window has been resized.
Pick-to: 6.5 6.4 6.2
Change-Id: I0d36fe5d2e8eaa0739414835b8d99a0b2ed44cf6
Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
QXcbConnection::xi2HandleHierarchyEvent() calls xi2SetupDevices()
whenever the event tells us that a device was added or removed; but
until now, those instances were not getting deleted until application
exit. That was a memory leak, and also tended to get us confused when a
newly-attached device happened to reuse the same device ID of something
that was there before but had been removed in the meantime. Now, we hope
that QInputDevice::devices() will be in sync with reality as X11
presents it to us.
Amends da5dea807f6589f2ed0c etc.
Task-number: QTBUG-46412
Fixes: QTBUG-56214
Fixes: QTBUG-98720
Fixes: QTBUG-99331
Task-number: QTBUG-104878
Fixes: QTBUG-112141
Pick-to: 6.2 6.5 6.5.0
Change-Id: I573805a41a12850f94561a030071f1437c4dc37e
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
When we fixed the callers of toSQLTCHAR() to use the result's size()
instead of the input's (which differ, if sizeof(SQLTCHAR) != 2), we
exposed callers to the append(0), which changes the size() of the
result QVLA. Callers that don't rely on NUL-termination (all?) now saw
an additional training NUL.
Fix by not NUL-terminating, and changing the only user of SQL_NTS to
use an explicit length.
Amends 4c445ef0ba and
46af1fe49f.
Done-with: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Pick-to: 6.5 6.5.0 6.4 6.2 5.15
Change-Id: I6210b77e9417f46294df94cb32ab4134af8dc4c2
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
A coming change to support streaming requires networking so having it
in corelib is dubious.
Pick-to: 6.5
Change-Id: Idc25abe23b5ed07823d749294796c9f318ef1744
Reviewed-by: Hatem ElKharashy <hatem.elkharashy@qt.io>
Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
When a window-modal window has a transient ancestor, Qt treats this
ancestor window as modally blocked by the modal window, as if it had
been a true non-transient parent of the modal window.
Unfortunately, this is not how macOS natively behaves. Window-modal
windows only block their direct parent, and AppKit will happily
send events to any other top level window. This is different from
how application modal windows work, where NSApplication will filter
many events (but not all) in [[NSApplication _modalSession:sendEvent:].
Note that NSWindow.worksWhenModal has no effect in this situation,
as that property is only considered by AppKit for application
modal session are active (and NSApp.modalWidow returns non-nil).
Instead of trying to replicate the event filtering that AppKit does,
which would be fragile, we disable some of the effects these events
could potentially have, by for example preventing modally blocked
windows from becoming key, and temporarily disabling the close
button in the title bar.
One remaining issue is that, unlike with application modal windows,
the modally blocked transient parents can still be ordered above
the modal window. Fixing this requires informing the window server
about the modally blocked state of the window, which we can't do
using public APIs. Even returning NO from [NSWindow _allowsOrdering]
is not sufficient.
Task-number: QTBUG-104905
Pick-to: 6.5
Change-Id: I7e764a354f397ae6ef61304ca5442a4e1bb7589c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The typical way to set up menus on macOS, which we follow, is to create
NSMenuItems with an action selector set (copy:), but without a target.
This will result in AppKit finding a target dynamically, starting with
the first responder, walking the responder chain, and then moving on
to other NSWindows, before ending up in the NSApplication and its
delegate.
Unfortunately, we don't have a mechanism in Qt to forward generic
actions, such as the cut/copy/paste, or selectAll, so we rely on
mapping the actions back to QCocoaNSMenuItem that we can trace
back to a QPlatformMenuItem that we in turn emit activated() for.
Normally this works fine, but in the case where the Qt app is embedded
in a native UI, which has its own menu items with cut/copy/paste,
we'll get callbacks into QNSView for actions triggered by a generic
NSMenuItem.
In that case, we need to bail out, but we must do so without calling
[super forwardInvocation:invocation], as that will just try to invoke
the action on ourselves again.
It's unfortunately too late to try to redirect the action to another
responder, that might have handled the action, and it's questionable
whether that would be the behavior we'd want, as that would possibly
result in e.g. pasting text into another window than the Qt one that
currently has an active cursor in a text entry.
Fixes: QTBUG-111916
Pick-to: 6.5
Change-Id: I56318e4f7efd779cd20bf577aec8c2de04a6a142
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The machinery is quit fragile, so any logging will help here.
Pick-to: 6.5
Change-Id: I1906c0e33b4afbf649a20bfe2aa7210b6822087e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Currently we render shadow and default background-color even for
frameless windows with transparent content.
This behavior is not consistent comparing to other platforms.
An example of such window is InputSelectionHandle from
VirtualKeyboard module.
This commit disables shadow-box and provides transparent
background-color for QWasmWindow which are frameless.
It also provides distinction between "frame" as logic property
of window and "border" as visual decoration.
Change-Id: I902692ea561a2e88e2e6ab7faad8e3eeb536a26b
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Fix some tests so they will correctly work with Interbase (Firebird 3.x)
Change-Id: Ib3c8ceaf31fa01af3a00a9772350b49cee8b2342
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A table name or identifier must not be longer than 30 (< Oracle 12.2) or
128 bytes (sadly not characters).
Change-Id: I49192afaf908e12f5cfd20c754640b6117b03a71
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Misc cleanup of the IBASE driver - use qsizetype and range-based for
loops.
Change-Id: I69fe8ed3303fb352b59989c625de5a51239cf604
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This reverts commit 6c2387571a.
Caused a regression when the edit menu did not have any entries from
the system. Fixing that regression (out of bound index, crash), revealed
that the original patch is simply not working anymore - items are still
duplicated anyway.
Fixes: QTBUG-111798
Pick-to: 6.5
Change-Id: Id4a88f30e2cf300bc63181c4bc7aa113a8b13ac6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Previously the widget stayed black and we printed
"QBackingStoreDefaultCompositor: the QRhi has changed unexpectedly,
this should not happen".
To make it work the compositor is recreated in addition to the rhi
and the widgets are informed with the internal events.
Change-Id: I982d08bd3530478fe0f827080154c008a92a812e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Deals with:
* unknown class name 'Object'; did you mean 'QObject'?
* use of undeclared identifier 'QTimer'; did you mean 'QTime'?
Pick-to: 6.5
Change-Id: Id63064e70090ed1f816fa19db047b382220d634c
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Tor Arne Vestbø
Mikolaj Boc
Shawn Rutledge
Volker Hilsheimer
Morten Sørvig
Liang Qi
BogDan Vatra
Tobias Koenig
Matthias Rauter
Colin Snover
Mårten Nordheim
Timur Pocheptsov
Axel Spoerl
Lorn Potter
Jani Heikkinen
Assam Boudjelthia
Friedemann Kleint
Amir Masoud Abdol
Timothée Keller
Antti Määttä
Yuhang Zhao
Ilya Fedin
Oliver Wolff
Thorbjørn Lund Martsum
L. E. Segovia
Yuhang Zhao
Piotr Wierciński
Inho Lee
Vladimir Belyavsky
Jan Moeller
Christian Ehrlicher
Alexey Edelev
Carl Schwan
Christian Strømme
Andreas Bacher
Laszlo Agocs
Marc Mutz
David Redondo
Michal Klocek