Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: I75f8956c5fc094402837f96bd4598b60e3a7c649
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: I761e99060caa64750eecf4fde4acc7f68d029936
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: Ia905211d2b2bc5b49e5f9b50f2407544e939779d
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: I3fde4b0c8867eaf50162dec3178e5c6e5dad3a6f
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QCoreApplication::requestPermission` is not in
sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Idd1f32f48ef8b2a8d22d90a4df346b931f1f9cfa
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QMetaEnum::fromType` is not in sync with the
intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I9160c1d76c0078f599d028c39fb3db17a34c3dd7
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QObject::findChildren` is
not in sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I325008c22e82c002afe8cbeaa847af7a28277a0b
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QPointer` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Iefaa12a4ac4f05cb5dbadd126b920cfc6a118d91
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QUtf8StringView::QUtf8StringView(const Char*,
qsizetype)` and `QUtf8StringView::QUtf8StringView(const Char*, const
Char*)` are not in sync with their intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I916e840677f26d855f0bd825e6a913100ac261e2
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for some of the members of `QFuture` is not in sync
with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I142124e02c9264c8c1b82bb8130162ee89c0f3a5
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
These are POD types, so there's nothing to be unwound in case of
exceptions (and the only one that could happen is the Q_CHECK_PTR).
Change-Id: I79e700614d034281bf55fffd178f91fe21685f03
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The shaped clock example has the appearance of the analog clock, which
was refurbished with 619ec1a640. This
change applies the refurbished design to the shaped clock.
Task: QTBUG-118871
Pick-to: 6.6
Change-Id: Ibcfc8e9fb239a1c6f7ea685f6cab1e50b2060a53
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's the actual system call on Linux, inspired by the 4.4BSD call of the
same name (and our BSD code also uses statfs(), except for NetBSD, but
it probably could use statfs() there too). statvfs() wasn't introduced
until POSIX.1-2001, though glibc added it in 1998 for version 2.1 and
Bionic only for NDK version 19 in 2019.
So we could merge the Android code to the POSIX version, but it's easier
to merge the non-Android code to the raw system call.
Change-Id: I8f3ce163ccc5408cac39fffd178dbd83567a78d5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It's what the public API returns. There's little reason to use ulong,
despite that being the type that struct statvfs uses (on Windows, that
was 32-bit anyway).
Saves 8 bytes on the size of the QStorageInfoPrivate class.
Change-Id: I8f3ce163ccc5408cac39fffd178db8cfb9e5e4f6
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
There is a difference between findChild() and findChild("") that was
not explained in the documentation. So, add a sentence to clarify it.
The object's search when there are several direct ancestors was
documented as "undefined". Change it to "first child in children()".
Task-number: QTBUG-103986
Pick-to: 6.6 6.5
Change-Id: I25cb01b87d3b24af498ad494b3f353840ee78807
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
QWindowsScreen uses setupAPI.h's SetupDiOpenDevRegKey function to read
EDID data for monitors. This function is documented as returning
INVALID_HANDLE_VALUE in case of failure.
The QWindowsScreen code was ambiguous in the sense that it considered
both nullptr and INVALID_HANDLE_VALUE as being invalid handle values.
This inconsistency is likely not a bug, but makes the code harder to
understand.
This patch removes this ambiguity, and QWindowsScreen now follows the
documented behavior when SetupDiOpenDevRegKey fails. In addition, we
replace use of unique_ptr with the new QUniqueHandle template class
because HKEY is a handle type, not a regular pointer type.
Pick-to: 6.5 6.6
Change-Id: Ia863bda504077e59833f6f7a0f855e7915e4edd9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
There is no need to run the catch-all DPR update if
the window is not visible.
Pick-to: 6.6
Fixes: QTBUG-117762
Change-Id: Ib4e235fed4b21e5aa2ecafa960ab0900e2b68295
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In rare situation, base size could be (-1,-1) or (-2,-2) for high
dpi, it will be converted into huge positive numbers.
https://tronche.com/gui/x/icccm/sec-4.html
If a base size is not provided, the minimum size is to be used
in its place and vice versa.
Pick-to: 6.6 6.5 6.2 5.15
Task-number: QTBUG-117702
Change-Id: I900ed82f2291fb454d7e34a0dee27459d0a57240
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Add missing include of global module header.
Drop unneeded global namespace qualifier for constant in
our namespace.
Amends 6017695bfa
Change-Id: I04633030af13df3c3359fc09b08b4a5f031013a9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Using this trick we force CMake xcode generator to give the more
specific project name when configuring standalone tests.
Change-Id: Ic679003c574c0407bdc8df9eecf3762db214fd50
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Method is trying to infer the signature from the types of the
arguments, but since the argument for the view is a plain jobject
this signature is wrong, method is not found and the view is never
inserted.
Change-Id: I3cbf9bccbcb1e5526f843213ba0f66e5bd1e7107
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When a QWindow is parented into another window, either via its constructor,
or via setParent(), we also update the QObject parent of the window. This
in turn sends ChildAdded and ChildRemoved events to the new and old parent
of the window, as well as ParentAboutToChange and ParentChange to the window
itself.
But at the point when these events are sent, the QWindow parent relationship
has not been fully established. We have not updated d->parentWindow, nor
have we propagated the parent relationship to the platform window.
This is problematic because clients can not use these events to react to
window parent changes synchronously. For example. trying to raise a child
window when added to a parent is not going to work, because at that point
the child window isn't a native child of the parent.
Instead of re-using the QObject events for QWindow, like QWidget does,
by delaying the events or sending them manually at a point when the
window parent relationship has been fully formed, we opt to add new
dedicated events.
Change-Id: I019c14eba444861f537e4f68ab3a82297f843cf7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is somewhat of a corner case, where there is a single sub-window,
setViewMode(TabbedView) is called before addSubWindow(), and the latter
is called before show(). The sub-window would be active, i.e.
subwindow->d_func()->isActive is true and QMdiArea::aboutToActivate() is
emitted, but QMA::emitSubWindowActivated() is never called for that
sub-window, resulting in that sub-window shown as
unmaximized/with-a-title-bar instead of as maximized/tabbed as is
expected in TabbedView.
Pick-to: 6.6 6.5
Fixes: QTBUG-114188
Change-Id: Ia7b2cfd07c51867707866a1f99f70129bbdc0e3e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
endDrag(false) meant to end a drag with a dock location change.
endDrag(true) meant to abort a drag without a dock location change.
Replace this with a meaningful enumeration.
Define a dummy enum for builds w/o QDockWidget.
Task-number: QTBUG-118578
Task-number: QTBUG-118579
Pick-to: 6.6 6.5
Change-Id: I786f4210f5a3ee67ffcf0dc9285f77a480148569
Reviewed-by: David Faure <david.faure@kdab.com>
QGuiApplicationPrivate::processMouseEvent() requires the following
conditions to be met in order to trigger a double click event:
1. The same button should be pressed (kept in mousePressButton member)
2. The time between two press events should not exceed doubleClickInterval
3. Movement between presses shouldn't be bigger than doubleClickDistance
Unfortunately, when we are processing *synthesized* mouse events (from
touch), in order to check criterion 2) we cannot rely on
QPointingDevicePrivate::pointById(0)->eventPoint.pressTimestamp();
because this was already updated in QGuiApplication::processTouchEvent(),
so it does not any longer reflect the *previous* press timestamp, but
the current one.
Therefore we could not reliably calculate the time between the previous
press and the current press (in fact, it never exceeded the
doubleClickInterval condition)
I suspect this occurs with all touchscreens, but at least it was
reproduced with e.g. a NVIDIA Terra / Thinkvision touch screen on
Windows 11 and Dell Express SVC touch screen on Windows 11.
=> Since QGuiApplication is a singleton, add a static local variable to
remember the time stamp of the last processed press event.
Autotesting has been modelled in PS7. However, QTest::touchEvent is
unable to synthesize hardware specific detection latency and stray
touch events, which actually reproduce the issue.
=> Not adding an autotest.
Fixes: QTBUG-112479
Fixes: QTBUG-119032
Fixes: QTBUG-100688
Pick-to: 6.6 6.5
Change-Id: Idc97fb9d49ed334f56d702d420451fc062e9b5a9
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QList::QList(InputIterator, InputIterator)` is
not in sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" command.
Task-number: QTBUG-118080
Change-Id: I576a3b71ba39cec0d51f08f7db9771401e1fa340
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QScopedArrayPointer::QScopedArrayPointer(D*)` is
not in sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" command.
Task-number: QTBUG-118080
Change-Id: Icf4178989952bbc7dac9a0e8b7cfd031eed3a9d2
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
Some of the documented callables in "qsharedpointer.cpp" are not in sync
with the template declaration of their intended target.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Iadac55e944aa425205b9d1cd8b4189ffacb4a089
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for
`QModelRoleDataSpan::QModelRoleDataSpan(Container&)` is not in sync with
the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I08c7adf901fac81bb1c115a5017908cba4656bea
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Release and RelWithDebInfo builds always default to passing
--release to androiddeployqt. There is an opt-in variable
(QT_ANDROID_DEPLOY_RELEASE), presumably for Debug builds,
but there is no opt-out for non-Debug builds. Instead,
there is a hack for autotests.
In addition to tests, there are situations during development
where we want to deploy a release build, but do not have or
want to set up the release signing infrastructure. Having a
variable to opt-out is then very useful.
Change-Id: I6c6b9aaccad7d9d4f86745f3ed7d3c475b383ad3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
More logical than throwing it in the main rhi backend object.
In addition, holding on to the generated data from the last
setShaderResources() per command buffer has great value if/when
more granular resource updating is introduced at some point.
Change-Id: I26887423cf66b27995ec92ae9965d99a40267066
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kristoffer Skau <kristoffer.skau@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
CBV and SRV descriptor ranges default to
DATA_STATIC_WHILE_SET_AT_EXECUTE with RS 1.1.
Due to how constant buffers (that back
Dynamic+UniformBuffer QRhiBuffers) are implemented,
DATA_STATIC is more appropriate, leaving more optimization
opportunities. The buffer contents will not change once
setShaderResources() is called (which is what issues
the SetGraphicsRootConstantBufferView()). In fact
the buffer contents should not be changing anymore during
the whole render pass recording (begin..endPass).
Change-Id: I5901a6d9608fb7c61f04f9d6a3a9acebce37a673
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Nothing is relying on the binding list being sorted based on the
binding number. In many ways the D3D12 backend is very similar
to the OpenGL one: the srb merely holds some flags derived from
the binding list and that's it really, no native resources or
other content are owned directly by the binding set objects.
Change-Id: I35d652c9738308bff691095e43aea9706031dd90
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Because it is.
Amends 405244fe30.
Pick-to: 6.6 6.5
Change-Id: Icc7bb1a000e89b63254ca5c306325d01603eb1d4
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Going through the UIImage.CGImage flattens the image to monochrome.
Change-Id: If74c33badb4e94253b3bf21b6d69bb9f521d6bff
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This fixes an infinite loop reported by a user who had both the
definition of text/javascript from shared-mime-info 2.3 and the
definition of text/javascript from shared-mime-info 2.4 installed at the
same time. In 2.3, text/javascript is a subtype of
application/ecmascript, but in 2.4 application/ecmascript is a subtype
of text/javascript. Having both at the same time resulted in circular
inheritance.
https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/258#note_2167707
[ChangeLog][QtCore][QMimeDatabase] Added code to detect and break
circular inheritance loops in the MIME data, which were causing infinite
loops
Pick-to: 6.6 6.5
Change-Id: Ic207b1593a49c7bb88e4fd810d8f88aa630087ce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: David Faure <david.faure@kdab.com>
If manual test target is created using the standard Qt API but not
qt_internal_add_manual_test command, we need initialize autotools
for these targets. Add the generic functionality that ensures that
autotools are inialized for all manual tests.
Pick-to: 6.5 6.6
Change-Id: Ic048760390174d1be2f01096d70e84458f1c870f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
So far, there was custom handling for exposing the selection
of tab bars on Windows via UIA, s. QWindowsUiaSelectionProvider.
Implement QAccessibleSelectionInterface for QAccessibleTabBar,
so selection is exposed via the platform a11y bridge on all
platforms.
(This makes the custom handling for tab bars
in QWindowsUiaSelectionProvider obsolete for qtbase's own classes,
but there are 4 more uses of the QAccessible::PageTabList role in
qtdeclarative that might need a closer look before dropping
the custom handling from QWindowsUiaSelectionProvider.)
For consistency, also set the selectable/selected state for
the tab buttons (that are the selectable children of the
tab bar).
Sample use via AT-SPI on Linux using Accerciser to interact
on the a11y level (check the current selection, then select
the second tab):
1) run the qtabbar example (tests/manual/qtabbar)
2) start Accerciser
3) select the tab bar in Accerciser's tree view of the
a11y hierarchy
4) query for currently selected item, switch selection
from "Tab 0" to "Tab 1" by using the following commands
in Accerciser's IPython console:
In [10]: sel = acc.querySelection()
In [11]: sel.nSelectedChildren
Out[11]: 1
In [12]: sel.getSelectedChild(0)
Out[12]: <Atspi.Accessible object at 0x7fe01ce8a240 (AtspiAccessible at 0x43928c0)>
In [13]: sel.getSelectedChild(0).name
Out[13]: 'Tab 0'
In [14]: sel.selectChild(1)
Out[14]: True
In [15]: sel.getSelectedChild(0).name
Out[15]: 'Tab 1'
Equivalent on Windows using NVDA's Python console:
1) start NVDA
2) run the qtabbar example (tests/manual/qtabbar)
3) click on the first tab ("Tab 0") in the tab bar
4) press Numpad_insert+control+z to start the NVDA Python console and
capture snapshot variables
5) query and use the interfaces using NVDA's Python console:
>>> import UIAHandler
>>> tabbar = focus.parent
>>> selectionpattern2 = tabbar.UIAElement.GetCurrentPattern(10034).QueryInterface(UIAHandler.IUIAutomationSelectionPattern2)
>>> selectionpattern2.CurrentFirstSelectedItem.CurrentName
'Tab 0'
>>> selectionpattern2.CurrentLastSelectedItem.CurrentName
'Tab 0'
>>> selectionpattern2.CurrentItemCount
1
>>> selectionitempattern = tabbar.children[1].UIAElement.GetCurrentPattern(10010).QueryInterface(UIAHandler.IUIAutomationSelectionItemPattern)
>>> selectionitempattern.Select()
0
>>> selectionpattern2.CurrentFirstSelectedItem.CurrentName
'Tab 1'
Fixes: QTBUG-104602
Change-Id: I49b05bb84852c86a2b8669d7843fe173caf28e18
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
If the attribute does not follow the required
"name:value" syntax, ignore it, rather than crashing
if it doesn't contain any colon.
Same issue as spotted by Jan Arve Sæther during the review
of a QTBUG-118106 related change that would have introduced
the same issue in UIA code.
Pick-to: 6.6 6.5
Change-Id: Id391502ed7aec7f09ef2826a456f2e4737af045e
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
It follows f9e4402ffe.
Fixes: QTBUG-105395
Pick-to: 6.6 6.5
Change-Id: I399c448517b7dbdc28ba33f75ae43102836a8998
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
