these were skipped in previous runs, since they contain some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
This also shaves off some 140M input
Change-Id: Ie1f57174dd6fec3ba5b0b91eb0688acdc1a8143d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197494
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Replace by operator[], begin() and end(), which don't have overhead
since commit 2484de6728 (Remove non-
const Sequence::begin()/end() in internal code, 2021-10-15)
and commit fb3c04bd19 (Drop non-const
Sequence::operator[] in internal code, 2021-11-05).
Change-Id: I221470b3439bb0dc6e7705b0d99deb3cd2063484
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195176
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Added the following commands:
.uno:StartPara
.uno:EndPara
.uno:CommonAlignStart
.uno:CommandAlignEnd
Currently, the Start/End align commands use the same icons as the
Left/Right align commands, respectively, but they are mirrored
automatically in RTL context to reflect the appearance of the text.
Unique icons may be added in a future commit.
Change-Id: I0fbf7039d2bc20e025af3d30c775f270354e5aca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194125
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
At EditEngine, ImpEditEngine, Outliner, OutlinerView
and EditView. Changed to more explaining names. Checked
parameters.
Change-Id: Iccf8ce82d2772cbd769269014e920739a11bece2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187483
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Implemented the ODF 1.0 style:script-type text property. This property
can be used by documents to influence which script type-dependent
attributes are used when rendering certain characters.
This implementation uses the following semantics:
- If unset, the behavior is as it was in previous versions.
- If set to latin, asian, or complex, those characters not mapped by the
ODF standard to a script type are treated as latin, asian, or complex,
respectively.
- If set to ignore, all characters will be treated as latin. This value
is intended to be used for interoperability with file formats that
don't implement script types (e.g. HTML).
Change-Id: If81a1390ee455fd971dea655d161d9c3f44fd08a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186309
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
There are two sets of getters there; and the non-const ones may copy
the COW mpImplFont, and may call its AskConfig.
The name overload is unfortunate. It is not obvious at the call site,
which of the two will be called; and what is different. IMO, the way
to fix it would be to keep only one set of getters (the const one),
and make the call to AskConfig explicit (in the places that set font
name, and know that resolution of other properties will be needed).
But in this change, I only rename the non-const getters, making sure
to keep the behavior unchanged (at least the intention is to have a
non-functional change, meaning that the places that called non-const
overload, now use the renamed functions), to make it clear where we
actually may copy and initialize it.
Change-Id: I9a5cd91d5c1c0de7ff8577b9b982d165e4cdd2c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183116
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
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>
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>
{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>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
properties that match the default are not exported, so we're basically
stuck with what is in there for compatibility with older versions, so
revert
commit ca46afebb7
Date: Tue Oct 4 16:22:51 2022 +0100
default to 'flat' instead of '3D Look' for form controls
and set m_nBorder to the desired new default in the ctor but
leave getPropertyDefaultByHandle as it always was
Change-Id: Ia862fc6851248fc9b16b3b4c505fdaf6fdb4b2ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151497
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
The variable type of nHeight was changed as the return type of
pFontHeightItem->GetHeight() is sal_uInt32.Also nBit was assigned
the underlying datatype of LB(int) as it was checked against
LB::LAST(Value converted to underlying datatype of LB) in the for loop .
Change-Id: I657d545ac7af1786edd61569ba43b42e55d1f47b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143145
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
you get one of these by starting with a normal text box form control
and changing its "text type" property to multi-line with formatting
Change-Id: If922b6b9fdc49b78fa379dbb3e5974a73f6095ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137933
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Noel Grandin