By now, almost all a11y implementations implement both,
the XAccessible and XAccessibleContext interfaces themselves,
and they do so via the OAccessible base class.
One remaining case that only implements the XAccessible interface
directly is UnoControl. XAccessible::getAccessibleContext
is used from within AccessibleControlShape::Init to get the
accessible context. That accessible context however
is an OAccessible and implements both, the XAccessible
and XAccessibleContext interfaces again.
Stop requiring that UnoControl implements XAccessible
by instead adding a dedicated new method UnoControl::getAccessible
to directly get the OAccessible without relying on
the XAccessible interface being implemented by UnoControl.
In AccessibleControlShape::Init, cast to UnoControl
instead of querying for the XAccessible interface
and call the new method directly.
Stop implementing the XAccessible interface in
UnoControl as it is no longer needed now.
This aligns the UnoControl a11y logic more with how
a11y is implemented elsewhere across the code base.
Sample steps to trigger the modified code
when using the gtk3 vcl plugin on Linux:
* start the Orca screen reader
* start Writer
* insert a few push button controls using
"Form" -> "Push Button" and then clicking into
the document and dragging to insert
* disable design mode using "Form" -> "Design Mode"
* focus one of the controls by clicking on it
* press the Tab key to move focus between the controls
No differences in behavior were observed when
doing this with or without this change in place.
Side note: Announcement of the controls when they
receive focus didn't work (reliably) when opening an
existing document containing form controls instead of
inserting them into a new one, but that is preexisting
and unrelated to this commit.
Also adjust test AccessibleFixedTextTest::testFixedText
of the CppunitTest_toolkit_a11y test suite
accordingly that was assuming that it can
query the XAccessible interface directly
from the UNO control.
Change-Id: I8cc3902a8de725eda3d810920f1da2d390c06f73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210464
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Pass the more concrete OAccessible instead of a reference
to the abstract XComponent UNO interface.
Change-Id: Idcbf5c1eb09cc1380a85410b76d8b1e2df022b6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210460
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from using a weak reference (css::uno::WeakReferenceHelper)
to the abstract XAccessibleContext UNO interface to a weak
reference (unotools::WeakReference) of the more concrete
OAccessible class in UnoControl.
This makes clear that the accessible is always an OAccessible
subclass and allows dropping some UNO-querying for the
wanted UNO interfaces.
Change-Id: Ib1ea66c83da9bbf76891c492d84aa57c396f2f44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210459
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The UNO service specific to the status bar was
dropped in
Change-Id: I0d1cb8353fac37a3db9833a06fa439cc94e6c9b3
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 1 16:01:28 2026 +0200
[API CHANGE] a11y: Drop com.sun.star.awt.AccessibleStatusBar
and more UNO service descriptions will be dropped as they
are an implementation detail and not relevant to implement a11y
support.
Don't rely on XServiceInfo being implemented in
the AccessibleStatusBarTest, to prepare for the upcoming
removal of those services.
Change-Id: Ib545820a52bcb4d4f99239e438840b1562831c2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210405
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The com.sun.star.accessibility.AccessibleContext UNO service
is unnecessary and not really used for implementing a11y support,
apart from some a11y implementations declaring support for it.
What is relevant is the com.sun.star.accessibility.XAccessibleContext
interface instead.
Stop declaring support for the com.sun.star.accessibility.AccessibleContext
service in AccessibleGridControlBase (and drop related
XServiceInfo::getImplementationName overrides in subclasses),
in preparation of dropping the service altogether in an upcoming
commit.
Change-Id: I66e6390ad77e3ff0febfb335c312954815c6581c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210400
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That Java a11y test has been disabled since
commit d595547fa6
Author: Vladimir Glazounov <vg@openoffice.org>
Date: Tue Oct 23 08:38:02 2007 +0000
INTEGRATION: CWS unoapi1 (1.2.440); FILE MERGED
2007/10/15 15:04:34 cn 1.2.440.3: #i79479# update Lists
2007/10/15 09:27:54 cn 1.2.440.2: #i79479# update Lists
2007/08/24 15:17:25 cn 1.2.440.1: #i79479# updateLists
. As the comment in qadevOOo/tests/java/mod/_toolkit/AccessibleListBox.java
says, it would try to run the hyperlink dialog and then
find various widgets using the a11y API. However, assumptions
that the test has do not match what widgets and corresponding
a11y implementations would be relevant for that dialog
today.
The test can be seen failing by enabling it locally
like this
--- a/toolkit/qa/unoapi/toolkit_1.sce
+++ b/toolkit/qa/unoapi/toolkit_1.sce
@@ -21,7 +21,7 @@
#i86008 -o toolkit.AccessibleComboBox
-o toolkit.AccessibleDropDownComboBox
#i86110 -o toolkit.AccessibleEdit
-#i86110 -o toolkit.AccessibleList
+-o toolkit.AccessibleList
#i86110 -o toolkit.AccessibleListItem
-o toolkit.AccessibleMenu
-o toolkit.AccessibleMenuBar
and then running `make JunitTest_toolkit_unoapi_1`.
Just drop the test altogether.
If there should be a relevant test again in the future,
writing a new (C++, see [1]) one from scratch seems more
promising than having to deal with this outdated and disabled
test.
Dropping it also prepares for more upcoming vcl a11y changes
that would break even more assumptions that the test makes.
This commit is similar to the previous
Change-Id: Idbd01f92c78cd78005b306114c53f9946fa4d35f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 1 16:28:30 2026 +0200
a11y tests: Drop obsolete, long disabled AccessibleListBox Java test
, but now for the AccessibleList test.
[1] https://wiki.documentfoundation.org/Development/Accessibility_Unit_Tests
Change-Id: I1e0469f8f265d564cdcaf81aa1bdc8e718e49a26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210349
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That Java a11y test has been disabled since
commit d595547fa6
Author: Vladimir Glazounov <vg@openoffice.org>
Date: Tue Oct 23 08:38:02 2007 +0000
INTEGRATION: CWS unoapi1 (1.2.440); FILE MERGED
2007/10/15 15:04:34 cn 1.2.440.3: #i79479# update Lists
2007/10/15 09:27:54 cn 1.2.440.2: #i79479# update Lists
2007/08/24 15:17:25 cn 1.2.440.1: #i79479# updateLists
. As the comment in qadevOOo/tests/java/mod/_toolkit/AccessibleListBox.java
says, it would try to run the hyperlink dialog and then
find various widgets using the a11y API. However, assumptions
that the test has do not match what widgets and corresponding
a11y implementations would be relevant for that dialog
today.
The test can be seen failing by enabling it locally
like this
--- a/toolkit/qa/unoapi/toolkit_1.sce
+++ b/toolkit/qa/unoapi/toolkit_1.sce
@@ -22,7 +22,7 @@
-o toolkit.AccessibleDropDownComboBox
#i86110 -o toolkit.AccessibleEdit
#i86110 -o toolkit.AccessibleList
-#i86110 -o toolkit.AccessibleListBox
+-o toolkit.AccessibleListBox
#i86110 -o toolkit.AccessibleListItem
-o toolkit.AccessibleMenu
-o toolkit.AccessibleMenuBar
and then running `make JunitTest_toolkit_unoapi_1`.
Just drop the test altogether.
If there should be a relevant test again in the future,
writing a new (C++, see [1]) one from scratch seems more
promising than having to deal with this outdated and disabled
test.
Dropping it also prepares for more upcoming vcl a11y changes
that would break even more assumptions that the test makes.
[1] https://wiki.documentfoundation.org/Development/Accessibility_Unit_Tests
Change-Id: Idbd01f92c78cd78005b306114c53f9946fa4d35f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210348
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Together with the expanded state, SvLBoxContextBmp::m_bExpanded
is used in SvLBoxContextBmp::Paint to decide which image
(SvLBoxContextBmp::m_aImage1 or SvLBoxContextBmp::m_aImage2)
to draw.
There are 2 actual scenarios used for that member:
1) The member is set to true, with (potentially) different images
set. (Used in ImplContextGraphicItem.)
2) The member is set to false, with the same image
set for both images. (Used in SalInstanceTreeView
and SalInstanceIconView).
For 2), it doesn't matter which of the two images is used,
as they are the same anyway.
For 1), the
const Image& rImage = pView->IsExpanded() != m_bExpanded ? m_aImage1 : m_aImage2;
can be simplified to just
const Image& rImage = !pView->IsExpanded() ? m_aImage1 : m_aImage2;
to make more obvious that SvLBoxContextBmp::m_aImage1 is
used for the case where the entry is not expanded and
SvLBoxContextBmp::m_aImage2 is used when the entry is expanded.
Drop SvLBoxContextBmp::m_bExpanded to simplify this accordingly.
Change-Id: I94b06ef87f002a1f35591021225d1858631afb44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206969
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use SvTreeListBox::Insert directly, which is perfectly fine
with a null parent param (at least) with previous changes
up to
Change-Id: I07e12a6f3b3e9c96df79129e19f9331a64588830
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 17 10:25:17 2026 +0200
vcl: Consolidate to one SvTreeListBox::Insert
in place.
Change-Id: I6c4a68a23b36df66635ef8836ffc45c7a751ef29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206791
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Change the order of the 2nd and 3rd parameter
of SvTreeList::Insert and SvTreeListBox::Insert.
This prepares for providing a default value of
nullptr for the third parameter in
SvTreeListBox::Insert and dropping the
SvTreeListBox::Insert variant that only takes
2 params.
Change-Id: Ibea425c37a856cbece484fc2f7fbcd12b42ea235
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206788
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That one already gets the model to call
SvTreeList::InvalidateEntry, so no need to
do that manually in more places.
Change-Id: I52c8b883353b8eec19c642ff7a00ddb3fbd01802
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206748
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the existing SvTreeListBox method that removes
the entry from the model instead of manually
removing from the model directly.
This requires to pass a non-const SvTreeListBox
to TreeControlPeer::updateChildNodes.
Change-Id: Idefc7f25a5d22bcba765541c73101e888d42e225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206741
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This makes clear that this is always non-null.
The method implementation unconditionally dereferences
the argument.
Change-Id: I5c0e2576b3abf4347cd18349b79656ab73bae5d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206723
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Just hard-code passing true to the base class ctor as the
ImplContextGraphicItem ctor is always called with a value
of true.
Change-Id: I5437e049daf570d693445a7431ed61f17b6dfffa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206397
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
At least for one of my builds, JunitTest_toolkit_unoapi_2's toolkit.Toolkit
fails its XDataTransferProviderAccess check at getDragSource(), which returns
null:
> [toolkit.Toolkit::com::sun::star::awt::XDataTransferProviderAccess::getDragSource()] is testcode: [getDragSource()] - COMPLETED.FAILED
getDragSource has no XDragSource to return without a drag-and-drop capable VCL
backend: when the unoapi soffice runs the svp plugin without --headless,
SalInstance::CreateDragSource skips its GenericDragSource stub (gated on
headless/unittest/uitest) and the svp backend's ImplCreateDragSource returns
null. (The corresponding getDropTarget only passes because
Window::GetDropTarget always returns a non-null DNDListenerContainer wrapper.)
Signed-off-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Change-Id: I2c76b27e22e99612d8030598f338a78ca7c55ec3
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4187
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit c35ff1648f319723710a9143fbeb9ecf1a7fec70)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206645
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Return early if mpTreeImpl is null, which allows
to get rid of one nesting level further down.
Change-Id: I75fa1d7838bb83fe1340935f2f3db09f86a45253
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206311
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Expose font variation axis info to scripting and extensions via a new
com.sun.star.awt.FontVariations service. From Basic:
oInfo = createUnoService("com.sun.star.awt.FontVariations")
aAxes = oInfo.getFontVariationAxes("Reem Kufi")
The intent is to allow extensions to build a UI for setting font
variations, by querying the axes for an arbitrary font family and then
setting CharFontVariations property.
Change-Id: I4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205070
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
`Nodes` is created with the default Sequence ctor, i.e.
as an empty Sequence. Since no element is inserted afterwards,
it is still empty and has no element, so there is no point
in checking whether it has any.
Drop the corresponding logic altogether.
Change-Id: I3c5e83c950d383251f713fd6ddb20554e7ad2a97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204923
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
All 4 callers check whether TreeControlPeer::mnEditLock
is non-zero and return early in that case. Deduplicate
that by moving the check into TreeControlPeer::updateTree
itself.
Change-Id: I650e2a9e2d256a609290e288ba850f490d071929
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204922
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The methods overriden here are from the
css::awt::tree::XTreeDataModelListener UNO interface.
Clarify the comment in the header, and drop the
duplicate comment in the source file.
Change-Id: I0481202df14601935601f69b38099f58db5d80d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204920
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, the callback called when a SvTreeListBox
entry was edited contained the SvTreeListEntry
and the new text of the entry.
Pass also the entry's item (SvLBoxItem) in addition,
so the handler can take that into account.
This will be used in an upcoming commit to extend
weld::TreeView::signal_editing_done to also pass
the index of the edited column.
Change-Id: Iad2866d8fcc710d82f4f0dc0661a3b1f0bebaeab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204303
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch SvTreeListBox::EditedEntry to take a reference instead
of pointer param and also use a reference in IterString.
Change-Id: I9597ff94978c4f25440d1b41b8c99985928258e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204295
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Similar to previous commit
Change-Id: Id39e551d54f4dc20ab7d7e33d52ed5cea308e1ce
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Apr 24 12:12:01 2026 +0200
vcl: Return ref in SvTreeListBox::GetViewDataItem
, also switch the non-const variant to return a reference
instead of a pointer.
Change-Id: I31bef6a251c873c220171e17db1dfd4a82ddadbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204292
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of by pointer.
This also allows to drop one superfluous null check
in SvLBoxButton::InitViewData.
Change-Id: Iefbfc4c701effefbc618f2eaa0b101edbd6ee176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202346
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Andrea Gelmini