| Age | Commit message (Collapse) | Author |
|---|
|
Both parts of a hyphenated word shall lie within a single
page with ODF paragraph setting fo:hyphenation-keep="page".
The implementation follows the default page layout of
MSO 2016 and newer by shifting the bottom hyphenated line
to the next page (and to the next column, see last note).
Note: this is a MSO DOCX interoperability feature, used
also in DTP software, XSL and CSS.
* Add checkbox/combobox to Text Flow in paragraph dialog
* Store property in paragraph model (com::sun::star::style::ParagraphProperties::ParaHyphenationKeep)
* Add ODF import/export
* Add ODF unit tests
New constants of com::sun::star::text::ParagraphHyphenationKeepType,
containing ODF AUTO and PAGE (borrowed from XSL), and for the
planned extension ParaHyphenationKeepType of ParagraphProperties:
– COLUMN (standard XSL value, defined in
https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#hyphenation-keep)
– SPREAD and ALWAYS (CSS 4 values of hyphenate-limit-last,
equivalent of hyphenation-keep, defined in
https://www.w3.org/TR/css-text-4/#hyphenate-line-limits).
Note: the implementation truncates only a single hyphenated
line, like MSO does: the pages can end in hyphenated
lines (i.e. in the case of consecutive hyphenated lines),
but less often, than before.
Clean-up hyphenation dialog by collecting "Don't hyphenate"
options at the end of the hyphenation settings, and negating them
(similar to MSO and DTP), adding also the new option
"Hyphenate across column and page":
[x] Hyphenate words in CAPS
[x] Hyphenate last word
[x] Hyphenate across column and page
Note: ODF fo:hyphenation-keep has got only "auto" and
"page" attributes, while XSL defines also "column".
Because of the interoperability with MSO and DTP,
fo:hyphenation-keep="page" is interpreted as
XSL "column", avoiding hyphenation at the end
of column, not only at the end of page.
Change-Id: I5c6b7adc0671a5a790568e7bf1d33256e607f85f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164158
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Allow to change bullets in configuration.
Change-Id: Iab26118dd597417997d6f0a7355f516a4da97ee4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163735
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
which means I can remove one usage of gb_Library_set_plugin_for, which
is blocking linking the cui module into --enable-mergelibs=more
Change-Id: Ic6cd48377627f94747037c7247a1cd398738b390
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163820
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This option is not the equivalent of resetting the user properties in File->Properties,
so remove that information from the tooltip.
Change-Id: I0718443452b9285c8e7ba0d742aed790ed6a2403
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163433
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: I51585f1c15984a066262023184f668662853d20f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163556
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
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>
|
|
Change-Id: Icbc9d131d90e639490f6dfd896565c994a17b172
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162829
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
and
cid#1401342 Uncaught exception
Change-Id: I77c2303ceb25301d85bfc9f8f6dc9eb8f4c4494a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162945
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
since:
commit 93c4bfc96acf7f387120ff05883068d358a608c1
Date: Thu Jan 25 10:29:47 2024 +0200
make writer databases dialog async
Change-Id: Ic67a7b5313e1dfad9c34fc3bf05ca808af29ceba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162944
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
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>
|
|
and use that in the dtor instead of a pointer.
FWIW the XWindow isn't actually a vcl::Window in the Gtk case, so
VCLUnoHelper::GetWindow doesn't do anything there. But using an
XWindow gives a safe view wrt life cycle.
Change-Id: I4d0fd707ea931a76d6f87f434f7ece8df066785c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162744
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I9f3c3bc3c555ef8a115258ff6d186ceeead3cc99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162556
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia2de2ad1ccc16e0212e4c1be2df2f6958c490da6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162686
Tested-by: Jenkins
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
|
|
Change-Id: I3bc2bde431dc71d4a01f7e314c67be31271be9e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162681
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
They seem to be designed with multi-dimensional flexibility in mind;
it is stored as an array of lists, each having a name and a module.
The name may mean a filter. It may have a special name "_user" with
unclear meaning.
But it only ever used a single item in the array, named "_default",
in a single module (swriter). Everything else was only read into a
hidden listbox in Compatibility dialog, and never shown nor used.
Make ir much simpler. Just use the "_default" item. It is possible
to expand it later, if needed; but the previous complexity was bad
for maintenance and adding new options.
Translatable descriptions of the options were moved from UI file
to sw/inc/strings.hrc, and used in a structure that clearly maps
them to respective identifiers, to avoid fragile hidden dependency
on order of different lists.
Change-Id: I78ac5add8a872613e1fb388e4b8cc4fbf4362adf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162651
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@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>
|
|
since:
commit fe946f86ad6586fa810cae5c0f246389a285e172
Date: Wed Nov 29 15:25:06 2023 +0100
Bump Glade version
Change-Id: Ide86220f260dac40395389530e7221ea8de8f092
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162606
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Don't export printer name & printer config when
RemovePersonalInfoOnSaving is enabled, as it might contain
sensitive data such as printer location.
Add an option to export printer settings even when
RemovePersonalInfoOnSaving is enabled.
Change-Id: I3d2ca91ad2032050c919d382c11c9ceabf331770
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162577
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: Icb6c2fafe2b47989ff2692956890c87780b117e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162552
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
On Position tab of Character formatting dialog window
as a new checkbox "Exclude from hyphenation" (UX design
by Heiko Tietze).
With this, it's possible to disable hyphenation
with direct character formatting (e.g. combined with
Find All), or using character styles, and setting
"Exclude from hyphenation" in them. This feature
is conformant to the OpenDocument standard, and
unlike the previous locale=None workaround, it keeps
spell checking and locale dependent text layout.
Note: Clear direct formatting (Ctrl-M) is an
alternative way to remove the enabled CharNoHyphenation
(e.g. in version 24.2, where this commit won't
be back-ported).
Follow-up to commit b5e275f47a54bd7fee39dad516a433fde5be872d
"tdf#106733 sw: implement CharNoHyphenation".
Change-Id: I26823e6ec2a3ca39dcf0f7c051d96e638921c589
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162514
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Open Security Option Setting page directly from Security pop up
warning infobar.
Follow up of 1f440348eb0892fd2c9597806d87b5fe9d60d49a
(tdf#157482 UI: Turn Security Warnings popup windows into infobars)
Change-Id: Iac116677801bdb13a9680bcfdf532ec3d874ce0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162393
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
|
|
Change-Id: I6a23f648784f61e72e6095b249719d9c8630252f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162444
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I64cb2ae5b3748e8034fb0624b56c3d3dfdc31654
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibbfbc5024fb2be4906d0c312577310f28dde212d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162434
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
* Add an option to configure the accent color, which is
blue by default might not be visible to color blind people.
Change-Id: I72cbb0f57e864407a7c9315b5c46645a891d4764
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162055
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
|
|
Change-Id: I7c088b1450050720a28fbc7ccf139b8c69f1cf19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162419
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>
|
|
Change-Id: I4a0060422b55f681c3f4f0eb9a908d3b30faeb32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162347
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
It is used only on the Load/Save - General page, and it's
redundant with using officecfg methods and setting UI elements
representing locked down keys as insensitive + showing a lock icon
Change-Id: I689e7925198f8aac60b5711bf1c349c45a5ab62a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162267
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
After some experiments I now can remove
DirectPutItemInPool and DirectRemoveItemFromPool.
With the changes done before it is now possible to
get rid of this 'compromize'. Now there are no
more Items held at the 'Pool' which now can be
developed in the direction of ssth like
'SfxItemSupport' - what it really is.
Some of the last usages of DirectPutItemInPool were
in SvxAreaTabDialog::SavePalettes(), so I tried to
trigger those cases with using LO and calling that
Dialog in all situations I could possibly think
about, but it was never used.
Then I added asserts and run a UnitTests in the apps,
also no luck. Thus I would guess these are not used.
These put changed stuff from the Dialog 'directly' to
the Pool (what is not really supported and is a hint
for a 'compromize' that some functionality did not
find/want to use the right spot in the model to save
and hold that data). Thus it *would* be accessible
using the SurrogateMechanism at the Pool (which is
also a 'compromize', see some of my other commits),
but I also found no hints at places where that is
done.
Thus I decided to create this change and let's see
if that asserts ever get triggered in the builds
or tests.
Indeed did not trigger. I checked what other places
do which use SfxObjectShell::Current() when they get
no DocShell: Most avoid doing something, but none
puts stuff to the Pool, so I go one step further
and do what other places do: warn and return. Also
simplified SvxAreaTabDialog::SavePalettes() as then
feasible.
Change-Id: I1c351eac4ada26288a56a69d57008a09f2d19121
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162340
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Ia2e9ab91def1454bd06044b0e38f2d0720b44033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162246
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
4256c764aee0777770466115a97420d9b55c23ac "do not pass XComponentContext to
officecfg::...::get() calls" had removed it, for performance reasons, but
8a695046cfcc8f9ec835b208b0d56ca821a3ff84 "tdf#158375 Hack to make sure process
service factory is set" is a case where it should be passed in. To hopefully
avoid performance regressions, don't default to
comphelper::getProcessComponentContext() for what gets passed in, but default to
an empty Reference and only call comphelper::getProcessComponentContext() when
actually needed in the implementation.
Change-Id: I5b75ac2c28f36e21d1c8bc368b0b972c33c61a51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162205
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
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: I0e26a053b3b5fb04abf87894bcfebccea8bdd26f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162074
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Change-Id: I7623e983e14ab7de3948921ca1223488fa2049a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162067
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I587d60c8da53df937ed8992a846993078710659f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161971
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
this widget is the one that ends up controlling the insert hyperlink
dialog width
Change-Id: I09aaa32e96c4ddcc3e608cb24e67a669d376120f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161960
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I52a7cd6a8e3bb42062d42b99b42875f89dd7b133
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161959
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@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>
|
