Each series gives one arrow, from the origin to the point whose
1. x-coordinate value is the correlation of that series' feature column
with the first dimension column.
2. y-coordinate value is the correlation of that series' feature column
with the second dimension column.
A symbol marks the tip and the feature name sits beside it. The circle
of radius one and the two lines through the origin are drawn behind the
arrows, and both axes are held at minus one to one on a square plot
area, so a length in the picture means the same in both directions and
the circle stays round.
The correlations are worked out while the shapes are made rather than kept
anywhere, so they follow the cells they come from. Working them out needs the
whole of the three columns.
The correlation coefficient code itself is in a small header of its own
with a test beside it. It leaves out the instances where either side is
missing, and it has no answer for a feature that does not vary or for
fewer than two instances. A feature without an answer gets no arrow,
as there is no direction to point in.
Error bars, trend lines and area properties are turned off for this chart
type, since a point stands for a worked out pair rather than for a value in a
cell, and symbols are turned on because the tip of each arrow carries one. The
arrows take the line colour and width of their series, and the template asks
for thin ones, which is what keeps a crowd of them apart. The legend hands out
the same symbol as the arrow tip, so a key can be matched to an arrow.
Grids are turned off by default for this chart as the user is more
interested in the direction/angles and the magnitude of the "rays" from
the origin.
Change-Id: I2d8b3aa6ef7d66bd9deb1f63a647767a1b62ac90
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8103
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit e096bfee9c85a22e8b8155944a63ee9d6f72f75a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210465
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A correlation circle plot shows how each feature of a table relates to the
first two dimensions of a decomposition of that table, which a user can now
work out in a spreadsheet with MSVD. One point per feature sits at the
correlation of that feature with the first dimension across and with the
second dimension up, inside a circle of radius one.
The data arrives as one series per feature. Each series holds its own feature
column under the new role values-feature, together with the two dimension
columns under values-x and values-y, which every series shares the way the
bubble chart shares its x column. Keeping the dimensions on the x and y roles
means the point count, the axis scaling and the label machinery need no
special case, and the series label comes from the feature column header, so
the legend and the point labels read as feature names.
The interpreter reads a flat list of columns as a feature table followed by
two dimension columns: the last two are the dimensions and every column before
them is a feature. One range holds the lot, which is what the wizard hands
over, and it is also the order the list comes in when a chart of another type
is turned into this one. A first column of instance names is kept out of the
features when the range says it has them, as it is for a bubble chart.
Both dimensions are numbers running from minus one to one, so the chart type
joins the scatter and the bubble chart in asking for a numeric axis across.
That answer is also what turns the axis of names back into a numeric one when
a chart of another type becomes this one, since the coordinate system the
other type left behind is kept and reused.
Change-Id: Id17d3a2a235c849c3dab9768159ddf1608da6d05
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8102
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit b30d992bba26428941f47f952baf338df3763065)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209379
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Histogram bin-property changes regenerated the category sequence stored
on the data series, while the X axis continued referencing the previous
sequence. This left the chart bars updated but displayed stale bin
labels.
Keep the category sequence produced by HistogramDataInterpreter on both
the diagram axis and data series. Update its binning parameters in place
when histogram properties change, allowing existing listeners to
recalculate and redraw the axis labels.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: Ibd6679bddf29de5fa1fd903af9274259b2e9c243
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9282
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 0103afa2a6a746ce54a0e3e4297e1fa60698ef03)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209218
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Add model properties for optional underflow and overflow bins on
histogram chart types, and expose them through the HistogramDiagram
wrapper.
Pass the new settings through the existing histogram pipeline:
HistogramChartType snapshots the properties, HistogramDataSequence keeps
that snapshot, and HistogramCalculator creates optional edge bins around
the normal bin range.
Generated category labels now distinguish special bins from normal ranges,
e.g. "<= 11", "(11-13]", and "> 14".
Add a model-level test that sets fixed bin width together with underflow
and overflow bins, then verifies that the generated bin labels are rebuilt
correctly.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: I65eac9607daa4f4be6320304c9e9682549f479a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207151
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
This commit introduces the mathematical backend and data interpreter for
the Histogram chart, replacing the temporary raw value rendering.
- Adds HistogramCalculator, utilizing Scott's Rule to calculate optimal
bin widths and frequencies from raw data.
- Introduces HistogramDataSequence that listens to spreadsheet data
changes and automatically regenerates bin categories and frequencies
- Implements HistogramDataInterpreter to intercept raw values-y input,
and output the results into the calculated-y data sequence.
Change-Id: Iaf29ddd0b0824bd3f0808ffc91321cad9d5b877e
(cherry picked from commit 1ef619a998aba626d0ea7a9541109a7c9e145518)
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1879
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit df68284255ccac4bd86583555986d9f7cbdddf9a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203747
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This commit introduces the structural foundation and user interface for
the new Histogram chart type. The rendering engine gracefully falls
back to plotting the raw values-y input data directly. As a result, the
chart currently renders identically to a standard bar/column chart.
- Adds UI entries in the Chart Type dialog.
- Adds HistogramChart to the view layer, inheriting from BarChart and
forcing a 0-gap width.
Change-Id: Ica5b15e9b7428d6c908e1b978259367fe8ff7aab
(cherry picked from commit 14a4a09b62fc283f9b629a2a317156efa6509054)
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1878
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 508c3456e85a88771ac5e264cee9460274685a22)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203741
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Many callers pass the result of Chart2ModelContact::getDocumentModel()
which resolves a WeakReference<ChartModel> and can return null if the
model has been destroyed. Add null checks matching the existing pattern
in ControllerLockHelper::lockControllers/unlockControllers.
The crash was caused by a race condition where the ChartModel weak
reference (held in Chart2ModelContact) had expired by the time the
chart wrapper code tried to lock controllers during a Copy operation.
The fix gracefully handles the null case instead of dereferencing
a null pointer.
Change-Id: I43294de12b84cefb062ada12e8a570ad3b7ea571
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200268
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit e819e77fe79e8eb48bb3e977fadaffa9e99786f2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204885
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Replace index-only loops where we copy from containers into UNO or
diagram structures using an explicit sequence index / output pointer:
- BasicColorConfig: vector of property keys into Sequence OUString.
- ChartColorScheme: palette colors into uno color sequence buffer.
- RangeHighlighter: HighlightedRange list from OUString vectors.
Verified: make -j4 basctl chart2
Change-Id: If4a4a8747fadc772329d3ccc3f03778406b140ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204659
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Instead of hard-coding a size based on the icon size
for the icon views in ChartColorPalettes, rather let
the toolkit allocate a proper size.
Tweak some properties in the .ui file to achieve
proper auto-sizing.
Maybe, hard-coding the size was done because before
commit 478b712ea1
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Aug 7 09:45:15 2025 +0200
tdf#167658 vcl: Honor GtkIconView::columns + calc size
, the vcl implementation didn't take the column count
set in the .ui file into account when the original
code was was introduced in
commit a26c93a630
Date: Sun Aug 10 22:33:37 2025 +0200
chart color palettes: switch from drawingarea to IconView
.
In any case, it seems unnecessary now, and not hard-coding
the size e.g. results in all rows being visible at once
when using the gen vcl plugin for the following dialog,
instead of showing only part of them and using a scrollbar
despite there being plenty of space below the icon view.
Steps to trigger a dialog using this:
* start Writer
* "Insert" -> "Chart"
* double-click on a bar in the chart to open the
"Data Series" dialog.
* switch to the "Color Palette" tab
Now, all rows are shown at once for both, the gtk3
and the gen vcl plugins.
The code is also used in the chart palette popup
that can be triggered like this (and whose .ui
file is also tweaked in this commit a bit):
* start Writer
* "Insert" -> "Chart"
* click on a bar in the chart
* switch to the "Properties" sidebar deck
* in the "Colors" section, click on the arrow
of the button to open the popup
This commit also prepares for supporting the
dialog mentioned above with native Qt widgets
in an upcoming commit.
Change-Id: Ibf1cb597bc93f29033ab76432ca08af0b029cc0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204209
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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
So far, ChartColorPalettes was (ab)using the weld::IconView
tooltip handler to detect when mouse hovering over one of the
palettes happens. Stop doing so, and instead use the simple
mouse move event handler directly.
The API introduced in
commit 0e323f194b
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Dec 18 21:26:41 2025 +0100
tdf#168594 weld: Add IconView::get_item_at_rect
can be used in there to determine the currently
hovered over item.
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: I711c600b80703c118ba3b5940084e3feb41903b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203409
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
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>
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>
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>
This adds ComplexColor to many of the color properties that are
available in charts. It also handles some import code in oox, so
the complex colors are set correctly to the chart elements if an
OOXML document is loaded. This doesn't yet handle export and if
a theme is changed, as well if a color is changed manually in
the chart.
Change the tests so they now assert the scheme color like it is
defined in the source document and not the calculated derived
color.
In addition change the WriteRunProperties to have a struct as
an input instead a number of parameters, which in most cases don't
need to be filled out and are using the default value.
This was needed for the new parameter bUseTextSchemeColors, which
is used for charts, so the text colors use tx1 and tx2 elements
instead dk1 and dk2, which are usually used in Impress.
Change-Id: Iaebbaea983c5232c51233c1a02bd8fe1da24d551
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194939
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
commit a26c93a630
Date: Sun Aug 10 22:33:37 2025 +0200
chart color palettes: switch from drawingarea to IconView
had switched to using weld::IconView for the color
palettes and added setting a text, "Palette <number>"
for each of the palettes. The text was only displayed
for the VCL/non-gtk implementation, however.
Showing the text for gtk3 as well could be implemented
by adding a corresponding model column (see implementation
in earlier change set 1 of this Gerrit change, [1])
As Marco Cecchetti mentions in [2]:
> Anyway, I think more appropriate to remove the name
> in both cases since it's not descriptive and especially
> in the sidebar case it ends up just wasting space.
> Maybe you could set only for the a11y description.
Previous commit
Change-Id: I641afe5b54055e91048fec111751f0ba3dafbea0
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Aug 29 13:43:40 2025 +0200
a11y: Set a11y name for chart color palettes
implemented explicitly setting the a11y name to the
string that was previously set as the display text,
so the VCL fallback to use the display text for the
a11y name is no longer needed.
Therefore, drop the displayed text as suggested.
Sample steps to see the corresponding dialog page:
* start Writer
* click the "Insert Chart" toolbar item to insert
a chart
* double-click on a bar in the chart
* switch to the "Color Palette" tab page
[1] https://gerrit.libreoffice.org/c/core/+/190367/1
[2] https://gerrit.libreoffice.org/c/core/+/190367/comments/d4b582df_0cc820cc
Change-Id: I5242219df6049ce8b6e99148d30cc9ea95485658
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190367
Tested-by: Jenkins
Reviewed-by: Marco Cecchetti <marco.cecchetti@collabora.com>
commit a26c93a630
Date: Sun Aug 10 22:33:37 2025 +0200
chart color palettes: switch from drawingarea to IconView
had switched to using weld::IconView for the color
palettes.
Other than for the vcl IconView implementation, the gtk3
one does not use an item text for the accessible name
if no a11y name is explicitly set (even if an item text
were set, which is currently not the case for gtk3),
resulting in the Orca screen reader only announcing "icon"
when an item receives focus.
Explicitly set the accessible name for each item to the
same as the text set for the VCL variant to ensure an
a11y name is always set.
This now makes Orca e.g. announce "Palette 1, icon" when
that palette/item receives focus when using the gtk3
VCL plugin.
Sample steps to see the corresponding dialog page:
* start Writer
* click the "Insert Chart" toolbar item to insert
a chart
* double-click on a bar in the chart
* switch to the "Color Palette" tab page
Change-Id: I641afe5b54055e91048fec111751f0ba3dafbea0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190368
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
and
cid#1659699 Overflowed return value
cid#1659759 Overflowed return value
cid#1659922 Overflowed return value
cid#1660190 Overflowed return value
cid#1660286 Overflowed return value
cid#1660457 Overflowed return value
Change-Id: Ie9fffe4994b10ed3d4feb14eaf7950e3f01714ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189927
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
in spreadsheet related code, similar to runtime cases of
bin/sanitize-excludelist.txt but probably more dubious.
also:
cid#1660554 Division or modulo by float zero
cid#1660545 Division or modulo by float zero
cid#1660527 Division or modulo by float zero
cid#1660501 Division or modulo by float zero
cid#1660485 Division or modulo by float zero
cid#1660442 Division or modulo by float zero
cid#1660396 Division or modulo by float zero
cid#1660241 Division or modulo by float zero
cid#1660134 Division or modulo by float zero
cid#1660066 Division or modulo by float zero
cid#1659994 Division or modulo by float zero
cid#1659979 Division or modulo by float zero
cid#1659964 Division or modulo by float zero
cid#1659940 Division or modulo by float zero
cid#1659913 Division or modulo by float zero
cid#1659893 Division or modulo by float zero
cid#1659890 Division or modulo by float zero
cid#1659868 Division or modulo by float zero
cid#1659745 Division or modulo by float zero
cid#1659721 Division or modulo by float zero
cid#1659711 Division or modulo by float zero
cid#1659611 Division or modulo by float zero
cid#1659814 Division or modulo by float zero
Change-Id: I29830cad3170e5e45348f7bd4e08f028d21a4543
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189823
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1659754 Variable copied when it could be moved
cid#1659755 Variable copied when it could be moved
cid#1659756 Variable copied when it could be moved
cid#1659766 Variable copied when it could be moved
cid#1659767 Variable copied when it could be moved
cid#1659769 Variable copied when it could be moved
cid#1659770 Variable copied when it could be moved
cid#1659777 Variable copied when it could be moved
cid#1659787 Variable copied when it could be moved
cid#1659790 Variable copied when it could be moved
cid#1659793 Variable copied when it could be moved
cid#1659802 Variable copied when it could be moved
cid#1659818 Variable copied when it could be moved
cid#1659822 Variable copied when it could be moved
cid#1659824 Variable copied when it could be moved
cid#1659825 Variable copied when it could be moved
cid#1659826 Variable copied when it could be moved
cid#1659842 Variable copied when it could be moved
cid#1659849 Variable copied when it could be moved
cid#1659850 Variable copied when it could be moved
Change-Id: I70729aaf6e229518a9a50ac18311286ab5b05b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189348
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
This is a subtask of tdf#165742: Chartex charts are lost on input from OOXML
and re-export.
Build out the narrowest parsing path down to ChartType for funnel charts.
No other data or parameters are supported at this point other than the
chart type. This is a step towards more extensive support for I/O of chartex
charts to/from OOXML.
Change-Id: If33f4320c373262de19a7b0b31d28ce8f1de29e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183463
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This moves isSupported* function from ChartTypeHelper to ChartType
where it better belongs to. We can access the concrete classes now
instead of accessing through UNO si this is possible to do.
Change-Id: Icc52a8ba0d8ab6d5907d7942a1834cc6f7093cce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182712
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Andrea Gelmini