Age | Commit message (Collapse) | Author |
|
Drop the com.sun.star.accessibility.GetStandardAccessibleFactoryService
UNO service that was used to create instances of
the a11y classes for (mainly vcl) widgets.
The service was needed to break a dependency cycle.
However, with
Change-Id: Ib46c87446dc9121d3b8e735e0e5a40594da73cc5
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Dec 17 12:04:04 2024 +0100
a11y: Merge accessibility module into vcl
and all the preparatory commits in place, there
is no more dependency cycle, as the a11y classes
for vcl widgets no longer depend on any modules
"above" vcl.
Therefore, drop the UNO service and the abstract
vcl::IAccessibleFactory class and other related
classes.
Make all methods in the AccessibleFactory class
(that was previously subclassing the abstract
IAccessibleFactory) static helper methods,
and call them directly.
The UNO service dropped in this commit was
introduced in
commit 1af510e95147374e5289ae1c12f1f280931919f4
Date: Wed Feb 21 11:30:47 2024 +0200
Create an UNO service to do the symbol lookup in toolkit::AccessibilityClient
and its documentation was already clearly stating
that it's only meant for LibreOffice internal use:
> /**
> The toolkit module uses this to get a pointer to the AccessibleFactory from the acc module.
> Because we have a dependency in our modules that goes the "wrong" way.
>
> @since LibreOffice 24.8
>
> @internal
>
> ATTENTION: This is marked <em>internal</em> and does not
> have the <em>published</em> flag, which means it is subject to
> change without notice and should not be used outside the LibreOffice core.
> */
Change-Id: Ib97396a4bad486d9530361dd851ad3ee0f9681b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178689
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
toolkit::IAccessibleFactory and
vcl::IAccessibleFactory are abstract classes
providing methods to retrieve the XAccessible or
XAccessibleContext for different vcl widgets.
Both are implemented by the same class in the
accessibility module: AccessibleFactory
Merge toolkit::IAccessibleFactory into
vcl::IAccessibleFactory to have things in
one place, and have everything in vcl, i.e.
no longer part of it in toolkit that itself
depends on vcl.
Change-Id: I5da571899c9987267cbec2950630d0c44ff4d2f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178643
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
After
commit 168512dce7f1f1453c045584d47bd78a0a6c73f7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Dec 12 18:06:13 2024 +0100
a11y: Stop using VCLXWindow in vcl a11y classes
and further related commits, VCLXAccessibleComponent
no longer depends on anything in the toolkit module,
so move it from there to vcl.
This way, subclassing VCLXAccessibleComponent (as the
a11y classes for vcl widgets do, currently located in
accessibility/ ) no longer introduces a toolkit
dependency.
Change-Id: I4fd33fb1dc2265d75e8ca9ad87bcc70db61639d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178434
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Adjust VCLXAccessibleComponent and subclasses to take
a vcl::Window arg instead of a VCLXWindow in the ctor
and drop the VCLXAccessibleComponent::m_xVCLXWindow member
that used to hold a reference to the VCLXWindow.
(VCLXAccessibleComponent still holds a VclPtr
to the corresponding vcl::Window.)
Instead of passing the UNO/toolkit peer (VCLXWindow
and subclasses) to the AccessibleFactory to create
an XAccessibleContext context for the underlying VCL
widget, pass the underlying vcl widget, which can
now be passed as is to the corresponding ctors
of VCLXAccessibleComponent and specialized subclasses.
This follows earlier commits replacing the use of the
VCLXWindow classes by direct uses of the vcl::Window
subclasses inside VCLXAccessibleComponent and subclasses
and is the next step in reducing the UNO/toolkit
dependency in the accessibility implementation for
vcl widgets.
For now, the logic where those accessible objects
are created remains in VCLXWindow::CreateAccessibleContext
and overrides, but that can change in the future.
`IAccessibleFactory::createAccessibleContext(VCLXMultiLineEdit*)`
is just dropped and doesn't need its own replacement:
The previous VCLXMultiLineEdit variant was
creating a VCLXAccessibleEdit like the variant
taking a VCLXEdit, but VCLXMultiLineEdit doesn't
subclass VCLXEdit.
The vcl MultiLineEdit however subclasses Edit,
so VCLXMultiLineEdit::CreateAccessibleContext can make
use of `IAccessibleFactory::createAccessibleContext(Edit*)`
as well now.
This also implements what was mentioned in earlier
commit
Change-Id: I67bb7a6a237e57d0c522790c09a595c02ac06325
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Dec 12 17:16:29 2024 +0100
sw annotation win a11y: Skip VCLXWindow logic
:
> Drop the comment about the code being dodgy from
> SwAnnotationWin::CreateAccessible. This commit partially
> addresses it and switching VCLXAccessibleComponent
> to using the vcl::Window will take care of the rest,
> see upcoming commit
> Change-Id If0894e733273eecad268c6a932ecee7c2e34b4c2
> ("a11y: Stop using VCLXWindow in vcl a11y classes").
Now that the VCLXAccessibleComponent ctor takes a
vcl::Window, the sw::annotation::SwAnnotationWin
can be passed directly.
From a user perspective, no change in behavior is
intended by this commit.
Change-Id: If0894e733273eecad268c6a932ecee7c2e34b4c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178385
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Change-Id: I3724481e81a5f2987567b51424da479879ca78ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178364
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Added in:
commit d66a97d5622bfc7c8d68452eb5a3c2378b0b1820
Date: Thu Jan 12 08:29:24 2023 +0100
loplugin:crosscast (clang-cl)
> winaccessibility/source/service/AccTopWindowListener.cxx(47,36): error: suspicious dynamic cross cast from 'css::accessibility::XAccessible *' to 'VCLXAccessibleComponent *' [loplugin:crosscast]
> else if (auto pvclxcomponent = dynamic_cast<VCLXAccessibleComponent*>(pAccessible))
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Iee7585dd2fa0d92af3be6b89d7d08326de3d1e7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145380
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
AccTopWindowListener::HandleWindowOpened no longer does
that crosscast now, see
Change-Id: Ic96d2c95128af144c7769aac40707299b1c80f8c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Dec 5 14:07:52 2024 +0000
tdf#164093 tdf#157001 wina11y: Use vcl::Window's actual XAccessible
Change-Id: Ifca76a5d519099f9cbe06f8bde606e01871363fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177891
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Other than most of the a11y implementations for vcl
classes, VCLXAccessiblePopupMenu etc. do not
make use of any VCLXWindow (i.e. UNO/toolkit wrapper of a
vcl::Window) and thus do not depend on the toolkit
module, which the accessibility module depends on.
Therefore, there's also no need to use the accessible
factory to create them (which is needed when toolkit
classes are involved to avoid a dependency cycle).
Move those classes from the accessibility module to
vcl and add a new method Menu::CreateAccessible and
move the logic from AccessibleFactory::createAccessible
there. Drop the now unnecessary factory methods
previously used for those classes.
No change in behavior intended (yet), but this
also simplifies the code involved for the
tdf#164093 scenario.
Change-Id: Ie3f6f1a02bf6662206d31383473cdc868e1f9164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177812
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Move helpers to convert between the Rectangle, Point and Size
classes in vcl and in css::awt from VCLUnoHelper (in the toolkit module)
to vcl::unohelper (in the vcl module), for reuse in vcl in upcoming
commits.
Change-Id: I7b11c8a6b8c843a01ce25b1e4c0fb1869ad1e6ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177816
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This method from the unpublished XAccessibleExtendedComponent
interface is not used by any of the a11y platform bridges, and
I don't know of any platform a11y API that would need it.
In order to report character/font attributes, there is the
XAccessibleText interface and its
XAccessiText::getCharacterAttributes method instead, which
actually gets used by the platform a11y bridges.
Therefore, drop this method to simplify code, and also decouple
the accessibility module a bit further from the toolkit
module without having to reorganize code further.
(VCLXFont from the toolkit module currently gets used in
various implementations.)
Change-Id: I06ea3cc5998a13927b3f869877b28f03ac07c89b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177809
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Pass arguments right away in ctor rather than
having a ctor that takes no arguments and then
having to call VCLXFont::Init with the arguments
right after calling the ctor.
Change-Id: I651e27154499f61638409377438f9589bc7412a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177795
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: I445ec8a08c6622c681e459efc2dd2afbf74dd78e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177794
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
...by providing a non-inline key function for that class. This would have
prevented the issue that has been addressed by
2fe53b2e436cb236b2dc121ceec4f22de49a13a8 "Fix crash due to unexpected
dynamic_cast failures in optimized build", where a dynamic_cast to VCLXPopupMenu
failed on macOS (which uses pointer equivalence to determine RTTI equivalence),
because VCLXPopupMenu is final, so the compiler, at least in optimized builds,
just used a comparison between the object's recorded RTTI (from dylib A) against
the type's RTTI in dylib B, which erroneously failed.
Change-Id: I68ff864c266bf28d19032527f91de592ca1437f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176188
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Following
Change-Id: Id48f81deb05aee2026509037f7d14575735e5be0
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 10 14:49:03 2024 +0200
VCLUnoHelper: Align AWT <-> VCL helpers with convert.hxx impl
, port all uses of the helper functions defined in
`include/toolkit/helper/convert.hxx` to use the
`VCLUnoHelper` equivalents instead, to unify usage
and avoid duplication.
Drop `include/toolkit/helper/convert.hxx` now that
it's unused.
Change-Id: I22695a93e40e47bb2b14d191a2e0a4eb7c856895
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170317
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
There are currently (at least) 2 sets of helpers
for converting from AWT to VCL point, rectangle
and size classes - and the other way around:
* the ones in `include/toolkit/helper/convert.hxx`
* the ones provided by `VCLUnoHelper`
Align the `VCLUnoHelper` implementations with the
ones in `include/toolkit/helper/convert.hxx` and
make them inline as well.
Switch params from the specific subclasses to the
more generic base classes as well
(e.g. `css::awt::Point` -> `PointTemplateBase`).
Otherwise, `VCLUnoHelper::ConvertToVCLRect` is the only one
that didn't implement the functionality in the
exact same way as the counterpart, `VCLRectangle`,
as it was manually calculating the right and bottom
edges.
The `VCLRectangle` implementation
gives the same result for valid rects, so take over
that one. (It shouldn't make a difference for the
only 2 current callers, `ControlHolder::getPosSize`
and `VCLXGraphics::clear`.)
This commit is in preparation of consolidating all uses
to use the `VCLUnoHelper` variants and getting
rid of the other one in following commits.
Change-Id: Id48f81deb05aee2026509037f7d14575735e5be0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170316
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
...where "Referer" is now passed in as an additional property, so that the
relevant objects can decide whether to obtain graphics while loading a document
Change-Id: Ie3dabc574861713212b906a0d7793f438a7d50a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168674
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
I had done these a while ago, when I looked into extending loplugin:ostr to do
more automatic rewriting, and these were places where I needed to do something
manually, for one reason or another, because the automatic rewriting would not
pick it up correctly.
However, I got distracted, and a wholesale automatic rewrite would still run
into cases where an _ostr/_ustr instance from a library's .rodata would still be
referenced after the library has already been dlcose'd. So I never came around
to finishing all that.
But there appears to be renewed interest in (automatic) rewritings here now, so
it probably makes sense if I share this part of my work anyway.
Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: I2e6c2dcd06c76e0f5f68a1debde3a20665104b27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164219
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
after I missed a bunch of stuff when testing UBSan with
commit 3ba92b5f1eaf7d4447a0943ea260db515ca799dc
hide more symbols
Change-Id: Id3cb0b70b9fa24c7e3fba7fd565eb658dafa00f8
Change-Id: I369587ed3e14e50ca272037b9d950b62841695d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163703
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
using the bin/find-can-be-private-symbols.py script
to find classes with large numbers of exported symbols
that can hidden.
before
exported = 58104
imported = 30810
unused_exports = 35433
after
exported = 55094
imported = 31073
unused_exports = 32423
Change-Id: Idd0a70ee3740afd5ca1a86771e0e2ff8090d102d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163456
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I005257e458351285b1b35ffe49c8b42834a6db68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156990
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Instead of the generic `VCLXAccessibleComponent`,
use `VCLXAccessibleEdit` as a11y class for
`VCLXMultiLineEdit` (the component interface
class for MultiLineEdit) as well, not just for `VCLXEdit`.
With the preparatory changes from
Change-Id I8218db61feb07605f6ea5309f26eebd38312458a
tdf#104833 a11y: Don't use VCLXEdit in VCLXAccessibleEdit
in place, it behaves as expected when interacting
with the multi line edit from the sample dialog in
attachment 189287 in tdf#104833 using Accerciser and
the qt6 or gtk3 VCL plugin (and the text can also be
edited when removing the readonly flag from the control)
or the update dialog (which uses UNO controls,
`UnoControlEditModel` for the panes that were not
announced, s. extensions/source/update/check/updatehdl.cxx ).
In particular, the a11y text interface is supported by
the multi line edit on the a11y layer, which makes
Orca with the gtk3 VCL plugin announce the text content
when the control gets focused.
NVDA on Windows still announces "Checking..." instead
of using the actual text that would be retrievable via
the IAccessibleText interface now. This is probably
because "Checking..." is the (outdated) accessible name,
as can be seen by interacting with the object in NVDA's
Python console:
>>> focus.name
'Checking...'
>>> txt = focus.IAccessibleTextObject
>>> txt.text(0, txt.nCharacters)
'LibreOfficeDev 24.2 is up to date.'
For both, gtk3 and qt6, the a11y object does have the
new text as a11y name as well, as can be verified in
Accerciser:
In [10]: acc.name
Out[10]: 'LibreOfficeDev 24.2 is up to date.'
In [11]: txt = acc.queryText()
In [12]: txt.getTextAtOffset(0,3)
Out[12]: ('LibreOfficeDev 24.2 is up to date.', 0, 34)
Change-Id: Id80e191cdd5342b3215fdb9d2ad3847470366337
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156402
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This is in preparation of having the a11y factory
create a proper accessible context for it.
Change-Id: If60efa84263c2d68eb57daa3aae4834a060529c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156401
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It is only used inside the module, no need to be public
Change-Id: Ibd8445ecbb67624569ee7225f0bdf6d9c041dab4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151569
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 19c18c94085f7a70e536a914ed978fc54b5625b9.
Because it breaks the MRI extension, I was wrong, it does not
do quite the same thing as its superclass method.
Change-Id: I65bfb4264615dea5f6d0f2fb7b989352e7e83ee1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150274
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which is faster than binary lookup
Change-Id: Ia810313af36c75fd9b5b241704f0cbd66afcb6b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150189
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I18ab490074051831dd31b3953308e372ca2b469f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149904
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Rather than using it's superclass XWindowPeer and implicitly relying on it being XVclWindowPeer and casting it everywhere.
Change-Id: Icfb46f3b920d00f4a167a31803a71bbb0368d05c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149894
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
they should deal in terms of the fast property IDS, they should not need
to override setPropertyValueImpl, so just remove this, and standardise
on the subclasses overriding setFastPropertyValueImpl
Change-Id: I190955ccc4ae3e07dd481a1044f3c074dd1a40aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149836
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which does exactly the same thing as the method it overrides
Change-Id: Ib227011795f0cf6336fb1e01c14636a9996bb164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149835
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Which means creating a variant of the cppuhelper::OPropertySetHelper
helper class which uses a std::mutex.
Since we can do virtual base classes now (which the original could not), use that and a new helper
class comphelper::UnoImplBase to share
std::mutex m_aMutex;
bool m_bDisposing;
fields that the OPropertySetHelper wants to share with the parent class.
Change-Id: I05ad465a3d3653ed4e109137e3e1c58190da8d97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148474
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
there are two very similar classes, standardise on the one in
include/comphelper
Change-Id: If85729dcea01e65a2d095bb211fe643c783ebf1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148442
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icd565c83ca3b4afb1a846a637b7943b0498487e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147457
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I300f033054bddc2c0ee1973dbafc108c477bf09a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146103
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iee992e2e09647a7678fd05321e601a4c5bf0c430
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145469
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0d8a65aa16583fcb6c8201589b2d356da0be5cac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145482
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4afa34805e64f3ff37b76fe8ca4676c1f4eb3e14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145468
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9fa06600d3b9a2172a1818f89a3b9c06d65c8c54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145467
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
> winaccessibility/source/service/AccTopWindowListener.cxx(47,36): error: suspicious dynamic cross cast from 'css::accessibility::XAccessible *' to 'VCLXAccessibleComponent *' [loplugin:crosscast]
> else if (auto pvclxcomponent = dynamic_cast<VCLXAccessibleComponent*>(pAccessible))
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Iee7585dd2fa0d92af3be6b89d7d08326de3d1e7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145380
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as there were no calls to its OAccessibleImplementationAccess::getUnoTunnelId
so no code apparently made use of that XUnoTunnel
Change-Id: I35d392999f1c28e81f7ff4bf395f63642eb17bce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145250
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after 21e0d8162a0e683558c4d042ce688fc9a6833809 "loplugin:unusedfields" had
dropped the base class
OAccessibleImplementationAccess::implGetForeignControlledParent
Change-Id: I753aad41baaa0ac1d1f7eb0a6084993df5a58d5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145197
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as obsoleted by ef533553559fe09b4afab651fc692885d1acf4ed "Rudimentary support
for dynamic_cast on UNO proxy objects".
This reverts all of:
4cfcc9ac37b90ce64c8402a41eb4638adb185b5c "loplugin:unocast (framework::Desktop)"
03efbf72f4ddf7a84aa8aabef348331bd4b75e8a "loplugin:unocast
(vclcanvas::TextLayout)"
80099fdd51a69eaa6c36ca88ef772810e4a777fa "loplugin:unocast (SalGtkXWindow)"
cc147f576d8687fb79c77d47d41dc4ba1678a469 "loplugin:unocast
(sdext::presenter::CachablePresenterView)"
40db42be1d8fd0f9c6c8c5ba3767ddb9ee2034c2 "loplugin:unocast
(vclcanvas::CanvasFont)"
2d1e7995eae29e2826449eb5179f5fae181794a5 "loplugin:unocast (CairoColorSpace)"
4c0bbe4bd97636207cf71a6aa120c67698891da9 "loplugin:unocast
(canvas::ParametricPolyPolygon)"
89803666621c07d1b1ac9d3bd883f0ca192a91a0 "loplugin:unocast
(vclcanas::CanvasBitmap)"
d5e0c2c8db71878d21c2a7255af08cf5f9a6dd04 "loplugin:unocast
(sfx2::DigitalSignatures)"
c0c4519e0d5b555f59bbc04cc616454edfd1f4ce "loplugin:unocast
(VCLXAccessibleComponent)"
feb8b833a6245d42400f42a0bc789dc84594ee6f "loplugin:unocast (VCLXDialog)"
1fa58cc6cc9c3849753342a5d9a6ddfa461b5e66 "loplugin:unocast (VCLXMultiPage)"
f481f036deb1b1b46f3038074c4659f3a91b9c6c "loplugin:unocast
(DocumentSettingsSerializer)"
73df933f5fa5932f94e5a1b338a3eda00a9ce354 "loplugin:unocast
(css::embed::EmbeddedUpdate)"
420165ab0ef03c0467f9d17f504de2d2fc78f0e6 "loplugin:unocast
(canvas::tools' StandardColorSpace, StandardNoAlphaColorSpace)"
9abe8ee067e6c00f19d8a13346d53c4641c27166 "loplugin:unocast (MutableTreeNode)"
9f3022ceb036f23b4b0994c3e2fbd1001bff225a "loplugin:unocast (VCLXTabPage)"
1be70dda02c12a60778b7607cff2520ae1aa611e "loplugin:unocast
(vcl::unotools::VclCanvasBitmap)"
d6a70bb641b96e8e5616448c2378131ed62658b4 "loplugin:unocast
(basegfx::unotools::UnoPolyPolygon)"
5a14f009e6782c077463c8cbb8e9cea3d7950107 "loplugin:unocast
(xmlsecurity::Certificate)"
99009c9535dfa3e0d838989ccc7d84bfa2320ff4 "loplugin:unocast (sd::Annotation)"
0c7585c5fa78887e5459885ed744e8044fd76137 "loplugin:unocast (sd::TextApiObject)"
24e14afd1bfcaed6c200ab081973fba7e47267ca "loplugin:unocast
(SignatureVerifierImpl)"
1a7ad0c10d286ce9ae2700ceb2fd50eed1fb43a4 "loplugin:unocast
(pcr::PropertyEventTranslation)"
a97e2d2702d9a6f37775ccee2c08c4f3b2479c4b "loplugin:unocast (RangePageBreaks)"
19dfdf86ad1f5b08041d8b7a9f196caf881231ab "iloplugin:unocast
(pcr::OFormattedNumericControl)"
f9785ea595fd8e911f6370e836fa579225b9e571 "loplugin:unocast
(frm::OInterfaceContainer)"
5e5f40a4a92a31b0932c690219d002fcf18598cf "loplugin:unocast (ScVbaShapes)"
27b35b2c215b4832d4378ec3a7ecbba926552d06 "loplugin:unocast (ScVbaShapeRange)"
cb3108f860065928552a86cf8acc4b3a95718ecf "cid#1517812 Dereference null return
value"
feba0ddb1521d1142560fe54b7d7696ee910237f "loplugin:unocast
(weld::TransportAsXWindow)"
4d6c23216559eb48f9943bb49d6e475a6d64ba15 "loplugin:unocast
(oox::ForumlaImExportBase)"
4844c096a8ab6a9a620c410a0949d4499f12a504 "loplugin:unocast
(cairocanvas::SurfaceProvider)"
9a0b523e0a84d403b9092176ccec4b3e3efe42d0 "loplugin:unocast
(cairocanvas::CanvasBitmap)"
8a5648d8e59b4b007dbbf3824777c19a21efc61e "loplugin:unocast
(cairocanvas::TextLayout)"
28c27a0623bc78a0590858f97d03b620985bc84c "loplugin:unocast
(cairocanvas::CanvasFont)"
53bc223cb3288e32a417696ee61c29e5f01f209d "loplugin:unocast
(cairocanvas::RepaintTarget)"
5f70b0b9f6bc4ab145ddbd9155590ed4a3b1b9ec "loplugin:unocast (SvXMLImport)"
068187a898cdd2e26e9b16c348ecc1ed2dee3f29 "loplugin:unocast (VCLXWindow)"
88b4f966202717cd4ad38a30a8eda22c3e69ed35 "loplugin:unocast
(sfx2::sidebar::SidebarController)"
f1b7a69b280aefe2f1b3b0f32193494fd765f2bd "loplugin:unocast
(SvxLineStyleToolBoxControl)"
ba76f0ba7e8de4d2953739c952004b7d9af47197 "loplugin:unocast
(i18npool::Calendar_gregorian)"
840154daf934d8df52ead1cb7acd798c4d30f007 "loplugin:unocast
(framework::AddonsToolBarWrapper)"
b0e9c4c5f063cefa9557810e3349bdb9c7493091 "loplugin:unocast
(GrammarCheckingIterator)"
8ee6cfc9655ce9de4617cea1a0d9cb9d7a4fbfac "loplugin:unocast
(ucb::ucp::ext::Content)"
5b8cd77c112bc8c0e92b8fec215c3c8e802bbc0a "loplugin:unocast
(basic::SfxScriptLibraryContainer)"
9e73ff9fce12e102bb3c3cea8d8bb96c88f2c9ad "loplugin:unocast
(sdext::presenter::PresenterNotesView)"
a98acca8fbc38d3fd5600ae5056a8e42b6d8a40d "loplugin:unocast
(SelectionChangeHandler)"
c0b59ad6e35b0cb0dea0821e95f95569739078c1 "Consistently use
comphelper::getSomethingImpl<I>(aIdentifier, this)"
276e3ccbdd3259ec3daf8a1a98fa7f406b14e21c "loplugin:unocast
(vclcanvas::RepaintTarget)"
Change-Id: I37c73e3422a5154bf6cb647640d2d3f23db8bc34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145063
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I11496cc1d37e89ce8f11991f86c7b60bb1b93106
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144748
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
to try and untangle the dependency mess a little.
This means
(*) tunneling a piece of information from VCLXWindow via
the XWindowPeer::getProperty method, so
we do not need to directly call VCLXWindow.
(*) moving some formpdf code from framework "down" to vcl,
where the drawinglayer code can use it
Change-Id: I2c1ff3e34941b3147e66cf0a2d0fdb13293e3aa2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144341
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia30e3b7f10ae11c7a74e6860ac0a6115caaa439f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143529
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I102b49608b62b351d6a458b3fd56167b136b24e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143525
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I5dcba14a9b0dfcc5267760410f6d135fcd3b1bd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142944
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The highlight and highlighttext colors can be set for some
controls. So as example a selected item in a listbox can now
be paint with anothers colors then the standard blue. Controls
are: listbox, combobox, edit field and some special edit
fields like date, currency and others.
Change-Id: Iace2dd9a1a61abb7819b6c81eb0b8030912db32b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136691
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
With 16k column support in Calc enabled by default in
commit 4c5f8ccf0a2320432b8fe91add1dcadf54d9fd58
Date: Tue Mar 8 12:44:49 2022 +0100
change default Calc number of columns to 16384 (tdf#50916)
, the number of Calc cells in a spreadsheet is larger than
SAL_MAX_INT32, meaning that a 32-bit a11y child index is no more
enough and using it resulted in integer overflows in
methods handling corresponding Calc cells in the a11y layer.
This e.g. had the effect of the Orca and NVDA screen readers
not announcing focused or selected cells properly when their
a11y child index was out of the 32-bit integer range.
Switch the internal a11y child indices to 64 bit to
be able to handle this properly internally.
Since the platform APIs (at least AT-SPI on Linux and
IAccessible2 on Windows; from what I can see LO's macOS
a11y bridge doesn't directly expose the child index)
are still restricted to 32 bit, larger child indices
still cannot be exposed via the platform APIs.
As a consequence, use of the the IAccessible2 and
AT-SPI methods that use the child index remains
problematic in those cases where the child index
is larger. However, as an alternative to using the
AT-SPI Table interface and the IAccessibleTable/
IAccessibleTable2 interfaces with the child index
to retrieve information about a specific cell,
both AT-SPI and IAccessible2 also provide interfaces
to retrieve that information directly
from the cell object (TableCell interface for AT-SPI,
IAccessibleTableCell for IAccessible2).
Those interfaces are already implemented/exposed
for winaccessibility (s. `CAccTable`) and the
qt5/qt6/kf5 VCL plugins (s. the `QAccessibleTableCellInterface`
methods implemented in `QtAccessibleInterface`).
With the switch to 64-bit internal a11y child indices,
these now behave correctly for cells with a child
index that doesn't fit into 32 bit as well.
NVDA on Windows already uses the IAccessibleTableCell
interface and thus announcing focused cells works fine
with this change in place.
Orca on Linux currently doesn't make use of the AT-SPI
TableCell interface yet, but with a suggested change to
do so [1], announcement of selected cells works
with the qt6 VCL plugin with a current qtbase dev branch
as well - when combined with the suggested changes
to implement support for the AT-SPI TableCell interface
in Qt [2] [3] and the LO change based on that [4] and
a fix for a nullptr dereference [5].
The gtk3 VCL plugin doesn't expose the AT-SPI
TableCell interface yet, but once it does so
(via `AtkTableCell`), it also works with the
suggested Orca change [1] in place.
(Adding that is planned for an upcoming change,
works with a local WIP patch.)
For handling return values that are larger than what
platform APIs support, the following approach has
been chosen for now:
1) When the return value is for the count of
(selected) children, the maximum value N
supported by the platform API is returned.
(This is what `ScAccessibleTableBase::getAccessibleChildCount`
did previously.)
The first N elements can be accessed by their
actual (selection) indices.
2) When the return value is the child/cell index,
-2 is returned for objects whose index is greater
than the maximum value supported by the platform
API.
Using a non-negative value would mean that the
index would refer to *another* actually existing
child. A child index of -1 on the other hand
tends to be interpreted as "child is invalid" or
"object isn't actually a child of its (previous)
parent any more)". For the Orca case, this would
result in objects with a child index of -1
not being announced, as they are considered
"zombies" [6].
What's still somewhat problematic is the case where
more than 2^31 children are *selected*, since access
to those children still happens by the index into
the selection in the platform APIs, and not all
selected items are accessible this way.
(Screen readers usually just retrieve
the first and last element from the selection and
announce those.)
Orca already seems to apply different handling for the
case for fully selected rows and columns, so
"All cells selected" or "Columns ... to ... selected"
is announced just fine even if more than 2^31
cells are selected.
(Side note: While Microsoft User Interface
Automation - UIA - also uses 32-bit indices, it also
has specific methods in the ISelectionProvider2
interface that allow to explicitly retrieve the
first and last selected item,
`ISelectionProvider2::get_FirstSelectedItem` and
`ISelectionProvider2::get_LastSelectedItem`, but
we currently don't support UIA on Windows.)
Bound checks at the beginning of the methods from the
`XAccessibleContext`, `XAccessibleSelection` and
`XAccessibleTable` interfaces that take a child index
(or in helper methods called by those) should generally
already prevent too large indices from being passed to
the methods in the lower layer code that take smaller
integer types. Such bound checking has been
been added in various places where it wasn't present yet.
If there any remaining issues of this
kind that show after this commit, they can probably be
solved in a similar way (s.e.g. the change to
`AccessibleBrowseBox::getAccessibleChild` in this
commit).
A few asserts were also added at
places where my understanding is that values shouldn't
be larger than what is supported by a called method
anyway.
A test case will be added in a following change.
[1] https://gitlab.gnome.org/GNOME/orca/-/merge_requests/131
[2] https://codereview.qt-project.org/c/qt/qtbase/+/428566
[3] https://codereview.qt-project.org/c/qt/qtbase/+/428567
[4] https://gerrit.libreoffice.org/c/core/+/138750
[5] https://codereview.qt-project.org/c/qt/qtbase/+/430157
[6] https://gitlab.gnome.org/GNOME/orca/-/blob/82c8542002e36e0d3d918088d583162d25136143/src/orca/script_utilities.py#L5155
Change-Id: I3af590c988b0e6754fc72545918412f39e8fea07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139258
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|