| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 2cf7c26293462406d91ee050c6677930065e660b.
Reason for revert:
<_rene_> noelgrandin: sdui->sd... and what about people not needing that ui?
<_rene_> (e.g. --disable-gui and libreoffice-draw-nogui and impress-nogui)
<_rene_> i.e. the use case of --convert-to for ppt(x) etc
Change-Id: I6755c209e63f34b3fc9f9fdc4af7001b18579e8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163348
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which eliminates another dynamic-symbol lookup and another complication
which was making it harder to do better with --enable-mergedlibs
sd is relatively small, so even the combined library is not as big as
one of the sw and sc libraries
Change-Id: Ibef8077d70a5abc7361c95f5dbb8c43447610188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163302
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id5e35e1514695bffeced718d48dcfeffc4a4d4d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163250
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Icons taken from https://thenounproject.com/icon/lock-89649/ and
https://thenounproject.com/icon/unlock-89647/ (licensed PD)
Change-Id: I7efd25e83726ced7dee4f876cf4bb4c8f54408df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160460
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
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>
|
|
Adds a goto page/slide dialog for Impress and Draw similar to Writer.
To avoid duplicating code and ui, the dialog is created in svx/ and used in other modules.
The old goto dialog in Writer has now been replaced with this dialog.
Change-Id: I28f819f0d0734fb2bb08a7b99a628217ef66dba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162913
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
Copies list type and list level from source to target paragraph(s).
Also switches off lists, if source is not in a list.
Change-Id: I260f1d7d9936476f16c355a3a09204b3fb4592d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163054
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Makes the new last page in the document be the page switched to after a
page delete of the last page in the document. Before the patch, when
the draw view has focus (not the slide sorter), deleting the last page
in the document results in a switch to the first page.
Change-Id: I8d3904e85254228e01d423f15312981d11fc9755
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159963
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
Also relayout the text
Change-Id: Id774c5a5089e1c031ae705e6b23281e882b6739f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162995
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
remove CUI_DLLPUBLIC from stuff which is not exported
then drop the cui/include dir which is then empty and
the places we link to cui where we now don't need to
and restore cui back to a lib containing stuff that
doesn't need to be explictly linked to in keeping
with original #i106421# idea
Change-Id: I21894e6f8529dd3306df345fb52dbf5009015f3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162798
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
the point of cui was to have no headers, so move this
SvxNumberingPreview out of cui and into svx
Change-Id: I83edbcdc8d8b95dbea734bdef4a93f6ec8ee50e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162748
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Add .uno:NumberFormatCurrency item to .ui
Use weld:: way of widgets creation so we can inject
jsdialog code and popup will be correctly registered.
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: Ib57e1cad617ca5c7198d67e107441ba062580f06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162623
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162710
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
and
cid#1588087 COPY_INSTEAD_OF_MOVE
cid#1588085 COPY_INSTEAD_OF_MOVE
cid#1588084 COPY_INSTEAD_OF_MOVE
cid#1588083 COPY_INSTEAD_OF_MOVE
cid#1588082 COPY_INSTEAD_OF_MOVE
cid#1588081 COPY_INSTEAD_OF_MOVE
cid#1588080 COPY_INSTEAD_OF_MOVE
cid#1588079 COPY_INSTEAD_OF_MOVE
cid#1588078 COPY_INSTEAD_OF_MOVE
cid#1588077 COPY_INSTEAD_OF_MOVE
cid#1588076 COPY_INSTEAD_OF_MOVE
cid#1588073 COPY_INSTEAD_OF_MOVE
Change-Id: Ibd0fc37ed1f93e0c092e0ce2ef04b28b4df4bccf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162665
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: Ifc8721f50f359669af501c91bc86d6a983785f9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162663
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
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>
|
|
Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove
non-const Sequence::begin()/end() in internal code, 2021-10-15) and
commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Icb6c2fafe2b47989ff2692956890c87780b117e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162552
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic24b2b935f1d539cf257194d136d901b52e00a84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162433
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I09ce07f7b520688aa54dd30107b5ab2218b12894
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156277
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 62804da3c0ab9443cf36f2e02387a2e9c272d5dc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162463
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I05ef274dd0ad5dc35b5455cfc01feabc6c0820a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161276
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: I49a1ff800c6b5fcee69e160158a089659d288bdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162422
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I067d682ade01671d7aa347a492929ae4f92064b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162421
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I239d8d344ed3152586567c6e1d9b529ba75925dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162418
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I26ec71ab5b00545a2e173dd4cc3dcd49d79c2fa7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162417
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icf81810297dc5767cedd051cf8ccdfbb101f35ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162395
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia5869788ccefcd17ef561bafb41da6f0d48fd54d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162394
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I222240dc1715604ad1e82e1062b34d116b2840f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162367
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to look like getters elsewhere, which compose better
Change-Id: I23277910d3fb3c08fa6e839f0fbec010915e951a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162362
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
when the PPTX file only has table style id, but no table style content.
Change-Id: Ia3416478716a50beb6837988e98697fd88e916d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162368
Tested-by: Jenkins
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
|
|
{Imp}EditView always needs to have EditEngine set (or it would
crash otherwise), so we can change the getter to return a referece
instead of a pointer. This simplifies things a bit because we get
rid of all the nullptr checks and makes the interface more clear.
Also change direct access to mpEditEngine in {Imp}EditView to use
getEditEngine() and getImpEditEngine() (returning a reference)
instead.
Change-Id: Ib8f9c565b8364144bb9c35c3093c4975af1970c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162333
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
ItemSurrogates are a possibility to iterate over
all SfxPoolItems associated with a WhichID at a
ItemPool to collect or change data.
It is in general not a good idea: the correct action
would be to iterate over the model data and change/
adapt/collect data on the Items of the type
in question. This is because the *assumtion* that you
iteate over all the Items associated with a document
model is *not* correct:
The ItemPool of the model is used for various ItemSets,
e.g. Dialogs/Sidebar and others, so you might get Items
not only from the DocumentModel but from elsewhere.
You might even get Items from *other* models, so
changing these might have unpredictable effects (!)
It is clear to me that this mechanism is more convenient
that iterating over the document models, and it might
have been invented due to this and then used in more
and maore cases. There should be a lambda/callback-based
mechanism in every document model to do this. Until then
we have to live with this 'compromize'. There are over
100 usages currrently, so no way to easily replace this.
For those reasons I changed this to be more safe: There
are two methods to do this now:
1: iterateItemSurrogates to allow read/write access. I
identified six places where that mechanism was used
to change SfxPoolItems, with the use of const_cast.
This now offers a lambda/callback mechanism and the
needed data in a helper (SurrogateData). Internally
it iterates over ItemSets and ItmHolders registered
and thus associated with the Pool. Changing an Item
means to set a changed Item at the Pool/replace the
holder.
2: GetItemSurrogates/FindItemSurrogate to allow
read-only iteration (2nd one with filter). This
collects the Items in a vector that you provide over
which you can then iterate. Do *not* use const_cast
and change the Item when using this (!)
Note that mechanism (2) pe-filters the Items so that
you get each only once: Of couse one Item can be set
in more than one ItemSet/Holder (but also in more than
one model). This filtering is not possible for (1), you
have to evtl. do the same replace action for the same
item, but this is the only way to not change Items that
are associated wth another model.
Note that (2) could also be changed to a lambda/callback
mechanism similar to (1), but there are too many places
that would beed to be adapted. That would have the
advantage to not need to pre-collect the candidates in a
first run.
Also removed/replaced FindItemSurrogate with using
GetItemSurrogates and locally filtering with that needle.
That also made me remove/cleanup CollectSurrogates, it's
only used in one place now.
Change-Id: I0fe2f51f4fca45e1e5aea032cb96bb77b4567f4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162254
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
It is used in readonly mode.
Signed-off-by: Gökay Şatır <gokay.satir@collabora.com>
Change-Id: I428d4923ab89dbcf6df237c68ae792753c1edf13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162201
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
(cherry picked from commit 876543305c78cb596720da087454a5c54e5feb06)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162222
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Importing the text marks the object as not empty. Then, the object would
behave as an outliner object. This includes showing in slide show; allowing
text esiting; stretching the placeholder image, which required a workaround
implemented in commit 7b3be7f6f3d800e2ad86f5a043e6e9b21ed4409f (tdf#140912
Better handling of the picture placeholders, 2021-12-01).
Instead, drop the custom prompt. More correct solution would be making sure
to mark the object as empty after setting the text; but this doesn't round-
trip to ODF; and it crashes export to PPTX. Proper support for the sustom
placeholder prompt feature should be done separately.
The new workaround (dropping the text) makes previous workaround (special
handling of the placeholder graphic) unnecessary. The unit test is updated.
Change-Id: Ic7f42493af8d1d725ffa39ffab58f1ff033351cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162202
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I3d23186045c17006e50d9ef48bc26df3c79d28b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162052
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
The ::Put methods at SfxItemSet had an extra WhichID
parameter that was not really documented, but I would
guess often asked why it exists: An extra WhichID, just
called 'nWhich' (which makes things NOT clearer). That
is 'strange' since the Item given to be put already
internally has a WhichID, so why a 2nd one?
If you were really interested and read all that code
(no, no comments on that anywhere) you might know
that this a kind of 'Target-WhichID' under which
the Item shall be put to the ItemSet. Since this
is unclear for most people it is even dangerous and
explains why so many code places just hand over the
WhichID requsted from the Item that already gets
handed over.
To make it short: I removed that. For the 19 places
where this was really needed I added a new method
besides ::Put called ::PutAsTargetWhich that takes that
extra WhichID (now called TargetWhich) and takes the
needed actions. These are quite some because that may
be combined with the bPassingOwnership flag, see new
SfxItemSet::PutImplAsTargetWhich method.
This makes usage of ItemSets/Items less dangerous. It
also simplifies and thus makes safer the central helpers
implCreateItemEntry/implCleanupItemEntry which have some
less cases to handle.
Debugged the failing UnitTests showed that there is
an incarnate Item != SfxVoidItem that causes problems.
I checked for errors in the change, but no luck.
Afterr some time I found out that a ::Clone
implementation caused the problem: These need to
also copy the WichID of the original, but the
SfxFrameItem failed to do so. This did not cause
problems in the former version because
implCreateItemEntry was designed to set a missing/
different WhichID.
I corrected that in SfxFrameItem, also removed not
needed costructor that caused that. Also added a
SAL_WARN and a correction in implCreateItemEntry.
I could have added an assert (did so for running
local UnitTests), but should be enough.
NOTE: When hunting for Items except SfxVoidItem
that get crerated using a WhichID '0' i learned
that this indeed happens: There are some (5) calls
to SfxRequest::SetReturnValue that incarnate an
SfxBoolItem with WhichID '0' (ZERO). This is not
good and I think about how to change that...
Change-Id: I9854a14cdc42d1cc19c7b9df65ce74147d680825
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162124
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I24c429c7cb8283a384b72499d1c3f4c2f1457c33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162155
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and
cid#1545812 COPY_INSTEAD_OF_MOVE
cid#1545463 COPY_INSTEAD_OF_MOVE
cid#1545290 COPY_INSTEAD_OF_MOVE
cid#1545844 COPY_INSTEAD_OF_MOVE
Change-Id: Ie6d997fc6282599631dc9e07e2e59893e499c239
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162058
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1546154 COPY_INSTEAD_OF_MOVE
cid#1546120 COPY_INSTEAD_OF_MOVE
cid#1546115 COPY_INSTEAD_OF_MOVE
cid#1546111 COPY_INSTEAD_OF_MOVE
cid#1546096 COPY_INSTEAD_OF_MOVE
cid#1546016 COPY_INSTEAD_OF_MOVE
cid#1545980 COPY_INSTEAD_OF_MOVE
cid#1545942 COPY_INSTEAD_OF_MOVE
cid#1545902 COPY_INSTEAD_OF_MOVE
cid#1545869 COPY_INSTEAD_OF_MOVE
cid#1545853 COPY_INSTEAD_OF_MOVE
cid#1545769 COPY_INSTEAD_OF_MOVE
cid#1545742 COPY_INSTEAD_OF_MOVE
cid#1545735 COPY_INSTEAD_OF_MOVE
cid#1545689 COPY_INSTEAD_OF_MOVE
Change-Id: If93debe8b00991761cf1876b3fce27b09906749e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161966
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
and
cid#1546408 COPY_INSTEAD_OF_MOVE
cid#1546367 COPY_INSTEAD_OF_MOVE
cid#1546283 COPY_INSTEAD_OF_MOVE
cid#1546268 COPY_INSTEAD_OF_MOVE
Change-Id: I8b6067f70bc0e8cce7117bb3f366227add279887
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161964
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
First step for publishing any palette for LOK.
Let's start with Document colors (colors used in the
document) which can be extracted similar to theme
colors from SfxViewShell.
Modify generateJSON function so it appends palette into
existing ptree/JSON.
In the next step we can make it more generic so it will
be able to send any palette managed by PaletteManager.
Change-Id: Ibb56690af6dfd59ee232e88b28e7a3d312d0e16c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161798
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 0460be8848b0ce02c07183e41dd7137ac3b94164)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161941
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
The issue is that the flag RegisteredAtPool
at the SfxPoolItem is Pool-dependent: It marks that
the Item is registeres at *one* Pool/Model. This
makes it Pool-dependent. Due to this there is no way
to share Items that need to be registered globally/
in multiple Pools/Models what is one of the goals
for optimal sharing.
We can also not live without having access to all
Items associated with the Pool, due to mechanisms
in place like the Surrogate stuff.
This again is used for two purposes:
(1) Access all Items associated with one Pool/Model,
at least that is the assumption. This is not valid
since it gets corrupted with a single ItemSet/Holder
used that does not host model data, e.g. an open
Dialog or the Sidebar (or...). But works in
principle.
(2) Access extra-Items that are held nowhere and
are created using DirectPutItemInPool, e.g. infos
for a Dialog. These would need a instance/place to
host them, the Pool is (ab)used for that.
Both are 'compromizes' (to not use a more bad word)
and should not exist. (1) should iterate over the
Model and do actions. There are even places that
use (1) to *change* Items, by casting them to
non-const, even RefCounted ones, so having no control
over what all might be changed doing so. Since we
talk about ca. 100+ places there is no way to get
away from this - I can imagine how this happened:
The 'poolable' attr traditionally needed for the old
binary format was one day 'used' to not need to
iterate over the Model, an API was added to access
and this usage was copied. Sigh..
It is even used when ODF is loaded: E.g. the
FillStyle is imported from XML, interpreted, and
put into an ItemSet. Then it gets set at the
XShape using UNO API and a *name* -> that name and
the Surrogate mechanism is used to find and set the
FillStyle at the Model Object. The FillStyle could
probably just be set using UNO API and the data
directly.
The association between Model/Pool and Item is
created by the object hosting the Item, these are
ItemSets and ItemHolders. Thus it is possible to
register these at the Pool. This allows to iterate
and collect the Items associated with the Pool
and keep the Surrogate mechanism alive.
This is the main change done here. It limits
the registrations to Items for which (at the Pool)
the NeedsPoolRegistration is set, also
Item-independent. Speed is okay, I saw no big
changes in my tests here. The registration is
just pointers, no ownership or RefCounting needed
here.
The advantage is that Items get closer to be
shared office-wide, they can be referenced by
multiple ItemSets (RefCnt) associated with
different Pools/Models.
NOTE: This is not true for SfxSetItems, these are
and will stay Pool-dependent due to their need
to a Pool in the contained ItemSet.
Note that we have ca. six deivations of SfxSetItem,
but ca. 500+ Item derivations, so not too bad.
For the usages of Surrogates to change existing,
RefCounted Items: These can now at least be
changed - if they show up to be problematic - to
iterate over the registered ItemSets and change
Items there the correct way: Set a changed one
at the ItemSet. That also allows Objects to
*react* on ItemChanges, there is no way to do
that with the existing 'compromize'...
UnitTests show that this already works well for
SC and SD, but SW has still some issues. I will
put this to gerrit now, but there will be
additional work.
A involved problem is the current DefaultItem
handling and the state the Pool implementation
is in. E.g. StaticDefaults are not really static,
Pools hard-delete the DefaultItems (forcing the
RefCnt to zero to not have the destructor
complain) and other quirks. Looking at that
right now, hoping to get this change done without
having to change that too much.
I thought about adapting PoolItemTest to this,
but it is only related to DirectPutItemInPool
which is mostly gone and hopefully completely
soon.
Nonetheless I adapted that mechanism to use a
list of SfxPoolItemHolder at the Pool. That makes
it safe and abandons the need for indirect
garbage collection removal at the Pool.
Change-Id: Ib47f21dafa989202930919eace5f7e9c5632ce96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161896
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
As it is done already for Writer. Unfortunately cannot
move the code from afterCallbackRegistered to base class
in sfx2 as it is not linked to svx which is needed to
generate JSON. So at least share generation and sending
part in ThemeColorChangerCommon.
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: Icbf681230bd4c49698c47d852a0862620d93bcec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161771
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161927
Tested-by: Jenkins
|
|
See https://lists.freedesktop.org/archives/libreoffice/2024-January/091422.html
Change-Id: I79e94912708a8d0ebd2aca76899e6fbb9fc23f2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161923
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
The impl SlideshowImpl gets notifications for changes from
the ObjectModel, but needs to ignore them when SlideShow
is not active/running. For discussion how to do this see
comments in task.
Change-Id: Ic251af4b82f0f4b48d8d9b0127dd2f6015966935
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161922
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
followup for commit 64624d225c71229acce4f889d4863d7c29c52658
lok: send error on access denied in image import
It shows an error in LOK when we try to insert image
from remote host blocked by HostFilter
Previously it was showing error in paste case,
now do the same also on image insertion.
For now disable HandleGraphicFilterError in sd, as it
crashes, is synchronous and cannot be easily fixed
- dialog sits inside module not linked to sfx2, needs
some rework.
Change-Id: I3c15ff5621add97ef9d60d4f4c1305dae2909158
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161001
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161774
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
and
cid#1545364 COPY_INSTEAD_OF_MOVE
cid#1545363 COPY_INSTEAD_OF_MOVE
cid#1545344 COPY_INSTEAD_OF_MOVE
cid#1545299 COPY_INSTEAD_OF_MOVE
cid#1545287 COPY_INSTEAD_OF_MOVE
cid#1545267 COPY_INSTEAD_OF_MOVE
cid#1545256 COPY_INSTEAD_OF_MOVE
cid#1545226 COPY_INSTEAD_OF_MOVE
cid#1545500 COPY_INSTEAD_OF_MOVE
cid#1545538 COPY_INSTEAD_OF_MOVE
cid#1545618 COPY_INSTEAD_OF_MOVE
cid#1545681 COPY_INSTEAD_OF_MOVE
cid#1545750 COPY_INSTEAD_OF_MOVE
cid#1545778 COPY_INSTEAD_OF_MOVE
cid#1545785 COPY_INSTEAD_OF_MOVE
cid#1545799 COPY_INSTEAD_OF_MOVE
cid#1545847 COPY_INSTEAD_OF_MOVE
cid#1545958 COPY_INSTEAD_OF_MOVE
cid#1545963 COPY_INSTEAD_OF_MOVE
cid#1545990 COPY_INSTEAD_OF_MOVE
cid#1546013 COPY_INSTEAD_OF_MOVE
cid#1546029 COPY_INSTEAD_OF_MOVE
cid#1546079 COPY_INSTEAD_OF_MOVE
cid#1546104 COPY_INSTEAD_OF_MOVE
cid#1546127 COPY_INSTEAD_OF_MOVE
cid#1546133 COPY_INSTEAD_OF_MOVE
cid#1546155 COPY_INSTEAD_OF_MOVE
cid#1546190 COPY_INSTEAD_OF_MOVE
cid#1546216 COPY_INSTEAD_OF_MOVE
cid#1546273 COPY_INSTEAD_OF_MOVE
cid#1546315 COPY_INSTEAD_OF_MOVE
cid#1546326 COPY_INSTEAD_OF_MOVE
cid#1546387 COPY_INSTEAD_OF_MOVE
accept some reasonable suggestions
Change-Id: I7b004086d490c7618d8fe7a21a53cfa8ac1f8408
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161748
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I598960d8cc7d394581def20de3ab64a8ff6c7789
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161694
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I1a404fe156c9c7859c1eb19d4dff9892f4598bc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161591
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
At first it seemd that sal_uInt16 may be sufficient for storing possible
values. But as elsewhere unsigned 32 bit variables are used for such
purpose, sal_uInt32 is used which allows having more space for bigger values.
Change-Id: Ic2834ffc0fcabad91175aba3753e832dc1807fbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151006
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: Idc3a4e983de0dec226ae1830fd70dc222624edd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161565
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
