And drop EPosition, which duplicates EPaM, except for its default
ctor (used in a single place).
Change-Id: I48bb6dafcba84465d61579df0ec71b815945532a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177075
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
reduce cost of OUString construction by avoiding
initialising a temporary and then overwriting it.
12s to 10s
Change-Id: I889152ba71947004ca7d5c96f073182c94d95ed5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175539
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and for the duration of Threaded calculation where there will be
no new formats required we can drive number formatting with the
unlocked RO policy.
Change-Id: Ic0e449acdcf834bc569d13b4a984f13c55316801
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165160
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
I checked if this is used, but it can be replaced
using Clear() -> all. This prevents that the whole
array of Items in an ItemSet gets set to
INVALID_POOL_ITEM.
I also checked if INVALID_POOL_ITEM/IsInvalidItem
is needed at all representing SfxItemState::DONTCARE
but it is and still will need to be set for individual
Items.
At last checked if SfxItemState::UNKNOWN and
::DISABLED really need to be separate states, but
indeed there are some rare cases that need that.
To make things more consistent I also renamed
SfxItemState::DONTCARE to SfxItemState::INVALID
to better match Set/IsInvalid calls at ItemSet.
The build showed a missing UT and led to a problem
due to the hand-made ItemSet-like SearchAttrItemList.
The state 'invalid' seems to be used as 'unused'
marker. It should be changed to use SfxPoolItemHolder
and not need that. For now, set by using an own loop
to set to that state.
Change-Id: Ifc51aad60570569a1e37d3084a5e307eed47d06c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165035
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Driving forward the Item reworks I now take the
ItemPool in focus: It now does not hold any items
anymore and should be renamed to something like
ItemInfoProvider/ItemHelper, since it's main purpose
is to provide the Defaults for the Item functionality.
There is that SfxItemInfo, only a struct and bundling
SlotID and ItemFlags. There are also the DefaultItems,
just handled as ptrs in an array. It is/was always
error-prone to keep these in sync. Remember that it's
also necessary for the order to not only being sorted
but being increments of one with no gaps allowed in
the WhichIDs to which the Items are bound.
I now bundled that to a new class ItemInfo that joins
WhichID, SlotID, ItemFlags and the default Item. This
is a pure virtual base class, it comes in three
derivations:
(1) ItemInfoStatic:
This is supposed to be global static and hosts the
Item in a std::unique_ptr to ensure cleanup. It is
designed to be constructed once during runtime and
being shared globally. It allows the ItemPtr to be
nullptr to mark as non-static (if initial static is
not possible for some reason) but still offers the
needed data. Most cases (95%+) are of that case.
The contained Item is owned by that instance. The
flag isStaticDefault() is set at the Item.
(2) ItemInfoDynamic:
This is supposed to be used for cases where the Item
cannot be static: Mainly for SfxSetItem (that needs
a Pool itself in the contained SfxItemSet, so lifetime
is bound to that Pool), but other cases showed up in
the transition. These instances live while the Pool
lives and get destructed when the Pool goes down.
Also uses std::unique_ptr for the Item instance for
as much automated cleanup as possible, the contained
Item is owned by that instance, the instance by the
Pool. The flag isDynamicDefault() is set at the Item.
(3) ItemInfoUser:
This is used for UserDefaults that can be set for
every ItemInfo entry to 'overshadow' the default
from the 'outside'. It uses a regular Item and
the central access methods implCreateItemEntry/
implCleanupItemEntry to manage the Item instance,
thus works like a SfxPoolItemHolder. The Item
instance can be globally shared and re-used even
when the Pool goes down. Instances belong to the
Pool and are cleaned up when the Pool goes down.
This Item does not need any further flag to be
set.
The ItemInfos are organized using a class
called ItemInfoPackage:
This bundles groups of ItemInfoStatic to
functional instances. There are derivations/
implementations of this e.g. for Writer ItemPool
bundling all the needed defaults for Writer,
similar for draw/impress, Calc and other usages.
These ItemInfoPackage can be 'registered' at an
ItemPool using it's method registerItemInfoPackage.
This does all the needed stuff to setup that
group of ItemInfos at the Pool (It even sets
internal vars First/LastWhich, that info can just
be derived from the buildup ItemInfo Ptrs).
The ItemInfoPackage has methods 'size()' and
'getItemInfo(index) to allow looping over it
and deliver the infos the Pool needs. The
(forced, pure virtual) overloads of getItemInfo
in the specific implementations check for the
ItemPtr being nullptr and create a exclusive
incarnation of ItemInfoDynamic for the Pool if
needed, returning that. The Pool owns the
ItemInfoDynamic incarnations and uses the
ItemInfoStatic directly. On shutdown it cleans
up the ItemInfoDynamic as needed.
The ItemInfoUser is used by the Pool when a
UserDefault is set/used: for SetUserDefaultItem,
GetUserDefaultItem, ResetUserDefaultItem. It
is not held in a 2nd list, but directly in the
list of ItemInfo'ptrs: To keep track of this
an unordered_map is used that helds the original
ItemInfo associated with the WhichID. That way
no two lookups (as before) are needed to get the
current Pool's default for any WhichID.
The derivations of ItemInfoPackage are
encapsulated and just allow access to an
ItemInfoPackage& with a single method as
return value. All use a static local instance
of a std::array<ItemInfoStatic, FIXED_SIZE>
which constructs all ItemInfoStatic and the
static Item instances - if already possible.
Sometimes it is necessary to overload the
constructor to set some static instances
for Items later than the lib init. These are
also just marked with nullptr as Item instance.
Some need to overload getItemInfo to complete
instances of ItemInfoStatic, if needed, or
create and deliver instances of ItemInfoDynamic.
The registerItemInfoPackage also offers a
optional lambda callback: there were two cases
where local data from the Pool was needed to
incarnate the item - just add that to the
call to registerItemInfoPackage if needed,
see examples in the adapted code.
For the re-use of Items this means that now
in SfxItemSet/SfxPoolItemHolder *true* static
Items can and will be used without RefCount
directly and globally. This is also the case
for dynamic Items, with the exception of
differing Pools for SfxSetItems which cannot
be done.
Future:
That design is already prepared to allow
solving that Pool-chaining problem: currently
there are master/sub-pools and all accesses
have to traverse that structure before even
doing anything.
For the future the idea is more to 'compose'
a Pool by registering ItemInfoPackages, e.g.
for Writer pool you may start with SfxItemPool,
register the writer-specific ItemInfoPackage,
then the one for DrawingLayer (if needed) and
the one for EditEngine.
It should also be possible to get to smaller
granularities of that packages. Ideas for
new ones will emerge. We might also think
about composing Pools which can e.g. run Writer
and Chart, so allowing to use Chart *without*
OLE stuff in Writer - just ideas...
More changes:
- Adapted all stuff, cleaned up old stuff/
definitions
- Removed FreezeIdRanges, that can be done
once per Pool on-demand (and cannot be
forgotten to be called)
- Merged XOutdevItemPool with SdrItemPool
and offered a ItemInfoPackage which joins
both needed sets of Items
- All the cleanup hassle with Pools and
defaults cleaned up
- Adapted all access methods of the pool
to use that new stuff. Pool chaining
currently stays, but I use a central
method 'getTargetPool' instead of
recursive calling to get the correct
Pool for the action
Change-Id: I2b8d3d4c3cc80b1d0d0b3c0f4bd90d7656b4bab7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163157
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
When a formula cell gets copied from google docs, the value of the <td>
element only contains the formula result. This means once value cells
and formula cells gets copied together, the pasted formula cell won't
updated anymore when the input values change.
Turns out there is a data-sheets-formula attribute on <td> that contains
the formula, it seems it uses the R1C1 format.
Fix the problem by extending ScHTMLLayoutParser::TableDataOn() to parse
this attribute and set a formula on the target cell (rather than a
value) if the formula is available.
This required also extending ScEEImport a bit, since the HTML paste
builds on top of the RTF one in Calc.
Change-Id: I720df96ce74a5e865b7329d06f3b719551f31b96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163234
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Sorted out some methods at ItemPool which process
Defaults to make more clear what is going on and
what which method is doing.
Change-Id: I2568d3e03d0a56a14b6fe4e04521e1a8e22c000b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162643
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
and try something a bit more generic
Change-Id: I1d8256576cd02f0a589df350ba7b53059dd586a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161250
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
ScPatternAttr is traditionally derived from SfxPoolItem
(or better: SfxSetItem) and held in the ScDocumentPool
as Item.
This is only because of 'using' the 'poolable'
functionality of the Item/ItemSet/ItemPool mechanism.
Lots of hacks were added to sc and Item/ItemSet/
ItemPool to make that 'work' which shows already that
this relationship is not optimal.
It uses DirectPutItemInPool/DirectRemoveItemFromPool
to do so, also with massive overhead to do that (and
with not much success). The RefCnt in the SfxPoolItem
that is used for this never worked reliably, so the
SfxItemPool was (ab)used as garbage collector (all
Items added and never removed get deleted at last
for good when the Pool goes down). For this reasons
and to be able to further get ItemSets modernized
I changed this. I did two big changes here:
(1) No longer derive ScPatternAttr from SfxItemSet/
SfxSetItem, no longer hold as SfxPoolItem
(2) Add tooling to reliably control the lifetime of
ScPatternAttr instances and ther uniqueness/
reusage for memory reasons
It is now a regular non-derived class. The SfxItemSet
formally derived from SfxSetItem is now a member. The
RefCnt is now also a member (so independent from
size/data type of SfxPoolItem). All in all it's pretty
much the same size as before.
To support handling it I created a CellAttributeHelper
that is at/owned by ScDocument and takes over tooling
to handle the ScPatternAttr. It supports to guarantee
the uniqueness of incarnated ScPatternAttr instances for
a ScDocument by providing helpers like registerAndCheck
and doUnregister. It hosts the default CellAttribute/
ScPatternAttr. That default handling was anyways not
using the standard default-handling of Items/Pools.
I adapted whole SC to use that mainly by replacing calls
to DirectPutItemInPool with registerAndCheck and
DirectRemoveItemFromPool with doUnregister, BUT: This
was not sufficient, the RefCnt kept to be broken.
For that reason I decided to also do (2) in this change:
I added a CellAttributeHolder that owns/regulates the
lifetime of a single ScPatternAttr. Originally it also
contained the CellAttributeHolder, but after some
thoughts I decided that this is not needed - if there
is no ScPatternAttr set, no CellAttributeHolder is
needed for safe cleanup at destruction of the helper.
So I moved/added the CellAttributeHolder to ScPatternAttr
where it belongs more naturally anyways. The big plus is
that CellAttributeHolder is just one ptr, so not bigger
than having a simple ScPatternAttr*. That way, e.g.
ScAttrEntry in ScAttrArray did not 'grow' at all. In
principle all places where a ScPatternAttr* is used can
now be replaced by using a CellAttributeHolder, except
for construction. It is capable to be initialized with
either ScPatternAttr instances from the heap (it creates
a copy that then gets RefCounted) or allocated (it
supports ownership change at construction time).
Note that ScAttrEntry started to get more a C++ class
in that change, it has a constructor. I did not change
the SCROW member, but that should also be done.
Also made registerAndCheck/doUnregister private in
CellAttributeHelper and exclusively used by
CellAttributeHolder. That way the RefCnt works, and a
lot of code gets much simpler (check ScItemPoolCache,
it's now straightforward) and safer and ~ScPatternAttr()
uses now a hard
assert(!isRegistered());
which shows that RefCnt works now (the 1st time?).
There can be done more (see ToDo section below) but I
myself will concentrate on getting ItemSets forward.
This decoupling makes both involved mechanisms more safe,
less complex and more stable. It also opens up
possibilities to further optimize ScPatternAttr in SC
without further hacking Item/ItemSet/ItemPool stuff.
NOTE: ScPatternAttr *should* be renamed to 'CellAttribute'
which describes what it is. The experiencd devs may know
what it does, but it is a hindrance for understanding for
attacting new devs. I already used now names like
CellAttributeHelper/CellAttributeHolder etc., but
abstained from renaming ScPatternAttr, see ToDo list below.
SfxItemSet discussion:
ScPatternAttr still contains a SfxItemSet, or better, a
SfxSetItem. For that reason it still depends on access to
an SfxItemPool (so there is acces in CellAttributeHelper).
This is in principle not needed - no Item (in the range
[ATTR_PATTERN_START .. ATTR_PATTERN_END]) needs that.
In principle ScPatternAttr could now do it's own handling
of those needed Items, however this might be done (linear
array, hash-by-WhichID, ...). The Items get translated
to and from this to the rest of the office anyways.
Note that *merging* of SfxItemSets is *still* needed what
means to have WhichID slots in SfxItemState::DONTCARE,
see note in ScPatternAttr::ScPatternAttr about that. And
there is also the Surrogates stuff which would have to be
checked.
The other extreme is to use SfxItemSet *more*, e.g. directly
derive from SfxItemSet what would make stuff easier, maybe
even get back to using the 'regular' Items like all office,
I doubt that that would be much slower, so why...?
Also possible is to remove that range of Items exclusively
used by ScPatternAttr from ScDocumentPool *completely* and
create an own Pool for them, owned by CellAttributeHelper.
That Pool might even be static global, so all SC Docs could
share all those Items - maybe even the ScPatternAttr
themselves (except the default per document). That would
remove the dependency of ScPatternAttr from a Pool
completely.
ToDo-List:
- rename ScPatternAttr to CellAttribute or similar
- use SfxItemSetFixed with range [ATTR_PATTERN_START
.. ATTR_PATTERN_END] instead of regular SfxItemSet
(if the copy-construtor works now...?)
- maybe create own/separate Pool for exclusive Items
- make ScAttrEntry more a C++ class by moving SCROW
to the private section, add get/set methods and
adapt SC
Had to add some more usages of CellAttributeHolder
to the SC Sort mechanism, there were situations where
the sorted ScPatternAttr were replaced in the Table,
but the 'sorted' ones were just ScPatternAttr*, thus
deleting the valid ones in the Table already. Using
CellAttributeHolder makes this safe, too.
Added a small, one-entry cache to CellAttributeHelper
to buffer the last found buffered ScPattrnAttr. It
has a HitRate of ca. 5-6% and brings the UnitTest
testSheetCellRangeProperties from 0m48,710s to
0m37,556s. Not too massive, but erery bit counts :-)
Also shows that after that change optimizations in
the now split functionality is possible and easy.
Change-Id: I268a7b2a943ce5ddfe3c75b5e648c0f6b0cedb85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161244
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
instead of using SfxObjectShell and then static_cast'ing it
everywhere.
Change-Id: Id3184e44f048228dc4d0d9fa5d579e663c2762cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156945
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Write the font table while visiting column/row and
get the unique index to reference it.
"The \fonttbl control word introduces the font table group.
Unique \fN control words define each font available in the document,
and are used to reference that font throughout the document."
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I20c5d1128972f5ec9b9b2e246f466bdb173ef8a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154906
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156415
Tested-by: Jenkins
Create a map font name associated with unique index.
"The \fonttbl control word introduces the font table group.
Unique \fN control words define each font available in the document,
and are used to reference that font throughout the document"..
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: I028226cb539865f1980f953385c887a3bd4b8e3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154905
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156414
"An RTF file has the following syntax:
'{' <header> <document>'}' "
In order to build the header:
<header>
\rtf <charset> \deff? <fonttbl> <filetbl>? <colortbl>? <stylesheet>? <listtables>? <revtbl>?
The font table should be created while visiting the column/rows.
Signed-off-by: Henry Castro <hcastro@collabora.com>
Change-Id: Id72a3c87acab6cfc7889cf81f7e83a0d73e378a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154903
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156412
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Add Detect numbers in scientific notation option to HTML paste
Still need some qa tests
Change-Id: I553404a01ab2a61566b861b3c01d14bdc0c46668
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152591
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
WriteOString is a better replacement
Change-Id: Ic431b9aeb98d19fe61cff71360eee555105cc2bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150192
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Graphic is just a wrapper around shared_ptr, so no need to
allocate this separately
Change-Id: Ie657dea1c021e66a6876e814090a44cb6f995b91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139739
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Which means we can get rid of the majestic hack of ScCaptionPtr
Previously, SdrObject was manually managed, and the ownership
passed around in very complicated fashion.
Notes:
(*) SvxShape has a strong reference to SdrObject, where
previously it had a weak reference. It is now strong
since otherwise the SdrObject will go away very eagerly.
(*) SdrObject still has a weak reference to SvxShape
(*) In the existing places that an SdrObject is being
deleted, we now just clear the reference
(*) instead of SwVirtFlyDrawObj removing itself from the
page that contains inside it's destructor, make the call site
do the removing from the page.
(*) Needed to take the SolarMutex in UndoManagerHelper_Impl::impl_clear
because this can be called from UNO (e.g. sfx2_complex JUnit test)
and the SdrObjects need the SolarMutex when destructing.
(*) handle a tricky situation with SwDrawVirtObj in the SwDrawModel
destructor because the existing code wants mpDrawObj in
SwAnchoredObject to be sometimes owning, sometimes not, which
results in a cycle with the new code.
Change-Id: I4d79df1660e386388e5d51030653755bca02a163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
so we can assert that it has the correct tag type
Change-Id: I984c22ae2527d652f2d4194227dc1173793300c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136054
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
as a first step to wrapping up the internals of this class and adding
some asserts
Change-Id: Ic13ddd917948dbf3fd6d73f44b8efcc727726baf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135994
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
since we never return a nullptr, and rename to reflect that
Change-Id: I5b8f0aba6ce387bb0fe1ce6088ba2685d2ade7f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122209
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... because "update" is such a generic term I keep forgetting what we
are turning on and off
Also return the previous value from SetUpdateLayout to
make the save/restore code more compact.
Change-Id: Iae1764c837a92e58c9b17521f130e8fc80311d22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121479
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
so I can make changes without running into cyclic dependencies
between header files
Change-Id: I98a91c7cc66002ba745cdb8239e5cc267922a45c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120412
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
If a LogicToLogic uses fixed units, we can use o3tl::convert
instead. We can also do the same for all other cases where
LogicToLogic is used, but that needs additional investigation to
determine if it is safe to do so.
Note:
MapUnit::Pixel is converted to o3tl::Length::pt because it assumed
72 PPI for a logical pixel, which corresponds with the conversion
rate of a point (72 PPI).
Today, 96 PPI is standard, which is also used for o3tl::Length:px.
Change-Id: I29126df38bfcfda74b5d83d4cb880a378aecd18b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120230
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
so we can remove SfxItemPoolUser, which is a right
performance hog when we have large calc spreadsheets
Change-Id: I344002f536f6eead5cf98c6647dd1667fd9c8874
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115247
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
add use so we can hold the pool with std::unique_ptr
Change-Id: I685fbc37c0ae145a5b48a66a88eab9fb29a0fc0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115174
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts dca0374fb1edbd9bdeeaadda3f1866ce66b3a778 and instead
tries to achieve the same without using a flag in ScGlobal. How
reliable that is I don't know. See
https://gerrit.libreoffice.org/c/core/+/110245 for discussion.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110245
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Change-Id: I2a7aa5bf3d29e5fd071e2f1cab628b923b5b6754
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110285
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
unused since 9fb7aaf570c03c8a26d763f1205fb8c890e8211a "Make linked graphic
register into LinkedManager again", and remove further function parameters and
class members that turn out to be unused now, too
Change-Id: I3dd2b138fd8787d12b89547526da751ea5954845
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106041
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>