Make getSystemDependantDataInternal (with "a") in
getSystemDependentDataInternal (with "e") to have it
coherent with addOrReplaceSystemDependentDataInternal and the class
addOrReplaceSystemDependentDataInternal
Change-Id: Id56d54c0981752f09387d43a3eb33fab81ccd5c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209484
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Library_simplecanvas contains the SimpleCanvasImpl
class, which implements the XSimpleCanvas UNO interface
and is the implementation for the
"com.sun.star.rendering.SimpleCanvas" service,
defined in the component file.
However, none of these are actually used anywhere.
Therefore, drop the simplecanvas library altogether.
Change-Id: I301b3a42dfb6eacf6a9ef3a4851ed1d38f16ec66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208852
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
as seen e.g. at
> In file included from engine/cppuhelper/source/defaultbootstrap.cxx:27:
> In file included from engine/cppuhelper/source/servicemanager.hxx:35:
> In file included from engine/external/boost/include/boost/container/small_vector.hpp:31:
> In file included from engine/workdir/UnpackedTarball/boost/boost/container/small_vector.hpp:27:
> In file included from engine/workdir/UnpackedTarball/boost/boost/container/vector.hpp:61:
> In file included from engine/workdir/UnpackedTarball/boost/boost/move/algo/adaptive_merge.hpp:16:
> engine/workdir/UnpackedTarball/boost/boost/move/algo/detail/adaptive_sort_merge.hpp:261:17: error: unused function template 'needed_keys_count' [-Werror,-Wunused-template]
> 261 | static SizeType needed_keys_count(SizeType n_block_a, SizeType n_block_b)
> | ^~~~~~~~~~~~~~~~~
and
> In file included from engine/vcl/source/outdev/eps.cxx:22:
> In file included from engine/include/vcl/metaact.hxx:45:
> In file included from engine/workdir/UnpackedTarball/boost/boost/container/vector.hpp:61:
> In file included from engine/workdir/UnpackedTarball/boost/boost/move/algo/adaptive_merge.hpp:16:
> engine/workdir/UnpackedTarball/boost/boost/move/algo/detail/adaptive_sort_merge.hpp:261:17: error: unused function template 'needed_keys_count' [-Werror,-Wunused-template]
> 261 | static SizeType needed_keys_count(SizeType n_block_a, SizeType n_block_b)
> | ^~~~~~~~~~~~~~~~~
Signed-off-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Change-Id: I1c81650c82df717317846769ea3ac016d9a14652
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7281
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit fd3a8cc0417525806d45522fc6752c6678b2d433)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208736
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Relocate the whole solver component out of the standalone sccomp module
and into sc. This moves the SolverComponent base class, the CoinMP and
Swarm solvers, the differential evolution and particle swarm headers, the
UNO service registration, the scc string resource, and the two unit tests.
The now-empty sccomp module is removed.
The solvers are Calc specific. Moving them inside sc is the first step
toward letting them work directly with ScDocument, and eventually clone a
document or its sheets so trial calculations can run in parallel. That
direct access is only possible from inside sc, so the relocation has to
come first.
This is a pure relocation with no behaviour change. The translation domain
stays "scc" and its polocation still points at "sccomp", so the existing
translations keep loading unchanged. Re-homing the scc translation domain
into sc is left as a follow-up.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I5b972daae4c51f04ca394fc9a92f89ac0c4dd599
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3832
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 7f1bea8723761f97c053f2e7e46aab7081b1bb21)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208080
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The Lpsolve solver and the CoinMP solver are both used for the same
thing: a linear model, with optional integer variables by branch
and bound. CoinMP (CLP plus CBC) is the more capable and better
maintained of the two, so the lp_solve one adds a second bundled
dependency and a parallel copy of the solver code for no capability
the other lacks.
Remove the LpsolveSolver component, the bundled lp_solve external
(and its colamd dependency, which only lp_solve used), and all the
build, configure, packaging and license references to them.
A document may still name com.sun.star.comp.Calc.LpsolveSolver as
its engine. SolverSettings now reads that name as the CoinMP
solver, which solves the same model, so such documents keep
working.
The Calc solver test that exercised the engine now uses CoinMP. Its
knapsack model has a single optimal total value of 6987, which fills
the weight capacity of 1000 exactly and which CoinMP finds. The
lp_solve run had returned a suboptimal 6981, so the test now expects
the true optimum.
The build setup changes only take effect after re-running autogen.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia14d8c491779873da6b0157aa524056275adf8f5
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3810
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e77738a7ca7d44fd9d1f852e26d46e3a6d60467b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208038
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Add a check to the UI rules enforcer that checks that
no column (GtkTreeViewColumn) contains multiple
renderers of the same type, e.g. no 2 GtkCellRendererToggle.
This wouldn't work at least with the qt weld implementation
as that one maps the different types of renderers to a
role, but setting/displaying multiple different values for the
same role in the same column isn't possible.
All previously detected occurences (that had dummy
columns for other reasons) were addressed in previous
commits, so there is currently no such issue left.
Adding the check can help to identify/avoid new
issues in the future.
Change-Id: I637e50477ce41a7ceca8f9cf5830e383b5393c69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207309
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The ui-rules-enforcer check newly introduded in earlier commit
commit e6b2af1cf8
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 19 08:58:59 2026 +0200
tdf#130857 ui-rules-enforcer: Check that special toggle renderer not by itself
was used to identify cases where the first GtkTreeViewColumn
in a GtkTreeView in a .ui file only contained a
single GtkCellRendererToggle and no other renderers.
Quoting from the commit message:
> If the special toggle renderer is used in the first
> column, the next "real" renderer still uses column index 0
> in the weld API.
> That makes sense if the renderer is actually
> in the first column still, but is rather
> non-obvious/confusing if that's not the case.
> (The GtkInstanceTreeView ctor currently unconditionally
> considers a GtkCellRendererToggle to be a special
> expander column when it is the first renderer in
> the first column, regardless of whether more
> renderers are there or not.)
> Ensure that the special toggle renderer
> is not in a column by itself, but accompanied
> by at least another renderer by adding a corresponding
> check to the ui-rules-enforcer.
>
> Since the special toggle button is to toggle an
> entry on/off, it also makes sense if it is in the
> same column as the icon or text that it enables/disables.
> If the purpose is to be for a whole row and the check
> button should be in its own column, then it would in my opinion
> make more sense to also use a regular column index of 0 instead
> of the "expander toggle column" feature. Allowing to do that
> would require more rework (as it would break the
> current assumption/logic in the GtkInstanceTreeView ctor
> as described above). If there are any cases where it
> makes sense to have the renderer in its own column
> by itself, supporting that use case with a column
> index of 0 (instead of the current -1) should be easier to
> implement in the future once all cases where different columns
> don't make sense have been handled first. (Then, the logic
> in the GtkInstanceTreeView ctor can be adjusted without
> breaking those.)
All occurences that this new rule has found were
already addressed, i.e. there is currently no
case where the first column contains only a GtkCellRendererToggle.
Prepare for/take the next step: Allowing to use a colum only
containing a single GtkCellRendererToggle again, but then accessing
it using a regular column index of 0 instead of the special
column index of -1, as already outlined as a potential way forward
in that earlier commit.
(This way, column index 0 will be used for the first column,
column index 1 will be used for the second column, etc. which
is reasonably straightforward and doesn't break the
corresponding assumption in the qt weld implementation
any more).
To do so, adjust the logic in the GtkInstanceTreeView
ctor to only enable the special toggle column feature if
a GtkCellRendererToggle is the first renderer in the
first column *and* it is followed by another cell renderer
for the actual content (that is accessible by column index 0
in the weld API).
This also matches what is already checked for the special
pixbuf "expander" column, see the
else if (GTK_IS_CELL_RENDERER_PIXBUF(pCellRenderer))
just below the modified line.
Drop the new ui-rules-enforcer rule introduced by the above-mentioned
e6b2af1cf8 again as
a first column only containing a toggle button is now
valid with the new semantics.
Extend the weld::TreeView::enable_toggle_buttons
doc a bit to make clear the requirements on the
definition in the .ui file.
This will be used in upcoming commits to simplify/streamline
existing UI like the one in the Java options page
(SvxJavaOptionsPage) where the .ui file
(cui/uiconfig/ui/optadvancedpage.ui) contains
two toggle renderers in the first column, but only
one of them is actually used and the implementation
in SvxJavaOptionsPage only makes use of column indices
-1 (for the special toggle column), 1 (for the "Vendor"
column) and 2 (for the "Version" column) and the
other renderer is not used in practice.
Presumably, the special toggle button feature was only
used because using it was mandatory in the past to be
able to use radio buttons at all.
That is no longer the case since
Change-Id: I098feb474162d61c5452c3496293a420118e2f4f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 24 15:42:40 2026 +0200
tdf#130857 weld: Have separate method to set treeview toggle button type
, so move forward with the intention to make the whole
mapping between cell renderers in the .ui file, columns
in the .ui file and column indices in the weld API
more straightforward/less confusing
(e.g. by being able to drop renderers in the .ui file
that have no actual equivalent in the implementation
of the UI using the treeview).
Change-Id: Ic5bbe4ab71ba255ba16bb0a9176ee4c3a8827fe8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207254
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As the weld::TreeView doc says, two special "expander" columns
for toggle buttons and images can be used that can be accessed
by index -1 in the weld::TreeView API:
/* Model column indexes are considered to begin at 0, but with special columns
before index 0. A expander image column (and an additional optional toggle
button column when enable_toggle_buttons is used). Column index -1 is
reserved to access those columns.
*/
class VCL_DLLPUBLIC TreeView : virtual public ItemView
While the vcl implementation in SalInstanceTreeView doesn't
currently take into account the .ui file at all, the gtk3
vcl implementation (GtkInstanceTreeView) does and the
native Qt implementation in QtInstanceTreeView also does.
If the special toggle renderer is used in the first
column, the next "real" renderer still uses column index 0
in the weld API.
That makes sense if the renderer is actually
in the first column still, but is rather
non-obvious/confusing if that's not the case.
(The GtkInstanceTreeView ctor currently unconditionally
considers a GtkCellRendererToggle to be a special
expander column when it is the first renderer in
the first column, regardless of whether more
renderers are there or not.)
Ensure that the special toggle renderer
is not in a column by itself, but accompanied
by at least another renderer by adding a corresponding
check to the ui-rules-enforcer.
Since the special toggle button is to toggle an
entry on/off, it also makes sense if it is in the
same column as the icon or text that it enables/disables.
If the purpose is to be for a whole row and the check
button should be in its own column, then it would in my opinion
make more sense to also use a regular column index of 0 instead
of the "expander toggle column" feature. Allowing to do that
would require more rework (as it would break the
current assumption/logic in the GtkInstanceTreeView ctor
as described above). If there are any cases where it
makes sense to have the renderer in its own column
by itself, supporting that use case with a column
index of 0 (instead of the current -1) should be easier to
implement in the future once all cases where different columns
don't make sense have been handled first. (Then, the logic
in the GtkInstanceTreeView ctor can be adjusted without
breaking those.)
Having the special column renderer in its own column
but still using a column index of 0 for the text that
is then supposed to be in actual column 1 doesn't
play well with the qt6 vcl plugin with native widgets
used (SAL_VCL_QT_USE_WELDED_WIDGETS=1), as that one uses
the actual columns as defined in the .ui file
(and corresponding column indices of 0 for the first
column, 1 for the next column,...) to set/retrieve conent
other than the "special expander columns".
As a consequence, e.g. the Calc "Protect Sheet"
dialog (start Calc, right-click on a tab, select
"Protect Sheet..." menu entry) would show both, the checkbox
and the text in column 0, and column 1 would just be empty
(but still consume space, i.e. make the dialog look
a bit odd). That was fixed in previous commit
commit 9bfbc7d139
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Jun 19 09:21:36 2026 +0200
tdf#130857 sc: Merge checkbox and text column in "Protect Sheet" dialog
and all other occurences identified by the
new rule introduced with this commit were also addressed
in similar commits.
(`git log --grep=Ib596c39698d308e18e9ede27c239cd44e43863a9`
can be used to see them.)
Given the rule newly added to the ui-rules-enforcer
was already used to detect any existing cases
and they were adjusted in the meantime, it currently
doesn't find any issues, but can be used to detect/avoid
any new ones from being introduced - and/or to prepare
for a further rework that can rely on the fact that
all "expander toggle columns" are by now no longer
in the first column by themselves.
Change-Id: Ib596c39698d308e18e9ede27c239cd44e43863a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207050
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As the weld::TreeView doc says, two special expander columns
for toggle buttons and images can be used that can be accessed
by index -1 in the weld::TreeView API:
/* Model column indexes are considered to begin at 0, but with special columns
before index 0. A expander image column (and an additional optional toggle
button column when enable_toggle_buttons is used). Column index -1 is
reserved to access those columns.
*/
class VCL_DLLPUBLIC TreeView : virtual public ItemView
While the vcl implementation in SalInstanceTreeView doesn't
currently take into account the .ui file at all, the gtk3
vcl implementation (GtkInstanceTreeView) does (and the
native Qt implementation in QtInstanceTreeView also does).
The vcl implementation always shows the toggle button/column
before the image/pixbuf one.
(See e.g. how SvTreeListBox::SetTabs calls
AddTab( nStartPos, TABFLAGS_CHECKBTN );
before
AddTab(nStartPos, TABFLAGS_CONTEXTBMP);
and how SalInstanceTreeView::do_insert also first
inserts an item if the SvTreeFlags::CHKBTN flag
is set before inserting a SvLBoxContextBmp for the
special bitmap/expander column.)
For consistency with the vcl implementation,
make sure the toggle renderer also comes first
in .ui files, which means it will be rendered
first when using gtk3 as well.
Ensure that by adding a rule to ui-rules-enforcer.
The two issues that the new rule detected were
already addressed in previous commits
Change-Id: I3a959d71cd91d5bfc20ba8abe50a3c7b1c189df3
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jun 18 17:58:49 2026 +0200
tdf#130857 dbaccess: Have special toggle before pixbuf col in dbtreelist.ui
and
Change-Id: Ie1bd0a96a79a9818f3aa573edb29e76363dbfe44
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jun 18 18:24:34 2026 +0200
tdf#130857 dbaccess: Show checkbox in front of icon in "Tables Filter" dlg
, so running
$ for a in `git ls-files "*.ui"`; do bin/ui-rules-enforcer.py $a; done
doesn't detect any additional issues right now, but can be used
to avoid/detect new issues in the future.
Change-Id: I1f7c8c6456ed2e8ba4d8018d69fb12b40204536a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206986
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The logic was relevant for Collabora Online/jsdialog,
but Collabora Online no longer uses this repo and
jsdialog support was dropped in
commit 8a91868e21
Date: Tue Jun 2 14:53:19 2026 +0200
drop JSDialog machinery
This was (also) used in the dumpState function in
vcl/source/app/lok.cxx for debugging purposes
when using LibreOfficeKit to dump more information
about the vcl::Window hierarchy. Drop the call to
it there, but leave dumping other information
in place there.
Change-Id: I8033516ecdf21f2c1b3a498774ef8ba54a91fdc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206012
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
wsl-as-helper case uses a post-script for AC_CONFIG_FILES for
config_host.mk to replace wsl-style paths in the form of
/mnt/<driveletter>/ to <driveletter>:/ for use by the build in the
windows-realm.
For variables that are used in the other generated files, the paths
needs to be converted explicitly/manually
this change partially undoes 9add004456
There's no need for a TARFILE_LOCATION_NATIVE / the build already uses
the native form, it was just another case of the replacement only being
done for the config_host.mk, not in the generated scripts.
(since configure runs in the linux realm, it needs the unix-style paths
as seen from within wsl, the actual build is then run in the windows
realm and uses windows paths (in mixed-form, i.e. forward slashes))
Change-Id: I5252ed134b0a338cf8812ad4c84022b5b43daf32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201297
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
And not truncate it to an integer value.
Add additional overload for attribute that takes an enumerated type, otherwise
the compiler will complain about ambiguous conversion because it cannot
choose between the attribute that takes a integral value and the one that
takes a double value.
Change-Id: I9eae22817ec3b26da7b9468d1c8b5e6f3e900538
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201193
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
...instead of using the default -static-libsan, where dynamic libraries must be
built without -z defs and where all executables must link against the static
libsan. Dropping the latter requirement means that we no longer need the static
sal hack in Library_jpipe.
But instead, at runtime, when a process loads any library that links against the
dynamic libsan, then that dynamic libsan must be loaded first into the process.
For executables that are themselves linked against the dynamic libsan, that is
already the case. For scenarios where we invoke a Java executable, we now use
LD_PRELOAD to fulfil that requirement. (And for invocation of Python
executables, this commit assumes a --enable-python=fully-internal configuration,
so that executable will be itself linked against the dynamic libsan.)
Dropping the requirement to build without -z defs revealed that using
-fsanitize=vptr often requires RTTI symbols from libraries that are not usually
linked against. Such cases are now handled by conditionally including those
libraries in gb_*_use_libraries calls. (This could be restricted even further
to only be done under -shared-libsan, but it arguably doesn't hurt to also do it
under the default -static-libsan.)
The expectation is that -shared-libsan will explicitly be passed into the
configuration along with any other -fsanitize... arguments via
--with-extra-cc-flags and --with-extra-cxx-flags. This commit does not yet
remove the code that is only needed for the (default) -static-libsan caes, but
that code could eventually be cleaned up, once all (Clang) builds using
sanitizers use -shared-libsan. (GCC already defaults to a shared model.
Instead of a combined -shared-libsan, it has individual -shared-libasan etc.,
though. This commit does not intend to make any changes to any potential GCC
sanitizer builds; my assumption is that we do not have any such, and that they
wouldn't work out of the box, neither before nor after this change.)
Change-Id: I932e4b75c299c158211e122adf33d7988892a87e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200935
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Use raw strings for regex patterns with escape sequences in
bin/checkExternalLibraries.py and bin/crashreportScraper.py to fix
SyntaxWarning for invalid escape sequences. Remove unused exception
variable in solenv/bin/hrcex and solenv/bin/uiex.
Change-Id: Ib43ed0705e52abfcae646236364c8bffd8e7d583
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198943
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
only in headersfwd mode.
This check ran in --headers mode as well, giving contradicting advice
compared to headersfwd mode.
Apply the check only in headersfwd mode for consistency
Change-Id: Icf58bbb6c47d0a736c2da5d253fe292d6e58a427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199381
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
spotted while rechecking include/toolkit, some hpp headers are now
not suggested to be replaced by fw declarations incorrectly,
but to be replaced by their matching hdl files.
There is already a rule to skip these automatically, no need to keep such
in exception files
Change-Id: I5df654a9bca3aaaecb4dce444264a6464ca8f3b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198277
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Spotted with include/i18nlangtag/languagetagicu.hxx:
iwyu wants to replace unicode/locid.h with namespace icu_78 { class Locale; }
but this is super fragile
Now this works for both this and the older example:
bin/find-unneeded-includes --headersfwd i18npool/inc/breakiterator_unicode.hxx include/i18nlangtag/languagetagicu.hxx
should give no suggestions
Change-Id: I7d534f106f45bf78f768abbb9d57389c7f413d74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198234
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Up to now with lots of effort ModelData was held at the
svx::diagram::Point to keep a stripped version of Text and
TextAttributes and also a selective (not complete!)
key/value list of attributes for each shape itself
(fill/line/text/...).
These had to be moved to/rescued from oox::Shape that is
used as helper at import to that model after import, set again
at the oox::Shapes when XShapes had to be re-created, you name
it - very complicated and error-prone, and never complete
by definition.
Nonetheless data in OOXML MSO format, so pretty easy to re-
export if necessary /that's what I was looking at last
changes).
That also meant that all changes done to an XShape/SdrObject
*had* to be somehow transfered to that diagram model data,
too. We have no converters for that at all, target would
be data representation as in OOXML files.
What we *have* is import to our model using oox::Shapes and
ccreating XShapes/SdrObjects, and export XShapes snippets
'direct' to MSO ooxml formats.
Thus I thought about to use what we have, for the cost to
split the model: the DiagramModel *has* to be kept to be
able to re-create the Diagram on structural changes, that
is needed. But the attribute & text data can stay at the
associated XShapes that need to exist and get created
anyways.
That needs reliable identification of the XShapes
belonging to the model. It requires to load that Diagram
initially, using the oox::Shapes which have the complete
attribute model data to create the XShapes.
Remember that there is a 2nd import, from the
ReplacementGraphic which (may) be contained in the MSO
file.
From that moment on changes on those XShapes will be
diagram model changes if attributes get changed.
But they will not need to forward changes to the
DiagramModel in another format.
When re-layouting it means to copy that data from old
XShape to new XShape, before these get deleted. There
may be new XShapes that need to be initialized, too.
For export this means that part of that export will have
to use the XShapes as model data as needed.
This also means that the quality of im/export of
Diagrams will in the future rely on the quality of our
existing im/export snippets for XShape/oox::Shape/oox.
These are developed and in use for a while now and
should have reached a good quality. If we have to
improve these that will always improve im/export
and Diagram stuff then, too.
This change does that big change and looks promising,
doing what it is intended to do. I still have to
experiment, so in master it is still deactivated due
to being too dangerous yet, see last SmartArt change
and mention of ACTIVATE_RECREATE_DIAGRAM_DATADOMS and
it's description.
Change-Id: Ife1591b0d3c8974d90a1004d94f3e6799be85a56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198221
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The DiagramModel uses 4 mandatory and three optional XMLDoms
for it's data. These get imported, but to get to a roundtrip
we will need to be able to create & save these again.
Last changes prepared this by deleting XMLDoms which were no
longer valid dependent of changes done to that DiagramModel.
When exporting the availability of these gets checked and if
all are there, it gets exported as Diagram (in MSO format,
not yet in ODF). If nothing was changed the original Doms
get exported - untouched.
That test will now try - if e.g. the most important XMLDom
OOXData is missing - to re-create this in that action. The 1st
one which I now implemented that is the OOXData which homes
the Point/Connections/BGFill data (and some more).
Due to this needing testing I for now encapsulated this
to a EnvVar called ACTIVATE_RECREATE_DIAGRAM_DATADOMS, so
this will for now only happen when this is set. Anyways all
that stuff is still behind the 'experimental features' wall.
This is and stays experimental for now.
These are already deep changes which need to get tested and
get to master, opening the path to experiment with it and
refine it. Due to the EnvVar gate no real changes should
happen in master, but due to the changes around it this
will need to be checked this way.
Change-Id: Iabba69b19387e45f1028843a25f3bae1fc4f8fe8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197676
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Add several paths to skip checking under Linux
This is preparation to integrate this script into CI,
so that it does not report error on headers that are
entirely Win/Mac/IOS/Android/... specific.
Change-Id: Ia1493b57e0e7eef70770d4a5b4b634dd82611c05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196632
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
- filter out two modules without relevant files
- search for files in include not in path/file.h
format, but only as file.h as seen with basctl/basctldllapi.h
Change-Id: I42192cc6d923132778ad46271c725bd7049b1bb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193423
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tested-by: Jenkins
- give warning if a header is skipped because it contains #if defs
- give an option to still check those (together with --noexclude)
Change-Id: I9e878b213300a53b6236325f2bafb280f8b0290f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196396
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tested-by: Jenkins
Also add text=True for good output - previously, this did not work at all
(it let include/vcl/BitmapTools.hxx checked, see it in subsequent patch)
Previously this check was placed a bit incorrectly, which made
it run only if both --headersfwd and --recursive was provided
Now it runs with simple glob patterns too, such as:
bin/find-unneeded-includes --headersfwd include/vcl/[A-Z]*
Change-Id: Ib8a5209bac553a74137e3a4ac6fdf88319b03982
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196234
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tested-by: Jenkins
There is definitely a better fix for this, we should not need two
different bitmaps and masking and stuff, but this will fix the problem for now.
Mostly revert the following commits:
commit 7278030b92
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Sep 15 16:26:25 2025 +0200
remove unused DrawModeFlags
commit 581c52dad2
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Sep 10 15:08:04 2025 +0200
BitmapAlphaClampFilter is dead since
commit e7b460f919
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sat Aug 30 15:23:11 2025 +0200
BitmapEx->Bitmap in canvas
Change-Id: Ic5747ce6143a8320f977111c7635bf736a9996d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193873
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Andrea Gelmini