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
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>
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>
If the selected range is too small when Insert->Chart is used then most
of the controls in the “Data Series” tab are disabled. Additionally,
nothing was updating the “Range for %VALUETYPE” label defined in the UI
file so it would be left with this stub visible in the UI. This patch
makes the default label instead just be “Range”. The previous string is
now defined in strings.hrc instead of reading from the label value when
creating the dialog so that it can be updated when a valid range is
selected.
Change-Id: Ib926383825f32042dc0c6d33a115d139a50c5aa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211102
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
A correlation circle plot reads the ends of its range differently from every
other chart type: the last two columns are the dimensions its points are placed
against and the columns before them are the features. One range holds the lot,
so nothing about the entry gives that away, and a reader who does not already
know it has no way to work it out.
Display a information label under the range input saying the last two
columns of it are component dimensions and the columns before that are
features.
Change-Id: Ib7d27aad189f12be188f61b1fc317dd1e718b803
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8105
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 2cbf62e18df956ed23c77932cd5e38424e7baa1f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210470
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The entry sits next to the bubble chart, under the same switch that keeps the
chart types wanting free x values out of the list where they do not belong. It
has one sub type, no three dimensional look and no stacking.
The two images are placeholders: a circle with a cross and a few arrows
out of the middle. They need a designer's hand before this ships.
A test drives the wizard the way a user would: it picks the type, types one
range whose last two columns hold the dimensions, and checks that every column
before them became a series holding that column beside the two dimension
columns. A second test reopens the ranges of that chart and checks the range
comes back as it was given.
Change-Id: If8b5275244a2456a22235a6ce2d3d51fcff6cb94
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8104
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 7a7fc603047e065ebbc20f8bc5dc814d6079e082)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210469
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
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
RangeSelectionListenerParent::enableRangeChoosing both sets the
dialog's visibility and modality. So far, it was first setting
the modality and then the visibility.
However, changing the modality while the dialog is shown
doesn't work as expected when using the qt6 vcl plugin
with native Qt widgets with upcoming commit
Change-Id: I53cbd9061ef473deba2124f17976f24b11c1712a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 22 17:27:01 2026 +0200
tdf#130857 qt weld: Support chart "Data Ranges" dialog
in place and would result in an inability to select the
data area as the main window would remain insensitive/disabled
for the following case:
* start Calc
* "Insert" -> "Chart"
* confirm with "Finish"
* with chart still selected, press the context menu key
(or click with right mouse button) to open the context menu
* select the "Data Ranges..." context menu entry
* in the "Data Range" tab, press the "Select data range" button
* try to click into the document and drag to make a selection
The native Qt implementation wouldn't require changing
modality back and forth, but gtk3 and the gen vcl plugin
would show the same problem as described above when not
setting the dialog to non-modal in the case it gets hidden.
Make all of them work by setting the modality, but always
doing that while the dialog is hidden (not shown), i.e.
either before showing it or after hiding it.
Change-Id: Ia368a919c497d51c4560536995e90f60e3b85768
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208493
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the weld::Entry and weld::TextView handlers
that are called when the text changes due to user
interaction to pass a weld::TextWidget& param
instead of a weld::Entry& and weld::TextView&
one respectively.
Adjust related methods across the code base accordingly.
This unifies the behavior for both of these
weld::TextWidget subclasses and prepares for
deduplicating the logic and moving it to the
common base class in an upcoming commit.
That will also ensure they stay in sync.
(Change also motivated by the fact that their behavior was
differing before
Change-Id: I03d2a13cd84d53d806eb9e363f49c4b6be28d938
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 9 13:08:58 2026 +0200
tdf#130857 weld: Don't signal about programmatic TextView text change
.)
Change-Id: I5572fc88caf577fae9a23a39f1ec4f2179935a99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses,
as well as a few helpers.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when anything in weld.hxx
changes.
Move the weld::toId and weld::fromId helpers from
weld.hxx to weldutils.hxx, in preparation of getting
rid of weld.hxx altogether in an upcomcing commit.
Change-Id: I408fe20a74ff104cbfe07bde3105317a1922ff61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This makes it easier to keep an overview and reduces
what needs to be recompiled if the class changes in
the future.
Change-Id: Ie8d0aad9bca3e990f78d4ffc006a04b0a8086fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205935
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.
Add missing includes/forward declarations in places
previously depending on transitive includes that
are now dropped.
Change-Id: I3215b358e0fa45ffce08756218c386e1a4d7ebc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205928
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
These are not needed inside weld.hxx itself. Instead
add the required includes/forward-declarations to those
files actually needing them, instead of relying on the
now dropped ones.
Change-Id: I5e4cea030867d14057b2bdcc2a2a4cd98843651d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205906
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: I34876c5bef75e30e758029b0fe5afeecc92d509d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205903
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class definition and implementation out of weld.hxx
and weldutils.cxx 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: I97768bf75dac492e32e1d387853d123481aa643a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205902
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.
Adjust includes in files that were implicitly depending
on transitive includes that are no longer present because
the more specific include/weld/Container.hxx is included
further down now instead of include/weld/weld.hxx.
Change-Id: I04e6bb72ce446b746dfdf88b45c7df9d0ccda473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205899
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: Ide86f35543468a88288a068cc9f89eaf381ac52f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205763
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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>
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: I0cc1e0f3aa60d3457af0f0f30ec8fe74cb5ce6a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205489
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: Ia7bc570fcd463d9adcbcdad070250cec5bc3b949
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205488
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: I2e42a2992c08311922451bb01062683bd81954fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205486
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: I2eb564b2483b052f01d4af55fd4feb00b5ed6031
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205472
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: If7cb4403f1861c465f44a1cae4065b0bf8dfad48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205323
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The crash occurs in getCurrentTemplate() when xTemplateManager is null
and xTemplateManager->createTemplate() dereferences it at address 0x40
(the offset of m_xContext within the ChartTypeManager object).
The ChartTypeManager can be null in two scenarios:
1. The ChartModel copy constructor has never initialized
m_xChartTypeManager - even before commit aa06241b9c (2022,
"use more concrete types in chart2, ChartTypeManager"), the old
CreateRefClone returned null because ChartTypeManager does not
implement XCloneable.
2. More importantly for this crash: the ChartModel may have been
disposed (which clears m_xChartTypeManager) while the chart type
wizard dialog is still active. In the LOK/COOL async dialog
environment, rapid InsertObjectChart commands can race, disposing
the first chart's model while its wizard still holds a reference.
Add a null guard on xTemplateManager before dereferencing. The caller
commitToModel() already handles a null return from getCurrentTemplate()
via its if(!xTemplate.is()) return check.
Change-Id: I3f8e8e91a4d77c12a3c05a5e09b12a4a9e028f65
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/942
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1444
Reviewed-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 77f8b95d0af914f54a42206e567a50f09bee0f67)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204806
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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
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/[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>
Michael Weghorn