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>
Thorbjørn Lund Martsum
Tor Arne Vestbø
L. E. Segovia
Tobias Koenig
Yuhang Zhao
Assam Boudjelthia
Piotr Wierciński
Morten Sørvig
Shawn Rutledge
Antti Määttä
Timothée Keller
Amir Masoud Abdol
Inho Lee
Axel Spoerl
Vladimir Belyavsky
Jan Moeller
Christian Ehrlicher
Ilya Fedin
Alexey Edelev
Volker Hilsheimer