The gapWidth tag specifies spacing for bar/column-like charts. In old-style
charts, it's given in the type group. In chartex, it is an attribute of the
<cx:catScaling> child element of <cx:axis>. This code thus includes some
structural changes to allow for reading the value in the axis processing
and storing it in the PropertySet associated with a type group (XChartType).
Change-Id: I21bdf3b511269c34c225873ee66fbaf29a7cb0ea
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/718
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit bb1d3ba56f5b17d0979addac95a3973278d2f46b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204149
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Instead of maintaining a ChartColorPalettes::mnHighlightedItemId
and passing an unused MouseEvent to the handlers, rather pass
the ID of the currently hovered-over item (or an empty string)
to the handlers (and convert to sal_uInt16/sal_uInt32 in
ChartColorPalettePopup::MouseMoveHdl instead.
No change in behavior intended or observed.
Sample steps to trigger the logic:
* start Writer
* insert a chart using the "Insert Chart" toolbar item
* click on one of the chart's bars
* in the "Properties" sidebar deck, in the "Colors" section,
click on the arrow to open the color palette popup
* hover over the different palettes and notice how the
colors in the chart show a corresponding preview using
the colors of the currently hovered over palette
Change-Id: I78c7d3612e5e8e4607f5d78315694f6e0e7d33ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203412
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the param for the signal and handlers used when
the selection in a weld::TreeView changes from weld::TreeView&
to the base class, weld::ItemView&.
This is in preparation of moving the logic to the weld::ItemView
base class in an upcoming commit.
Handler implementations that require a weld::TreeView
instance can use the one that the signal is connected
to, e.g. use the class member directly inside of the
implementation instead of using the param (as is done
in most of the places anyway).
Change-Id: I0bbf8fe1dbd95906a5224155d48d832bcd144532
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203366
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, the IconView::signal_item_activated was called
with the weld::IconView itself as a parameter, i.e.
the information what item was selected wasn't directly
passed to the signal handlers.
Change that to pass a weld::TreeIter param referring to the
activated item instead of the IconView itself.
The information what item was activated is relevant
and this way, there is no need to determine it some
other way in the handlers (e.g. by using the first
selected entry).
This also aligns this more with what UI toolkits
like GTK and Qt provide.
For GTK, the GtkIconView::item-activated signal [1]
has the path of the activated entry.
For Qt, the QAbstractItemView::activated signal [2]
has the QModelIndex of the activated item.
For the vcl implementation in SalInstanceIconView::DoubleClickHdl,
use the cursor/current item.
In LOKTrigger::trigger_item_activated, use the currently selected
entry (retrieved via weld::IconView::get_selected), because the
only caller in jsdialog::ExecuteAction uses weld::IconView::select
first to select an entry before triggering the signal.
Initially, leave the logic of the existing signal handlers/callbackes
(in dialog implementations) unchanged. At least some of them
will be simplified in upcoming commits.
[1] https://docs.gtk.org/gtk3/signal.IconView.item-activated.html
[2] https://doc.qt.io/qt-6/qabstractitemview.html#activated
Change-Id: I8ca62ac32108f01e2055d5ef9301de22eb5b1931
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203317
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header and source
file, in order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ic47dac553fc065c5c9cddbf31e33012314dbe43d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199073
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I5b23b02151c75bb49831a2bbf8d515eb0b54415e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199068
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I56cea12845bc906a8b7aff13abe033e9723b85c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198614
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
these were skipped in previous runs, since they contain some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
This also shaves off some 140M input
Change-Id: Ie1f57174dd6fec3ba5b0b91eb0688acdc1a8143d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197494
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
gdb backtrace on the core file:
#8 chart::OfPieChartDialogController::fillExtraControls (this=0x23c15020, xChartModel=..., xTemplateProps=...)
at chart2/source/controller/dialogs/ChartTypeDialogController.cxx:841
#9 0x0000719b38a2076f in chart::ChartTypeTabPage::selectMainType (this=0x23948420)
at chart2/source/controller/dialogs/tp_ChartType.cxx:272
#10 0x0000719b3b656103 in Link<weld::TreeView&, void>::Call (data=..., this=0x1fd52058)
at include/tools/link.hxx:111
and:
(gdb) print aValuesSeries
$1 = std::vector of length 0, capacity 0
But leave the assert in place, so we have a chance to find the deeper
problem in a debug build.
Change-Id: Ic590c777a0a6fbe5fd188b6600c1de908c9a0910
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197926
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[q-w]*
This shaves off about 100M input
Change-Id: Ib4d0af44b383d34d856a9797fe70a974b359402f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196398
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[d-g]*
This shaves off about 150M input
Change-Id: I2b15257451d4b392dca3e5d07f4a443ee653b04c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196395
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ie54aef229609f131d3d53874c9390339566880f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196947
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Previous work on this project added support for Funnel charts, one of the
chartex types. This commit expands that to all the other chartex types,
including RegionMap. Largely this is parallel to what was done for Funnel,
but there are some namespace differences, and ParetoLine requires some special
handling because Microsoft Office seems to encode it as a combination of
clusteredColumn type and paretoLine type. ParetoLine support is incomplete,
especially on the export side.
Change-Id: Ib751632ec05f3fbf248e0f194f7a6f36f2fa6a88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194933
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[A-Z]*
This shaves off about 100M input, not bad for such a small amount
of files checked
This time --headersfwd skips files that contain #if defs,
in hope of not breaking builds that are not checked by CI
(...except for include/vcl/BitmapTools.hxx - this was cleaned accidentally,
due to a bug in the bin/find-unneeded-includes script that is fixed
by the previous commit 930ff2b830
- but let's keep this anyway, it seems fine)
Change-Id: Ia8e49d94f6adb3cdbedbc40ffa56dbf846c9b6e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196235
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header and source
file, in order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I27033905fe8be1c3646c8cf08799c9bf53eeb471
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196448
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header file,
in order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
This also prepare for moving weld::Entry (which is
a weld::FormattedSpinButton base class) to its own header.
Change-Id: Iceb05e4055a22d483be9e0052199f738a7406097
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196447
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header and source
file, in order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I6555d2343ec9b01d7915cd52508c0db4c8704509
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196445
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header and source
file, in order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I43279e6479c9a0b5c9521dadf6e634e22bf39442
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196438
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header and source
file, in order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ib2fe4a6b5e34ad8ae2194ba85249ca25ed16e9d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196435
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the implementation to a new source file in the
vcl/source/weld directory where most of the code for
implementing weld::Widget implementations is by now
(apart from the headers), while
vcl/source/window/builder.cxx is mostly about
VclBuilder.
Change-Id: Ide967dab4a5321871da057f0c6b799dbc21230dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195832
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ifbd413fc8dcfe5e453a0fef8a04f3c396af4c836
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195781
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This is in preparation of moving code out of weld.hxx
to separate headers/source files, in order to make it
easier to keep an overview and to avoid having to
recompile ~all UI code when anything changes.
Also move weldutils.cxx to a new vcl/source/weld
directory.
Change-Id: Ia75b42f21e560dd248307282a522f186a64cd742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195777
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
/svx/source/sidebar/area/AreaPropertyPanelBase.cxx:820:42: runtime error: downcast of address 0x5030003750d0 which does not point to an object of type 'const SfxUInt16Item'
0x5030003750d0: note: object is of type 'XFillTransparenceItem'
00 00 00 00 d0 74 21 ac 12 7f 00 00 00 00 00 00 fb 03 be be 15 00 00 00 89 be 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'XFillTransparenceItem'
#0 0x7f12b02722cf in svx::sidebar::AreaPropertyPanel
after
commit 953219b811
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Wed Dec 3 21:34:19 2025 +0200
make XFillTransparenceItem extend SfxPoolItem
Change-Id: Iaee48c5f5522cab8ec48cffd621cc866151429af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195235
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Julien Nabet