The member is initialized to false in the ctor
and that value is never changed afterwards.
Drop it altogether and simplify code accordingly.
Change-Id: I0213e9f74b353a214af3ad163a934bfa7e868412
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211913
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
TableDesignWidget::m_bModal has a default value of false,
so there is no need to explicitly call TableDesignWidget::setModal
with the same value.
An upcoming commit will drop TableDesignWidget::m_bModal
altogether.
Change-Id: Iedfcc446b1c6f8d77d82d0478ff447590648765a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211912
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Now after
Change-Id: I3593630b4758d0547264c0ed63fec7ac111ccfd7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Oct 6 17:30:24 2026 +0200
svtools: Drop ValueSetItemType::ImageAndText and related logic
, the `rRendercontext` param for ValueSet::ImplFormatItem
is unused, so drop it, and also the then unused
corresponding ValueSet::Format param.
Change-Id: Ibc8afabf147974da1ed67ef903abc13c054c4c12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211911
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Prio to
Change-Id: I0d2f691eecfac013bc8ad3e506484d958d18ce0a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Oct 6 17:22:54 2026 +0200
svtools: Drop always false ValueSet::InsertItem bLegend param
, the only place where the type would have been set was
in ValueSet::InsertItem, but the method was never called
in a way that caused that code path being used.
Now that that was dropped from ValueSet::InsertItem,
also drop the remaining logic from the ValueSet
implementation.
This also means that the `rRenderContext` param for
ValueSet::ImplFormatItem becomes unused. Dropping
it and related cleanup will be done in an upcoming
commit.
Change-Id: I3593630b4758d0547264c0ed63fec7ac111ccfd7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211910
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
No single caller passes any explicit value for that
param, so the default of `false` is always used.
Drop the param and simplify the implementation a bit.
This will also allow for further cleanup in an upcoming
commit.
Change-Id: I0d2f691eecfac013bc8ad3e506484d958d18ce0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211909
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Port the toolbar popup to select the slide layout to use
from using two ValueSet widgets to using weld::IconView
instead.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom widget logic.
Adjust indices used to account for the fact that
weld::IconView indices are 0-based while the ValueSet ones
are 1-based. For the particular case here, custom non-continguous
item IDs were used for the ValueSet items that
correspond to the AutoLayout enum values.
Store those custom IDs as the IDs of the weld::IconView items and
retrieve the ID again in LayoutToolbarMenu::IconViewItemActivatedHdl.
The popup can be triggered like this:
* start Impress
* in the toolbar, click on the "Slide Layout" button
Change-Id: Ib4bf1c611663e8001a6ffcff6bc5ecf393c22277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211908
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Port the widget to select the extrusion direction from using
a ValueSet widget to using weld::IconView.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom widget logic.
Adjust indices used to account for the fact that
weld::IconView indices are 0-based while the ValueSet ones
are 1-based.
The popup can be triggered like this:
* open attachment 175894 from tdf#145296
* make sure the "3D-Settings" toolbar is enabled
in "View" -> "Toolbars" -> "3D-Settings"
* select the extruded shape
* press the "Direction" button in the "3D-Settings"
toolbar
Change-Id: I045bd1d605b0f5bb5c4ad7eeb3247e50356b39b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211907
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The popup can be triggered like this:
* open attachment 175894 from tdf#145296
* make sure the "3D-Settings" toolbar is enabled
in "View" -> "Toolbars" -> "3D-Settings"
* select the extruded shape
* press the "Direction" button in the "3D-Settings"
toolbar
Change-Id: If9c59a5d2e1d5232a909a4ad8a9e9e6086149ec5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211906
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
No need to store the images in a class member as they're
only used once in the ctor when inserting items into
the ValueSet. Just use a local variable and create the
images in the existing loop that inserts the items.
Change-Id: Ifa6722a88f97aac35e1b3c17ee9db7606c1ef001
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211905
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The last caller of that method was ported from ValueSet
to weld::IconView in previous commit
Change-Id: I28d86251b70149574535dc7b583660dbe42e9a0d
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Oct 6 15:01:52 2026 +0200
svx: Port ExtrusionLightingWindow from ValueSet to weld::IconView
Change-Id: I232f3767268a4fde206515f2a6d92e35c664ccd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211904
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Port the widget to select the lighting from using
a ValueSet widget to using weld::IconView.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom widget logic.
Adjust indices used to account for the fact that
weld::IconView indices are 0-based while the ValueSet ones
are 1-based.
The popup can be triggered like this:
* open attachment 175894 from tdf#145296
* make sure the "3D-Settings" toolbar is enabled
in "View" -> "Toolbars" -> "3D-Settings"
* select the extruded shape
* press the "Lighting" button in the "3D-Settings"
toolbar
Change-Id: I28d86251b70149574535dc7b583660dbe42e9a0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211903
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The popup can be triggered like this:
* open attachment 175894 from tdf#145296
* make sure the "3D-Settings" toolbar is enabled
in "View" -> "Toolbars" -> "3D-Settings"
* select the extruded shape
* press the "Lighting" button in the "3D-Settings"
toolbar
Change-Id: I195d1d7973b12541c7296433324b67a19dcd8021
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211902
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This means that native Qt widgets are used for this dialog
now when using the qt5 or qt6 VCL plugin and starting LO with
environment variable SAL_VCL_QT_USE_WELDED_WIDGETS=1 set.
The dialog can be triggered like this:
* open attachment 175894 from tdf#145296
* make sure the "3D-Settings" toolbar is enabled
in "View" -> "Toolbars" -> "3D-Settings"
* select the extruded shape
* press the "Depth" button in the "3D-Settings"
toolbar and select "Custom"
Change-Id: I4f1e43e20bac5525d3c24fdaa85c83f978460b0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211901
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The dialog can be triggered like this:
* open attachment 175894 from tdf#145296
* make sure the "3D-Settings" toolbar is enabled
in "View" -> "Toolbars" -> "3D-Settings"
* select the extruded shape
* press the "Depth" button in the "3D-Settings"
toolbar and select "Custom"
Change-Id: Ia7da2d663569f733451a692a0a6201cc19b5fe9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211900
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
After
Change-Id: I0150e699602a625874e5a09b8df38110f52c0c03
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Oct 6 12:15:49 2026 +0200
svtools: Drop now unused WB_NAMEFIELD logic from ValueSet
, that member is only written to, but never read, so drop
it completely.
Change-Id: I974183e725e3c530162152debd29bbf207b21b6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211899
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The last case where that style flag was set was ported
away from ValueSet to use weld::IconView instead in earlier
commit
Change-Id: I1c23a305322105608d0152bcd0b0fa195be14eff
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Oct 6 11:48:21 2026 +0200
cui: Port Callout tab page from ValueSet to weld::IconView
Therefore, drop the logic in ValueSet handling that
flag, to simplify the code.
This also means that the `pItem` param for ValueSet::ImplDrawSelect
is now unused, so drop that one, too.
Change-Id: I0150e699602a625874e5a09b8df38110f52c0c03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211898
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The value of `n` is only used in the first branch.
Reduce the variable scope to that one.
Addresses this warning shown in Qt Creator:
/home/michi/development/git/libreoffice/svtools/source/control/valueset.cxx:1522:8: Value stored to 'n' is never read [clang-analyzer-deadcode.DeadStores]
Change-Id: Ib6e74fb35152c1d6098274e1fd5a9a60253b4900
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211897
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the order in which the widgets in the .ui file
are defined so that the order better matches the visual appearance
and logical order, which makes sure that tab focus order with the
Qt-based VCL plugins is correct as well when using native Qt
widgets (SAL_VCL_QT_USE_WELDED_WIDGETS=1), where
focus order is (by default) based on widget creation order.
See
commit 02692566ad
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Oct 24 17:43:35 2024 +0200
tdf#130857 optnewdictionarydialog.ui: Define focusable widgets in order
for more background.
The tab page can be triggered like this:
* start Draw
* make sure the "Text" toolbar is enabled in
"View" -> "Toolbars" -> "Text"
* in that "Text" toolbar, select the "Callouts" shape
and insert it into the document
* right-click on the newly inserted shape to open the context menu
* activate the "Position and Size" menu entry
* switch to the "Callout" tab
The Python script mentioned in the commit message of
commit 327679b2fb
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 8 15:50:59 2026 +0200
tdf#130857 Define widgets in Calc "General" options page in order
was used to reorder the GtkGrid children automatically.
Change-Id: Ice8f6b318f57411bea553311faf45b40cb098b44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211883
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Port the widget to select the connector type using a ValueSet
widget to using weld::IconView.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom widget logic.
Adjust indices used to account for the fact that
weld::IconView indices are 0-based while the ValueSet ones
are 1-based.
Increase the item padding in the .ui file to 18 to
use more space for the individual items, to be more
similar to the previous ValueSet implementation.
The tab page can be triggered like this:
* start Draw
* make sure the "Text" toolbar is enabled in
"View" -> "Toolbars" -> "Text"
* in that "Text" toolbar, select the "Callouts" shape
and insert it into the document
* right-click on the newly inserted shape to open the context menu
* activate the "Position and Size" menu entry
* switch to the "Callout" tab
Change-Id: I1c23a305322105608d0152bcd0b0fa195be14eff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211882
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop ValueSet forward declarations from headers
not actually using the class.
Forward-declare the class in cui/source/inc/numpages.hxx
which actually uses it, but didn't forward-declare it
or include the header yet, but previously got the forward-declaration
from an included header.
Change-Id: I8876ad47eb362f581aa41ee4a61a85c4093a1dd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211881
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Instead of first inserting entries with a dummy image
and then setting the actual images using
ValueSet::SetItemImage, just insert the actual images
when inserting the entries right away.
Change-Id: I24b3e2a3a1e86a72eb99755c31602ac96845c9e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211880
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Without this in place, the following assert
would be triggered when closing the dialog:
soffice.bin: /home/michi/development/git/libreoffice/include/vcl/vclptr.hxx:134: VclPtr<SfxAbstractTabDialog>::~VclPtr() [reference_type = SfxAbstractTabDialog]: Assertion `(!m_rInnerRef.get() || m_rInnerRef->isDisposed() || m_rInnerRef->getRefCount() > 1) && "someone forgot to call dispose()"' failed.
Steps to reproduce:
* start Draw
* make sure the "Text" toolbar is enabled in "View" -> "Toolbars" -> "Text"
* in that "Text" toolbar, select the "Callouts" shape and insert it into the document
* right-click on the newly inserted shape to open the context menu
* activate the "Position and Size" menu entry to open the dialog
* press the "OK" button to close the dialog again
Change-Id: I2ddf9b6b0997db091ff8bc320ae04fbbfee19415
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211879
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This means that native Qt widgets are used for this dialog
now when using the qt5 or qt6 VCL plugin and starting LO with
environment variable SAL_VCL_QT_USE_WELDED_WIDGETS=1 set.
The dialog can be triggered like this:
* start Draw
* make sure the "Text" toolbar is enabled in "View" -> "Toolbars" -> "Text"
* in that "Text" toolbar, select the "Callouts" shape and insert it into the document
* right-click on the newly inserted shape to open the context menu
* activate the "Position and Size" menu entry
Closing the dialog currently triggers an assert,
but this is unrelated to this change and e.g.
also seen when using the gen vcl plugin and will
be addressed separately in an upcoming commit:
soffice.bin: /home/michi/development/git/libreoffice/include/vcl/vclptr.hxx:134: VclPtr<SfxAbstractTabDialog>::~VclPtr() [reference_type = SfxAbstractTabDialog]: Assertion `(!m_rInnerRef.get() || m_rInnerRef->isDisposed() || m_rInnerRef->getRefCount() > 1) && "someone forgot to call dispose()"' failed.
Change-Id: I7ba1020dc045d95098ee45b1551f3e641141130b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211878
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This UI file is used for the "Callout" tab page
that can be triggered like this:
* start Draw
* make sure the "Text" toolbar is enabled in
"View" -> "Toolbars" -> "Text"
* in that "Text" toolbar, select the "Callouts" shape
and insert it into the document
* right-click on the newly inserted shape to open the context menu
* activate the "Position and Size" menu entry
* switch to the "Callout" tab
Change-Id: I93118b94d5e7f63322df88ff1e6057cdc9b10ecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211877
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Without this, Qt Creator shows this error:
labdlg.hxx:60:27: No member named 'ComboBox' in namespace 'weld' (fix available)
Change-Id: Ica26b748976c0f034c490c92a16b1d393191529e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211876
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
There's no need to store the images in an array. Just
create the images when inserting them into the ValueSet instead.
Change-Id: I44506a80e461c7e3abfa2b8e059bd71757f1a731
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211875
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Merge the logic into the only caller, the
SvxCaptionTabPage ctor, which already directly inserts
items into the ValueSet as well.
Change-Id: Iab3264c8f4679eea9e6d3538e64c81704fbcb026
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211874
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Following
Change-Id: I3cdb85a966693514521637f672255ba086b9eb19
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Oct 6 09:33:08 2026 +0200
svx: Port shapes panel from ValueSet to weld::IconView
, stop storing the slot IDs/UNO commands corresponding to the
items in the icon views in DefaultShapesPanel in a map and
instead store them as the ID of the items directly in the
weld::IconView, which simplifies the logic a bit.
Change-Id: I97643abd64436cf106b88f835edf6e5c8fb5f7c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211857
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Port the widgets to select shapes to insert in the
Draw/Impress "Shapes" sidebar panel from using a ValueSet
widget to using weld::IconView.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom widget logic.
Adjust indices used to account for the fact that
weld::IconView indices are 0-based while the ValueSet ones
are 1-based.
The UI can be triggered like this:
* start Impress
* open the sidebar
* switch to the "Shapes" sidebar deck
Change-Id: I3cdb85a966693514521637f672255ba086b9eb19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211856
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of iterating over the DefaultShapesPanel::m_aShapesSetMap
elements twice, do so only once and just do everything that needs to be done
for each of the elements right away.
Change-Id: I0b774ccbed7e5110f57d0ce6cc6cf2382a6b923e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211854
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Merge DefaultShapesPanel::populateShapes into its only caller,
DefaultShapesPanel::Initialize.
This will also allow to merge the two for loops into one in an upcoming
commit.
Change-Id: I404d056424cc80bda76332543deee6ff287094ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211853
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Commit the results of running
for a in `git ls-files "*.ui"`; do bin/ui-rules-enforcer.py $a; done
Change-Id: I7a97f75773b9e5750dcce848d730960a8561916b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211850
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Both callers in subclasses pass the own frame. Use it
directly instead of requiring that callers pass it explicitly.
Change-Id: I5e40e86a0f6b4e76838234aacc32de71aad8ef22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211746
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
All of the 3 QtGraphicsBase subclasses
(QtGraphicsBackend, QtGraphics, QtSvpGraphics)
have their own QtFrame* member.
Deduplicate by moving it to the shared QtGraphicsBase
base class and adding a protected getter.
This will also allow having more QtFrame-related
logic directly in the base class in the future.
(An upcoming commit will get rid of the need to
pass the frame to QtGraphicsBase::ImplGetResolution
and it might e.g. also help to centralize new logic for
QtGraphics and QtSvpGraphics suggested to be added in pending
Gerrit changes [1] and [2].)
[1] https://gerrit.libreoffice.org/c/core/+/210650/6
[2] https://gerrit.libreoffice.org/c/core/+/210651/8
Change-Id: Ie6775b7dae0f1c8a68169ddbd746d3244b01e200
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211745
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
The last caller of ValueSet::SetItemData and
ValueSet::GetItemData was ported away from
using ValueSet in
Change-Id: I423e80bba9e81a98e80652f6486970d40286362e
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Oct 2 12:36:17 2026 +0200
svx: Switch to weld::TreeView in LineWidthPopup
. Drop the now unused methods and the corresponding
ValueSetItem::mpData member that could previously be used
to store custom data in an item.
Similar logic still exists in weld::IconView
and weld::TreeView, which should generally be preferred
over using the custom ValueSet widget.
Change-Id: I7d58ff933cb78a1157d3628096a17f68ddf2034d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211737
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of using a custom ValueSet subclass to
draw images and text next to them for selection
in the line width popup, use a weld::TreeView with
two columns: one for the image, and one for the text.
This is similar to what
commit b185d34642
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Nov 28 14:12:04 2025 +0100
tdf#168120 sc: Switch to weld::TreeView in CellLineStyleControl
did elswhere.
Adjust indices used to account for the fact that
weld::TreeView indices are 0-based while the ValueSet ones
are 1-based.
The special "Last custom value" entry so far was
using two separate images, depending on whether
or not it was enabled/sensitive or not: If it is
disabled, a greyed out variant of the image was used.
With the switch to weld::TreeView, leave that up
to the TreeView by simply enabling/disabling the
corresponding row using weld::TreeView::set_sensitive
for the corresponding row.
Drop the now unused LineWidthValueSet.
This switch to weld::TreeView reduces custom widget
logic and custom drawing and makes this more consistent
with other widgets used elsewhere (e.g. like for the
one mentioned in the commit above, the usual font
is used now as well, and it also aligns the behavior
more with that one.)
The popup for configuring the line thickness that uses
this code can be triggered like this:
* start Writer
* insert a chart using "Insert" -> "Chart..."
* select the chart wall in the chart
* open the "Properties" sidebar deck
* in the "Line" section of that sidebar deck, click on the
"Thickness" button/combobox
Change-Id: I423e80bba9e81a98e80652f6486970d40286362e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211735
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The std::map<sal_uInt16, OUString> members of SvxShapeCommandsMap
use ascending integers for the key, i.e. keys start with 0
and go up to N-1 if N is the number of elements.
Vector elements can be accessed by index as well, so switch to
using std::vector to simplify the logic.
To be safe, add an index check in
DefaultShapesPanel::ShapeSelectHdl
(std::map::operator[]() would implicitly insert a new
element when called with a non-existing key.) and
switch to std::vector::at() that performs bounds checks.
Change-Id: I0afc8d53a98d529b0d30344fccedd2167b5f595c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211731
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
commit 09c6204b63
Date: Thu Feb 29 17:15:23 2024 +0100
tdf#81880 Search the Gallery
dropped the `maThemeSelectionHandler` member, but left this
code using it, but commented out. Drop it, as it's no longer
relevant.
Change-Id: I50c8f255a2eb993497aafe20b5bafab18054b682
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211743
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In the same way that
Change-Id: I188f812f2d03fa8cbd97ffaaab3081094809887e
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Oct 1 10:29:15 2026 +0200
chart2: Port "Chart Type" dialog from ValueSet to weld::IconView
had done for the "Chart Type" dialog, also port the chart
sidebar from using the custom ValueSet widget to weld::IconView.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom logic.
It can be triggered like this:
* start Writer
* insert a chart using "Insert" -> "Chart..."
* while the chart is still selected, open the "Properties"
sidebar deck
Change-Id: I858dda4b9d5bf62291ee3b0c76b13ee92221f9e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211660
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the order in which the widgets in the .ui file
are defined so that the order better matches the visual appearance
and logical order, which makes sure that tab focus order with the
Qt-based VCL plugins is correct as well when using native Qt
widgets (SAL_VCL_QT_USE_WELDED_WIDGETS=1), where
focus order is (by default) based on widget creation order.
See
commit 02692566ad
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Oct 24 17:43:35 2024 +0200
tdf#130857 optnewdictionarydialog.ui: Define focusable widgets in order
for more background.
The dialog can e.g. be triggered like this:
* start Writer
* insert a chart using "Insert" -> "Chart..."
* right-click on one of the bars in the chart to open
the context menu
* activate the "Chart Type..." menu item
The Python script mentioned in the commit message of
commit 327679b2fb
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 8 15:50:59 2026 +0200
tdf#130857 Define widgets in Calc "General" options page in order
was used to reorder the GtkGrid children automatically.
Change-Id: Iafe15ceba9e7c8b7651114e538b9ca20915c2367
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211659
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Port the widget to select the chart subtype in the "Chart Type"
dialog from using a ValueSet widget to using weld::IconView.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom logic.
Adjust indices used to account for the fact that
weld::IconView indices are 0-based while the ValueSet ones
are 1-based.
The dialog can be triggered like this:
* start Writer
* insert a chart using "Insert" -> "Chart..."
* right-click on one of the bars in the chart to open
the context menu
* activate the "Chart Type..." menu item
The chart sidebar (ChartTypePanel) will also be ported
in an upcoming commit.
Change-Id: I188f812f2d03fa8cbd97ffaaab3081094809887e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211658
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Simplify drawing a line of N pixels height by drawing a
filled rectangle of that height, instead of drawing N lines
with a height of 1 pixel each.
The popup for configuring the line thickness that uses
this code can be triggered like this:
* start Writer
* insert a chart using "Insert" -> "Chart..."
* select the chart wall in the chart
* open the "Properties" sidebar deck
* in the "Line" section of that sidebar deck, click on the
"Thickness" button/combobox
Change-Id: Ie5f3bb7c25cfddaf17f3b181f6d0cac4723e1459
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211711
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`aLineEnd` uses the same calculation for the Y coordinate as `aLineStart`.
Simplify and make that more obvious by reusing the already calculated
one from `aLineStart`
Change-Id: I7e12c6fcf526d50dcd6d1d9dc19805cc01837c2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211710
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Inline the logic when called with a non-zero param
to the only caller that passes a non-zero value.
Rename to LineWidthValueSet::UnselectItems and stop
passing any param for the callers previously passing
a zero parameter.
This will also make it a bit more straight-forward
to port away from the custom LineWidthValueSet to using
a weld::TreeView in an upcoming commit.
The popup for configuring the line thickness that uses
this code can be triggered like this:
* start Writer
* insert a chart using "Insert" -> "Chart..."
* select the chart wall in the chart
* open the "Properties" sidebar deck
* in the "Line" section of that sidebar deck, click on the
"Thickness" button/combobox
Change-Id: Ieed1323cd8d82c498a676c4408754880f61a8fcd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211709
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Instead of tracking the currently selected entry via
LineWidthValueSet::nSelItem in addition to using the
selection logic of the ValueSet base class, drop that
separate member and use the existing ValueSet logic
to determine what item is selected.
This will also make it a bit more straight-forward
to port away from the custom LineWidthValueSet to using
a weld::TreeView in an upcoming commit.
The popup for configuring the line thickness that uses
this code can be triggered like this:
* start Writer
* insert a chart using "Insert" -> "Chart..."
* select the chart wall in the chart
* open the "Properties" sidebar deck
* in the "Line" section of that sidebar deck, click on the
"Thickness" button/combobox
Change-Id: Ie45eb1233b70c7a5ff814ade3fde774e2eb983b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211708
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is used for the popup that allows configuring the
line thickness which can be triggered like this:
* start Writer
* insert a chart using "Insert" -> "Chart..."
* select the chart wall in the chart
* open the "Properties" sidebar deck
* in the "Line" section of that sidebar deck, click on the
"Thickness" button/combobox
Change-Id: Ib06e95f19d33e983c9641e920572cd57a3272b5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211707
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Port the "Style Presets" panel in Writer's experimental
"Design" sidebar panel from using a custom ValueSet
widget to using weld::IconView.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom logic.
The UI can be triggered like this:
* start Writer
* in "Tools" -> "Options" -> "Advanced", enable experimental
features (and restart as needed)
* open the sidebar
* switch to the "Design" sidebar panel
Change-Id: I5ac862254c2e09f8ad595eff1623d9f2f5f9b676
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211705
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Following up to
commit 6296615b8d (master-android)
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 29 14:20:18 2026 +0200
tdf#173695 svx: Ensure minimum height for ColorWindow
and
commit 5c53840b57
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 30 10:15:59 2026 +0200
tdf#173695 svx: Increase min height for ColorWindow icon view to 250
, switch from using a minimum height of 250 to using
that as the fixed height.
The idea of using a minimum size was to still allow
using more space for the ColorWindow when a palette
with a lot of colors is initially selected.
However, the fact that the size of the popup differs
depending on what palette is initiallly selected is
considered confusing/as a bug, so instead use a fixed
height after all, see discussion in tdf#173695 for
more details/background.
A fixed height was also used when SvxColorValueSet
was still used in ColorWindow, i.e. before
commit a4d5983b4e
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 5 11:48:54 2026 +0200
tdf#130857 Port ColorWindow from SvxColorValueSet to ColorIconView
By then, the size could more easily be optimized to
just fit the colors of the "Standard" palette. With
weld::IconView being used now, the exact spacing can
differ depending on what toolkit/theme/style is used, see
the above-mentioned 5c53840b57
for more details.
Which properties are evaluated in the .ui file
depends on the weld implementation.
While the GTK implementation evaluates
GtkScrolledWindow::min-content-height
and GtkScrolledWindow::max-content-height, the vcl one
doesn't do that. Also set GtkWidget::height-request so
the fixed height also applies for that one.
Change-Id: I7c49218872610bcf345b35849d664f85d29fdc47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211678
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add an intermediate OAccessible subclass to avoid this
linker error otherwise seen in my local --with-visual-studio=2022
build on Windows:
icomphelper.lib(comphelper.dll) : error LNK2005: "public: virtual class com::sun::star::uno::Any __cdecl cppu::ImplInheritanceHelper<class comphelper::OAccessible,class com::sun::star::accessibility::XAccessibleSelection>::queryInterface(class com::sun::star::uno::Type const &)" (?queryInterface@?$ImplInheritanceHelper@VOAccessible@comphelper@@VXAccessibleSelection@accessibility@star@sun@com@@@cppu@@UEAA?AVAny@uno@star@sun@com@@AEBVType@4567@@Z) already defined in GraphCtlAccessibleContext.o
icomphelper.lib(comphelper.dll) : error LNK2005: "public: virtual void __cdecl cppu::ImplInheritanceHelper<class comphelper::OAccessible,class com::sun::star::accessibility::XAccessibleSelection>::acquire(void)" (?acquire@?$ImplInheritanceHelper@VOAccessible@comphelper@@VXAccessibleSelection@accessibility@star@sun@com@@@cppu@@UEAAXXZ) already defined in GraphCtlAccessibleContext.o
icomphelper.lib(comphelper.dll) : error LNK2005: "public: virtual void __cdecl cppu::ImplInheritanceHelper<class comphelper::OAccessible,class com::sun::star::accessibility::XAccessibleSelection>::release(void)" (?release@?$ImplInheritanceHelper@VOAccessible@comphelper@@VXAccessibleSelection@accessibility@star@sun@com@@@cppu@@UEAAXXZ) already defined in GraphCtlAccessibleContext.o
icomphelper.lib(comphelper.dll) : error LNK2005: "public: virtual class com::sun::star::uno::Sequence<class com::sun::star::uno::Type> __cdecl cppu::ImplInheritanceHelper<class comphelper::OAccessible,class com::sun::star::accessibility::XAccessibleSelection>::getTypes(void)" (?getTypes@?$ImplInheritanceHelper@VOAccessible@comphelper@@VXAccessibleSelection@accessibility@star@sun@com@@@cppu@@UEAA?AV?$Sequence@VType@uno@star@sun@com@@@uno@star@sun@com@@XZ) already defined in GraphCtlAccessibleContext.o
Creating library C:/Users/mwegh/development/git/libreoffice/workdir/LinkTarget/Library/isvx.lib and object C:/Users/mwegh/development/git/libreoffice/workdir/LinkTarget/Library/isvx.exp
C:\Users\mwegh\development\git\libreoffice\instdir\program\svxlo.dll : fatal error LNK1169: one or more multiply defined symbols found
This is somewhat similar to
commit f5667d1e3b
Date: Thu Jun 26 18:25:31 2025 +0500
Fix error LNK2005 in MSVC after recent sd changes
Change-Id: I8f01ea095d0a196c61521f92ea9ec76217941aeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211618
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That UNO service was dropped in
commit bcd90334e8
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 2 10:31:59 2026 +0200
[API CHANGE] a11y: Drop com.sun.star.accessibility.AccessibleContext
, so don't claim to implement it.
Change-Id: I8c569f1db4c05228ba18a2d8e20b96b8712764f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211617
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Earlier commit
commit 6296615b8d
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 29 14:20:18 2026 +0200
tdf#173695 svx: Ensure minimum height for ColorWindow
had ensured a minimum height of 200 pixels for the ColorIconView
in ColorWindow.
As discussed in tdf#173695, increase the minimum height
to 250 pixels which should be sufficient to show all rows of the
"Standard" color palette even if different styles/themes
(when using an actual toolkit like GTK or QT) may result
in slightly different spacing.
Quoting explanation from tdf#173695 comment 5 of why at least 10 rows
should be shown:
> The "Standard" palette does not merely contain 12 hues arranged in 12
> columns; it also uses 9 rows to provide 9 different shades for each hue.
> (The topmost row contains 12 achromatic colours with different
> brightness values, making 10 rows in total.)
>
> If this were a user-created palette, this might not matter. However,
> since the palettes provided as official presets have a
> two-dimensional structure, I think that preserving that structure
> requires at least the 12 columns × 10 rows that were available
> previously.
Change-Id: Iafee178ceab6ccbbf6d880fa45cd90e3fd81be9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211601
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
For drawing the currently highlighted item in
a vcl IconView, the text color is set to the highlight
text color in IconView::PaintEntry.
This is for example white when using gen or qt6 with a light
theme.
However, the color wasn't reset to the original color
any more since
commit 7cd00ca413
Date: Thu Jan 30 09:55:02 2025 +0200
use more OutputDevice::Push/Pop (tdf#164799 related)
, so white was still used to draw the text for
any items after the selected item as well, and
the white text on white background was not visible.
Make sure the text color gets reset again by adding
the vcl::PushFlags::TEXTCOLOR flag for the ScopeGuard
as well.
Change-Id: I3ffd1ea0295bbf0faa4226d9573e1f5230b8ed7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211573
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The number of colors displayed in the ColorIconView
in ColorWindow depends on the selected palette.
When the popup is shown for the first time, its
size is calculated based on the size of the
widgets it contains, and the size of the weld::IconView
used for ColorIconView is in turn based on the number
of colors in the initial palette.
If the initial palette has few (or no) colors,
switching to a palette with many colors results
in the need for the weld::IconView to use more
space than previously to show the additional items,
but since the popup doesn't resize, it remains at
its initial size and the selection of colors is
inconvenient or even impossible.
Avoid the problem by ensuring the ColorIconView
has a minimum height of at least 200 pixels.
Before the switch to ColorIconView in
commit a4d5983b4e
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 5 11:48:54 2026 +0200
tdf#130857 Port ColorWindow from SvxColorValueSet to ColorIconView
, the SvxColorValueSet widget in use previously
was always set to a fixed size altogether.
Change-Id: I7b24dd823083891126cf7b4d0ebe1914c1e0cc87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211565
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, ChartTypeDialogController::fillSubTypeList
(and its overrides) was clearing all existing
entries of the passed ValueSet widget and inserting
items for the chart types it handles.
Change the logic to return a vector of entries for
the corresponding chart types instead and let the
callers handle clearing the ValueSet and inserting
the entries instead.
This way, the ChartTypeDialogControllers don't have
to know/rely on the implementation detail what exact widget
is used to display the chart types.
This can simplify porting away from the use of the
custom ValueSet widget in the future, e.g. to
weld::IconView.
Change-Id: I98b32dee7d67b2a9e8c8474c464cacebb21b717e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211557
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Introduce new ImplImageTree::mbPreferDark member to
replace the static variable introduced in
commit 3a9ee3a2a7
Date: Sat Sep 26 12:14:17 2026 +0200
Resolve tdf#173739 - Consider dark UI for icon fallback
, see also discussion in [1].
There's only a single ImageTree (and therefore) ImplImageTree
instance that can be retrieved using ImageTree::get.
While at it, also switch the formatting/indentation of the
`else if` in ImplImageTree::fallbackStyle to a more conventional
one.
[1] https://gerrit.libreoffice.org/c/core/+/211478/comments/d66b922c_086d381c
Change-Id: Ib5cbcd5ae0e227b4eecad256d69cbd07579d8c73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211553
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
There's only a single instance of the class
that can be retrieved using ImageTree::get.
Make the ctor private to clarify that.
Change-Id: I75bd6e60e8079f5ddcef49200280fa61bbf1c4ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211552
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Let FontNameBox::LoadMRUEntries simply return the
entries loaded from the file instead of applying
them to the combobox right away.
Let the only caller FontNameBox::Fill do the insertion,
which also unifies the two different code paths of
either reinserting the existing entries or setting
the ones loaded from the file a bit more.
While at it, also rename the local `rEntries`
variable to `aEntries`, to make clear this is
not actually a reference (as the `r` prefix
previously suggested).
Change-Id: I89c14f2bcd34c4b6b4decf33e98bef54e7b31cf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211536
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Not only the freetype headers, but also freetype linker
flags are needed when building using internal cairo.
Adjust accordingly. (The 'freetype' external already
uses the 'freetype_headers' one, so specifying only
'freetype' is enough.)
This fixes the following build error otherwise seen in
a wasm/Emscripten build after
commit ea7166ec8b
Date: Fri Jul 24 18:01:51 2026 +0300
vcl: Don’t link against freetype
It is not used directly anymore.
:
em++: warning: EXPORT_EXCEPTION_HANDLING_HELPERS is deprecated (getExceptionMessage is exported anyway when ASSERTIONS or EXCEPTION_STACK_TRACES is set, which are set by default at -O0. At -O1 or above, you can export it separately by -sEXPORTED_RUNTIME_METHODS=getExceptionMessage,decrementExceptionRefcount.). Please open a bug if you have a continuing need for this setting [-Wdeprecated]
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Outline_Transform
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Outline_Decompose
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Done_Face
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_New_Face
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Set_Transform
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Set_Char_Size
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_MM_Var
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Var_Design_Coordinates
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Done_MM_Var
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_MM_Var
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Var_Design_Coordinates
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Set_Var_Design_Coordinates
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Done_MM_Var
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Init_FreeType
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Paint
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Paint
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Layer
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Layer
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Load_Glyph
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Layer
wasm-ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
Same also seen in the Tinderbox wasm builds:
https://ci.libreoffice.org/view/tb%20platform%20status/job/lo_daily_tb_linux_wasm/1547/console
Change-Id: Iea8725f9177417cdd3d6e410f693b9ac46d95e78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211510
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When in RTL mode (e.g. enabled via SAL_RTL_ENABLED=1),
translate/invert the X value as needed when retrieving/setting
it for the ColorFieldControl.
Otherwise, the position is horizontally inverted/mirrored
as described in tdf#173418 in the custom LO color chooser
dialog (e.g. clicking at the color at the right edge sets the
color that's at the left edge).
Change-Id: Ifd3e5b93aab4e8f3cf8ed72f0bedab652e9cb1e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211458
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Trying to create and populate the submenu for the "Gallery"
menu entry in the bullets and numbering dialog only when
its menu button is clicked is too late, as the toggle
handler isn't guaranteed to be called before the menu
gets shown. Therefore, instead do this as soon as the
menu button gets shown.
This is similar to what
commit 9456449751
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 20 18:20:42 2025 +0200
tdf#167034 sd: Populate graphics bullet menu when creating dlg
did for the Impress-specific bullets and numbering dialog,
but now for the dialog used in other modules.
Steps to reproduce:
* start Writer
* "Format" -> "Bullets and Numbering..."
* go to "Customize" tab
* select "Graphics" in the "Type" combobox
* Press the "Select..." menu button
* hover over the "Gallery" menu item to open its submenu
Without this commit in place, the menu would not be shown
unless using the gtk3 vcl plugin.
For the vcl implementation (SalInstanceMenuButton), the
submenu would be present after the menu button got clicked
for the second time.
For the implementation using native Qt widgets
(QtInstanceMenuButton, enabled via SAL_VCL_QT_USE_WELDED_WIDGETS=1)
the submen would even not be shown then.
With this commit in place, the menu is now shown as
expected already the first time for all 3 weld::MenuButton
implementations.
Change-Id: I9076efe1375360554701d76c5330494eceba1391
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211423
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Add the usual "m_" prefix to those SvxNumOptionsTabPage
members that don't have it yet, to make it easier to
distinguish them from local variables by their name.
Change-Id: I08eb0870efe37bf81a4b8da32ee37d75f73ce639
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211422
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
QtInstanceContainer has a virtual QtInstanceContainer::getLayout
method that is responsible for providing a QLayout when needed.
The base class implementation just returns the widget's layout,
but subclasses could be doing something else. Therefore, don't
already assert that the widget has a layout in the ctor.
If QtInstanceContainer::getLayout is called, that one
already has the same assert. (Add a message to that assert.)
This way, the check will only be performed once a layout
is actually needed.
The main motivation for this change is that QColorDialog
used in QtInstanceColorChooserDialog isn't guaranteed to
have a layout when a platform-native one is used, which
is e.g. the case on current KDE Plasma by default,
unless deactivated, which could be done like this:
--- a/vcl/qt5/QtInstance.cxx
+++ b/vcl/qt5/QtInstance.cxx
@@ -985,6 +985,7 @@ QtInstance::CreateColorChooserDialog(weld::Window* pParent, vcl::ColorPickerMode
std::unique_ptr<weld::ColorChooserDialog> pColorChooserDialog;
RunInMainThread([&] {
QColorDialog* pDialog = new QColorDialog(GetQWidget(pParent));
+ pDialog->setOption(QColorDialog::DontUseNativeDialog);
pColorChooserDialog = std::make_unique<QtInstanceColorChooserDialog>(pDialog);
});
Without this change (and without deactivating the native dialog),
opening e.g. the font color chooser in the Writer formatting
toolbar and then pressing the "Custom color..." button would
otherwise trigger the assert.
(QtInstanceColorChooserDialog also doesn't override
QtInstanceContainer::getLayout, so if any of the
weld::Container method implementations actually requiring
a layout were ever called the assert would still be triggered,
but that is not the case. Should that ever become relevant
in the future, disabling the native dialog could be one
potential way forward.)
Change-Id: I6d34e46d564af7a7da56cba5413872e13ba51a9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211420
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This makes clear the return value is non-null and
allows to drop the null check in one caller.
Change-Id: I7f3df77029af7a0a722c743afdb3b8a0f9b1e730
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211419
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... and rename accordingly. This makes clear it's
always non-null and therefore safe to dereference.
Change-Id: Ic01556edfc9fea9cf74ce6087a36c7c9a2f39a4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211418
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Instead of hard-coding the spacing for the vcl IconView
implementation to 5 pixels, use that as the default, but
override it with the GtkIconView::item-padding [1] property
if that one is set for an icon view in a .ui file.
Together with previous commit
Change-Id: I703504b7e2ce0c4b5351a95616112950a33332dd
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 23 11:00:24 2026 +0200
tdf#173578 Reduce spacing between ColorIconView items
, this results in the spacing between ColorIconView items
now also being smaller than before when the vcl implementation
(SalInstanceIconView) is used.
[1] https://docs.gtk.org/gtk3/property.IconView.item-padding.html
Change-Id: If4997dd5ea40659532424c600bb74e185c69b102
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211359
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
With the switch from the custom SvxColorValueSet
to the weld::IconView based ColorIconView in
commit 701cea2393
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Apr 17 09:45:29 2026 +0200
tdf#130857 Introduce ColorIconView, port "Area" page's "Color" section to it
and
commit a4d5983b4e
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 5 11:48:54 2026 +0200
tdf#130857 Port ColorWindow from SvxColorValueSet to ColorIconView
and
commit 9ed6b0a88f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jun 8 14:00:33 2026 +0200
Use ColorIconView for SvxDefaultColorOptPage
and
commit dc3b6ec185
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 10 10:25:27 2026 +0200
tdf#130857 sc: Port tab color dialog to ColorIconView
, spacing between the color items was implicitly
switched to the default values for the IconView
implementations, which is quite a bit more than
it was before at least for the GTK and vcl
implementations.
As requested in tdf#173578, reduce the spacing
again.
Now that weld::IconView is used, use the corresponding
GtkIconView spacing properties that can be set in
the .ui file.
For the GTK implementation (GtkInstanceIconView),
these are applied "automatically" because
GTK handles them internally.
For the vcl and Qt implementations (SalInstanceIconView
and QtInstanceIconView), they are not yet applied because
these properties are not evaluated yet.
For the vcl implementation, evaluating
GtkIconView::item-padding [1] will be added in
an upcoming commit.
For the Qt implementation, the spacing looks quite OK
to me (at least with the Fusion style on Linux).
Evaluating that property could still be added later as
needed. QListView::spacing [2] looks related.
[1] https://docs.gtk.org/gtk3/property.IconView.item-padding.html
[2] https://doc.qt.io/qt-6/qlistview.html#spacing-prop
Change-Id: I703504b7e2ce0c4b5351a95616112950a33332dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211358
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
If the intent for opening the document does not have
the MIME type set, use ContentResolver to resolve
the MIME type from the document URI.
On top of previous commit
Change-Id: I6a81dd65e7ef9a233ee9b507c9e133d419cf985c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Sep 21 14:47:26 2026 +0200
tdf#173650 android: Support opening Markdown files
, this also makes the scenario of opening a Markdown
document work on an an Android AVD with API level 37
(Android 17) when trying to open the file from within
the app ("Select file to open") instead of passing the
file "from outside" (e.g. by opening it from the
"Files" app).
Change-Id: Ie071ce8770155b97dd3a70d26620560a39a7e356
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211292
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Declare support for the Markdown MIME type
"text/markdown" for LibreOffice Viewer for Android.
Similar to CSV, make sure that the temporary file
passed to LibreOffice has a file name ending on
".md", otherwise it is imported as a plain text
file instead of a Markdown document.
This allows opening Markdown files from the Android
file manager ("Files" app) as tested successfully
on an Android AVD with API level 37 (Android 17).
However, when trying to open the file from within
the LibreOffice app ("Select file to open"), the
file is still grayed out and cannot be selected.
This will be addressed separately in upcoming commit
Change-Id: Ie071ce8770155b97dd3a70d26620560a39a7e356
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Sep 21 14:51:38 2026 +0200
tdf#173650 android: Resolve MIME type if not passed in intent
Change-Id: I6a81dd65e7ef9a233ee9b507c9e133d419cf985c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211291
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... for some soltools C programs"
The issues previously seen with current glibc versions are
now addressed differently by
Change-Id: I53d66f280ea82d295a2c2c086f4d02a965a893d7
Author: Stephan Bergmann <stephan.bergmann@collabora.com>
Date: Wed Sep 16 13:08:28 2026 +0200
Adapt loplugins to glibc 2.44 assert macro internals
, so revert the previous workaround again.
This reverts commit 5d72f86b56.
Change-Id: Ide517b9592ee1dbf444f000f48b901d474352c07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211064
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In recent weeks, JunitTest_toolkit_complex was seen occasionally
failing in CI, see e.g. last ESC minutes [1]:
> + tests that failed more than twice in last seven days
> [...]
> 18 JunitTest_toolkit_complex gerrit_linux_clang_dbgutil
It's unclear why the failure started to happen recently
and it doesn't happen reliably.
I was unable to reproduce the problem locally, even when running
make JunitTest_toolkit_complex
in a loop.
From a sample Jenkins failure log [2], what *might* be happening
is that the model etc. get disposed before the grid control in
the Java test code.
From the console log:
There were 6 failures:
1) testView(complex.toolkit.GridControl)
com.sun.star.lang.DisposedException
at com.sun.star.lib.uno.environments.remote.JobQueue.removeJob(JobQueue.java:199)
at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:309)
at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:279)
at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:83)
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:619)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:145)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:129)
at jdk.proxy2/jdk.proxy2.$Proxy21.dispose(Unknown Source)
at complex.toolkit.GridControl.impl_dispose(GridControl.java:79)
at complex.toolkit.GridControl.cleanupTestCase(GridControl.java:615)
... 35 trimmed
Caused by: java.io.EOFException
at java.base/java.io.DataInputStream.readInt(DataInputStream.java:386)
at com.sun.star.lib.uno.protocols.urp.urp.readBlock(urp.java:364)
at com.sun.star.lib.uno.protocols.urp.urp.readMessage(urp.java:96)
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.run(java_remote_bridge.java:92)
2) testSortableDataModel(complex.toolkit.GridControl)
com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge@210366b4 is disposed
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.checkDisposed(java_remote_bridge.java:689)
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:603)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:145)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:129)
at jdk.proxy2/jdk.proxy2.$Proxy12.getServiceManager(Unknown Source)
at complex.toolkit.GridControl.createInstance(GridControl.java:654)
at complex.toolkit.GridControl.impl_recreateGridModel(GridControl.java:91)
at complex.toolkit.GridControl.testSortableDataModel(GridControl.java:354)
C++ backtrace:
Thread 1 (Thread 0x7f0aff59adc0 (LWP 2939300)):
#0 0x00007f0b0708d4bc in __pthread_kill_implementation () at /lib64/libc.so.6
#1 0x00007f0b0703fbb6 in raise () at /lib64/libc.so.6
#2 0x00007f0b07029873 in abort () at /lib64/libc.so.6
#3 0x00007f0b0786db51 in (anonymous namespace)::callSystemHandler(int, siginfo_t*, void*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libuno_sal.so.3
#4 0x00007f0b0786d680 in (anonymous namespace)::signalHandlerFunction(int, siginfo_t*, void*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libuno_sal.so.3
#5 0x00007f0b0703fc60 in <signal handler called> () at /lib64/libc.so.6
#6 0x00007f0b0708d4bc in __pthread_kill_implementation () at /lib64/libc.so.6
#7 0x00007f0b0703fbb6 in raise () at /lib64/libc.so.6
#8 0x00007f0b07029873 in abort () at /lib64/libc.so.6
#9 0x00007f0b0702979b in _nl_load_domain.cold () at /lib64/libc.so.6
#10 0x00007f0b070388f6 in () at /lib64/libc.so.6
#11 0x00007f0aff09e392 in com::sun::star::uno::Reference<com::sun::star::awt::grid::XMutableGridDataModel>::operator->() const () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#12 0x00007f0aff0961a1 in (anonymous namespace)::SortableGridDataModel::getRowCount() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#13 0x00007f0aff1dae5c in svt::table::UnoControlTableModel::getRowCount() const () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#14 0x00007f0aff1312b5 in svt::table::TableControl_Impl::doPaintContent(OutputDevice&, tools::Rectangle const&) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#15 0x00007f0aff149fc9 in svt::table::TableDataWindow::Paint(OutputDevice&, tools::Rectangle const&) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#16 0x00007f0afb41f321 in PaintHelper::DoPaint(vcl::Region const*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#17 0x00007f0afb42074f in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#18 0x00007f0afb41ff57 in PaintHelper::~PaintHelper() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#19 0x00007f0afb4207d6 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#20 0x00007f0afb41ff57 in PaintHelper::~PaintHelper() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#21 0x00007f0afb4207d6 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#22 0x00007f0afb41ff57 in PaintHelper::~PaintHelper() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#23 0x00007f0afb4207d6 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#24 0x00007f0afb420c7e in vcl::Window::ImplCallOverlapPaint() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#25 0x00007f0afb420e34 in vcl::Window::ImplHandlePaintHdl(Timer*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#26 0x00007f0afb420cbd in vcl::Window::LinkStubImplHandlePaintHdl(void*, Timer*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#27 0x00007f0afbe37178 in Link<Timer*, void>::Call(Timer*) const () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#28 0x00007f0afbe36fcc in Timer::Invoke() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#29 0x00007f0afbdd92f9 in Scheduler::CallbackTaskScheduling() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#30 0x00007f0afc32ee86 in SalTimer::CallCallback() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#31 0x00007f0afc32ce9e in SvpSalInstance::CheckTimeout(bool) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#32 0x00007f0afc32e07d in SvpSalInstance::ImplYield(bool, bool) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#33 0x00007f0afc32e678 in SvpSalInstance::DoYield(bool, bool) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#34 0x00007f0afbe08bfc in InnerYield(bool, bool) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#35 0x00007f0afbe083cb in Application::Yield() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#36 0x00007f0afbe08167 in Application::Execute() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#37 0x00007f0b0744e27a in desktop::Desktop::Main() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libsofficeapp.so
#38 0x00007f0afbe33c83 in ImplSVMainRun() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#39 0x00007f0afbd2ff31 in SalInstance::SVMainRun() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#40 0x00007f0afbe33082 in ImplSVMain() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#41 0x00007f0afbe34ee9 in SVMain() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#42 0x00007f0b074d143c in soffice_main () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libsofficeapp.so
#43 0x000055da4f9609bd in sal_main () at desktop/source/app/main.c:51
ret = 8
#44 0x000055da4f960997 in main (argc=8, argv=0x7ffe8beae9c8) at desktop/source/app/main.c:49
ret = 538976288
This looks like event processing might have been triggered that
triggers the (re)paint of the TableDataWindow/TableControl_Impl
(frames #15 and #14), but then dereferencing the UnoControlTableModel's
data model in frame #11 fails, maybe because the data model has already
been disposed earlier?
Dispose the grid control at the end of the testView() Java test that is
the one that creates it and the only one using it, so that happens
before the model and data model etc. get disposed in impl_dispose() that gets
called from cleanupTestCase().
That is to prevent that a repaint is still attempted.
(When the TableControl is disposed, it's model is unset,
so svt::table::TableControl_Impl::doPaintContent (frame #14
in the backtrace) will return early, before trying to call
svt::table::UnoControlTableModel::getRowCount that is seen
in frame #13 of the above backtrace.)
Note: The above backtrace does not yet include the commits
refactoring TableControl and TableControl_Impl like
commit 39749ff5b4
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:30:10 2026 +0200
toolkit: Merge TableControl into TableControl_Impl
and
commit b580576a4d
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:44:17 2026 +0200
toolkit: Rename TableControl_Impl to TableControl
and
commit e4f1a48967
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:48:54 2026 +0200
toolkit: Rename TableControl header/source to match new class name
, so the naming and exact code differs slightly with current master,
but as far as I can tell, that otherwise shouldn't have any effect on
the observed behavior.
This is an attempt to address the JunitTest_toolkit_complex failures
mentioned above, without being able to actually verify that locally
(as the failure could not be reproduced locally either).
[1] https://lists.freedesktop.org/archives/libreoffice/2026-September/094885.html
[2] https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/212155/console
Change-Id: If1a5411c92dfdfb49a34b31f4e44ac47d409772c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211231
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
It's a helper method only used by SfxViewShell::ExecPrint,
so doesn't need to be public. Make it private.
Change-Id: I9925e7d47bcd1e2423aaed7e6e3ff6a06726eb82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211230
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to previous commit
Change-Id: I5db3a99bb8d78099e3b136cbcd402fe2ae49d49c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Sat Sep 19 13:12:54 2026 +0200
[API CHANGE] Pass XAccessible to XAccessibleGroupPosition::getGroupPosition
, also pass an XAccessible instead of a uno::Any to
XAccessibleGroupPosition::getObjectLink.
See the above-mentioned commit for more background.
Change-Id: I8440b91eff66a18bc6e431a0ad91362e895d945c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211217
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Instead of passing an XAccessibleContext wrapped in a uno::Any,
pass the XAccessible. This drops an extra level of
wrapping/unwrapping.
The same will be done for XAccessibleGroupPosition::getObjectLink
in an upcoming commit.
Since the XAccessibleGroupPosition interface
(and the UNO a11y API in general) is unpublished
and meant for internal use only, changing it should
be unproblematic.
Change-Id: I5db3a99bb8d78099e3b136cbcd402fe2ae49d49c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211216
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the more concrete OAccessible instead of the abstract
XAccessible UNO interface for AccessibleTabBarPage::m_xParent,
to make clear the parent is always a subclass of that class.
Change-Id: If70401a3403a9c2a6e2205a82bc7fe705d4be510
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211218
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the more concrete OAccessible instead of the abstract XAccessible
UNO interface for that member.
Drop now unnecessary querying for the XAccessibleContext UNO
interface, as OAccessible implements that interface itself
as well.
Change-Id: I689af3c6b72f442967ab7fe4c39d438fc68b09fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211215
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the more concrete OAccessible for the parent param
instead of the abstract XAccessible UNO interface, to
make clear that the parent is always an OAccessible subclass.
Change-Id: I6447f6131e809baddc24a4b413fe4d4748aa7a7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211214
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Use the more concrete OAccessible instead of the
abstract XAccessible UNO interface for that member.
Change-Id: Id811da24db3e48baefa22343d999541cd31546af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211213
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Pass param by the more concrete OAccessible instead
of using the abstract XAccessible UNO interface.
Change-Id: I8f7a2b22328da38e4d0d62b8c91bc45354a1bef9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211212
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Return a default-constructed empty reference directly
instead of first assigning it to a local XAccessible variable.
Change-Id: I8cfb0a22f189eb82643a2b865ccc3bf065cacf9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211211
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use more concrete type instead of the abstract
XAccessible UNO interface for the local variable.
Change-Id: I17149ff7a1be1e3ebf76d2a40f16df564d43437b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211210
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the more concrete OAccessible for the local variable
in ScAccessibleDocumentPagePreview::getAccessibleAtPoint instead
of the abstract XAccessible UNO interface.
Change-Id: I4a0df2d86fea83cb9524b61242781c8ae01fed2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211208
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Michael Weghorn