Following
Change-Id: I54e578098684a027c9bf2f192a5af3fecb4e65d7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:44:17 2026 +0200
toolkit: Rename TableControl_Impl to TableControl
, also rename the header and source file to match
with the new class name.
(See that commit's commit message for more background.)
Change-Id: I5d7c4251902689718b9b2f3217671cad5b071201
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211163
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As mentioned in previous commit
Change-Id: I82c89866e90f4d29964626d483872e0eafbc4dbe
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:30:10 2026 +0200
toolkit: Merge TableControl into TableControl_Impl
, rename TableControl_Impl to simply TableControl,
now that the two classes were merged.
The header and source
file will also be renamed accordingly.
Do it as a separate step to keep the diff of the
single commits clearer.
Change-Id: I54e578098684a027c9bf2f192a5af3fecb4e65d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211162
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, most of the logic for the TableControl
widget was implemented in the TableControl_Impl
implementation class that was held by the
TableControl via a std::shared_ptr
(TableControl::m_pImpl member).
However, other classes were also using the
TableControl_Impl directly.
Stop that separation and simplify code by merging
TableControl into TableControl_Impl. As mentioned,
the latter already implemented most of the logic,
so it is easier to merge the remaining logic into
that class than the other way around.
Move the remaining TableControl logic into
TableControl_Impl, in particular make TableControl_Impl
a Control subclass and move the vcl::Window/Control
overrides to TableControl_Impl.
Now that TableControl_Impl is a vcl::Window subclass,
VclPtr is the appropriate way for handling shared
ownership and no longer std::shared_ptr.
Therefore, switch to using VclPtr instead of shared_ptr
in the corresponding ITableModel methods
(ITableModel::addTableModelListener and
ITableModel::removeTableModelListener) and corresponding
data structures used in the subclasses.
See also commit message of previous commit
Change-Id: I74b9b29f03d03571709d1c8a7b416b0a6a12319a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 11:07:29 2026 +0200
toolkit: Use TableControl_Impl directly instead of ITableModelListener
that was already preparing for that change.
No change in behavior intended.
Now that there is no more TableControl that owns it,
it makes sense to rename TableControl_Impl to TableControl.
That will happen in a separate upcoming commit, to keep
the diff clearer/more manageable.
Change-Id: I82c89866e90f4d29964626d483872e0eafbc4dbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211161
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from pointer to reference, which makes clear that
it's always non-null. Rename accordingly.
Change-Id: If8a3597d1fb42f7714bbdafd1dde2826d6f46824
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211160
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In most of its methods, TableControl simply calls a corresponding
method in TableControl_Impl. Most of them have the same name
in both classes, but start with an upper case letter in TableControl
and a lower case letter in TableControl_Impl.
Align the names to match, mostly by switching the TableControl_Impl
variants to also start with an upper case letter, and renaming a few
others that had different names.
This is in preparation of merging TableControl into TableControl_Impl,
so that the callers of the methods don't need to be adjusted to
use the (so far) differing method names.
Change-Id: Ie554a6f889f8993b37e494d2e66f3e4d88d503eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211158
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Those are partially used in TableControl_Impl and elsewhere.
On the other hand, TableControl uses sal_Int32 directly,
i.e. the TableControl methods using sal_Int32 call the
TableControl_Impl equivalents using the typedefs.
Unify this to consistently use sal_Int32 directly.
This will also make merging TableControl and
TableControl_Impl more straightforward, which
is planned for an upcoming commit.
Change-Id: I96c83bcd69ad84012194865f19ad0fc507f11e1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211157
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
TableControl_Impl is the only class implementing/subclassing the
ITableModelListener interface/base class.
Switch to using TableControl_Impl directly instead of the
abstract base class. This also requires that TableControl_Impl
now needs to subclass std::enable_shared_from_this instead
of ITableModelListener doing so.
This commmit prepares for merging TableControl and TableControl_Impl
in an upcoming commit, at which point the std::shared_ptr will
be replaced by a VclPtr as TableControl is a vcl::Window subclass.
Change-Id: I74b9b29f03d03571709d1c8a7b416b0a6a12319a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211156
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
This commit is part of a series to implement that approach
for more methods by moving the logic to TableControl_Impl,
to make the handling more consistent and prepare for merging
TableControl and TableControl_Impl in an upcoming commit.
Change-Id: I19e2c30d9b6c09a1621fd9097ab394e80c9821b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211155
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
This commit is part of a series to implement that approach
for more methods by moving the logic to TableControl_Impl,
to make the handling more consistent and prepare for merging
TableControl and TableControl_Impl in an upcoming commit.
Change-Id: I9540a25c008d003b24c52309255b9009e01d09eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211154
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
This commit is part of a series to implement that approach
for more methods by moving the logic to TableControl_Impl,
to make the handling more consistent and prepare for merging
TableControl and TableControl_Impl in an upcoming commit.
Change-Id: Ibf26eebf0506d6cfc5448064075eae9412ff1fc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211153
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
Implement that approach for more methods by moving the
logic to TableControl_Impl, to make the handling more
consistent and prepare for merging TableControl and
TableControl_Impl in an upcoming commit.
Change-Id: Ic551ed5e3a0298744602dd0c0abbaa9e1662fc9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211152
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
It does the same as TableControl::GoToCell, so replace the
only call to the former with a call to the latter.
Change-Id: I85905afb0e56a4b00686723a7e80a12f1519bdd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211151
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
Implement that approach for more methods by moving the
logic to TableControl_Impl, to make the handling more
consistent and prepare for merging TableControl and
TableControl_Impl in an upcoming commit.
Change-Id: If2b911371aad21a28f396d473f9e0dd7e5b33fde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211094
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
SVTXGridControl::m_xTableModel is a
std::shared_ptr<svt::table::UnoControlTableModel> and
svt::table::UnoControlTableModel is a ITableModel subclass,
so can be passed as is, without the need to explicitly
construct a std::shared_ptr<ITableModel>.
Change-Id: Ifecbc38634ff747d3b28077338114d6437e6ebc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211093
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the TableFunctionSet class definition and implementation out of the
header/source used for TableControl_Impl to an own/separate one.
This is in preparation of merging TableControl_Impl with
TableControl in an upcoming commit.
Change-Id: I9a0f9cd37db5763e8cd9deea727f2fe036b9375f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211091
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch members/params from the abstract ITableControl to the
concrete TableControl_Impl that is the only actual implementation/
subclass of ITableControl.
This is in preparation of Dropping ITableControl completely in
an upcoming commit.
Change-Id: I1b3bcb87f771f64dd7bf07f1047279524de432fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211084
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Make the header a bit more widely available inside the
toolkit module.
This is in preparation of merging TableControl_Impl with
its abstract ITableControl base class/interface and
merging TableControl with TableControl_Impl in upcoming
commits.
Change-Id: Id38183ac369f9d90571904816b1f3fbce1e12fa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211083
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This in particular also gets rid of an extra level of indentation
in toolkit/source/controls/table/mousefunction.cxx.
Change-Id: I1e5f8db7b281fb1d68d7819c5d99efae13c0cea4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211081
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from the abstract XAccessible UNO interface to the
more concrete OAccessible for AccessibleGridControlBase::m_xParent
and rename accordingly.
Drop now no longer needed method calls and UNO queries
to get the XAccessibleContext and XAccessibleComponent interfaces,
because OAccessible directly implements those interfaces
itself as well.
Change-Id: I39e8453f087568c78c2f7de6634d87bde2717956
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210633
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent is always an OAccessible subclass.
Pass that more concrete type for the parent param instead
of the abstract XAccessible UNO interface.
Change-Id: I4880448db03dcc89076dc72d45902c0bf2f16d83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210632
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent is always an OAccessible subclass.
Pass that more concrete type for the parent param instead
of the abstract XAccessible UNO interface.
Change-Id: Id2c3cb8c9095f338c5c1072bf86486bbf9260a79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210631
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Pass a more concrete OAccessible instead of the abstract
XAccessible UNO interface for the parent param.
Change-Id: I0a363d3174b304f019f7005cc5d7f219d0e150b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210630
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the local variable from the abstract XAccessible UNO
interface to the more concrete OAccessible base class.
This also prepares for more upcoming changes.
Change-Id: I8f33c4bea80052ebfc0d2ec21889f865e0cc5d6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210627
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The parent is always an OAccessible subclass.
Pass that more concrete type for the parent param instead
of the abstract XAccessible UNO interface.
Change-Id: If072062b295195b9599ad20af72d4fbf3eb6fc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210626
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent of a AccessibleGridControlTableCell is always the
AccessibleGridControlTable it belongs to.
Pass that concrete type to the ctor instead of the abstract
XAccessible UNO interface.
Change-Id: I3ff1c0f9f1a9bd81d07b8ff825b11d763c3863cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210625
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent of a AccessibleGridControlHeaderCell is always the
AccessibleGridControlHeader it belongs to.
Pass that concrete type to the ctor instead of the abstract
XAccessible UNO interface.
Change-Id: I17069674b5bd853e07b6b1551f291994f21c7eb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210624
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The parent is always an OAccessible subclass, so use that
more concrete type for the parent param of the ctor
instead of the abstract XAccessible UNO interface.
Change-Id: I938d73cef38385a562b516758bdbb7bb8d7dc5bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210623
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent is always an OAccessible subclass, so use that
more concrete type for the parent param of the ctor
instead of the abstract XAccessible UNO interface.
Change-Id: Icaeca70a28b87c2b2f9e5b07581777f0dd4cec3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210622
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The parent is always an OAccessible subclass, so use that
more concrete type for the parent param of the
AccessibleGridControlHeader ctor instead of the
abstract XAccessible UNO interface.
Change-Id: Ib0575f725f553b8345bd3f02085fa073a500cd92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210621
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
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 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>
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>
Michael Weghorn