summaryrefslogtreecommitdiff
path: root/source/auxiliary/as/highcontrast2.css
diff options
context:
space:
mode:
Diffstat (limited to 'source/auxiliary/as/highcontrast2.css')
-rw-r--r--source/auxiliary/as/highcontrast2.css4
1 files changed, 2 insertions, 2 deletions
diff --git a/source/auxiliary/as/highcontrast2.css b/source/auxiliary/as/highcontrast2.css
index 0e31b90466..fd4f2ab032 100644
--- a/source/auxiliary/as/highcontrast2.css
+++ b/source/auxiliary/as/highcontrast2.css
@@ -28,10 +28,10 @@
body, p, h1, h2, h3, h4, h5, h6, .listitem, .listitemintable, .tablecontent, .tablecontentintable
- { font-family: "Albany AMT",Albany,Arial,"Nimbus Sans L","Bitstream Vera Sans",Helvetica,Lucida,Geneva,Helmet,"Andale Sans UI","Arial Unicode MS","Lucida Sans Unicode",Tahoma,sans-serif; }
+ { font-family: "Segoe UI",Ubuntu,Cantarell,"Noto Sans","DejaVu Sans","Lucida Sans Unicode","Helvetica Neue",Helvetica,Tahoma,sans-serif; }
pre, .code, .codeintable, .example, .exampleintable, .literal, .literalintable, .path, .pathintable
- { font-family: "Cumberland AMT",Cumberland,"Courier New","Nimbus Mono L","Bitstream Vera Sans Mono",Courier,"Lucida Sans Typewriter","Lucida Typewriter",Monaco,Monospaced; margin-top: 1pt; margin-bottom: 1pt;}
+ { font-family: Menlo,Consolas,"DejaVu Sans Mono","Nimbus Mono L","Lucida Sans Typewriter","Courier New",Courier,Monaco,monospace; margin-top: 1pt; margin-bottom: 1pt; }
.acronym
{ font-weight: bold;}
generated by cgit (git 2.34.1) at 2025-02-14 04:09:18 +0000
ption> LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/editeng/source/editeng/editdoc.cxx
AgeCommit message (Collapse)Author
3 daystdf#164685 Cleanup SfxItemSetFixed - Part 3rafaelhlima
This is the continuation of the cleanup of class SfxItemSetFixed, as described in the bug ticket. Change-Id: I567f985af181d326a6adb6c3d3af2a9e2fa8df34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180975 Tested-by: Jenkins Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
2024-11-29cid#1606728 Overflowed integer argumentCaolán McNamara
Change-Id: I6fef2b6818018b8a0f82125ef2d8220688d642a3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177536 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-11-28tdf#163913 Implement font-relative marginsJonathan Clark
This change adds loext:margin-left and loext:margin-right, which implement margins that support font-relative units. See tdf#36709 for additional details. Change-Id: I31b0dd2b6f98cb5b02fd4dca3608db6fdee4054c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177473 Tested-by: Jenkins Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
2024-11-24Let ESelection use EPaM for simplificationMike Kaganski
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
2024-11-13tdf#36709 editeng: Layout for font-relative first-line indentJonathan Clark
This change extends layout for font-relative paragraph first-line indentation into Edit Engine. Change-Id: I5906f493b91fbcb87ded165709fb132b33ce1906 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176487 Tested-by: Jenkins Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
2024-10-08cid#1606728 Overflowed integer argumentNoel Grandin
The problem here is that coverity thinks that ParaPortion::GetLineNumber can return -1, which it can, but only if things are already broken, so add an assert tbere. Change-Id: Iceea035edb49bb3e1e0a39a9b63a9176308346ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174621 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-10-08cid#1607133 Overflowed constantNoel Grandin
Change-Id: I63d1ca446491b8b376bb54e410b3d9edc543a734 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174619 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-07-30tdf#161846 avoid allocation in ContentNode::InsertNoel Grandin
which is fairly common Change-Id: I3b1ec65d880cb71b8894f292061e23376af177bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171224 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-07loplugin:ostr in editengNoel Grandin
Change-Id: I7353710e1558d486130ace09844ce97150eb4c43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167272 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-18ITEM: Rename for more control over SlotID usagesArmin Le Grand (allotropia)
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>
2024-02-12ITEM: ItemPool Rework (I)Armin Le Grand (allotropia)
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>
2024-02-12editeng: prefix members of ParaPortion & add some access methodsTomaž Vajngerl
Change-Id: I6be67530690d1d5ee1236d654dd65cc8545e95d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163224 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-27ITEM: Cleanup some Pool stuff with DefaultsArmin Le Grand (allotropia)
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>
2024-01-23ITEM: Solve SfxVoidItem(0) situationArmin Le Grand (allotropia)
An instance of SfxVoidItem(0) was used to signal the SfxItemState::DISABLED. This was done not only using WhichID == 0, but using isVoidItem() at the SfxPoolItem. Unfortunately this mixes up with usages of SfxVoidItems, mostly for UI stuff/Slots. This also means that all the time an SfxVoidItem had to be cloned/delete when when added/removed from ItemSet or ItemHolder. Much more action than e.g. for INVALID_POOL_ITEM which we already use by havong just a simple ptr to a single static instance of an Item. Disabled should do the same thing. Unfortunately also the functionality was mixed with non-SfxItemState::DISABLED purposes and these were very hard to be separated. But the current solution works now after some quirks doing that. It even oes no more need the isVoidItem() flag at the SfxPoolItem. Change-Id: I99f03db144f541ae4ea35f3775b3b3d58a375a81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162414 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-01-15editeng: return ParaPortion from the list as a ref.Tomaž Vajngerl
Change operator[] for getRef(..) method, so instead of returning a pointer, return a reference to ParaPortion instead. This also needs changes to the code, because we now need to make sure before hand that the ParaPortion is really available in the list and when this is not possible or convenient, the change the call to use existing "SafeGetObject" instead. Add "exists" to check if the object is available in the ParaPortionList. In addition add "lastIndex" method to return the index of the last ParaPortion in the list (shortcut for Count() - 1). Change-Id: Id52c38f996468af51c75d50185110ec8502169e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162071 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-14ITEM: Move Shareable ItemFlag to SfxPolItemArmin Le Grand (allotropia)
Currently a Pool-Attribute (in SfxItemInfo), but should be a SfxPoolItem property. Originally 'moved' from old 'poolable' used as hint. I identified needs more general and moved it to where it belongs. Also reworked SfxItemInfo to no longer have/support single bollean flags, but a FlagVariable and defined SFX_ITEMINFOFLAG_* entries to access these, that will make future changes easier without having to change all palces where these get defined over and over again. Added CheckItemInfoFlag for gereral access to that flag and e.g. NeedsSurrogateSupport to directly check for the SFX_ITEMINFOFLAG_SUPPORT_SURROGATE flag as syntactical sugar, that makes the intention clear. Change-Id: I09c238c7c5b7f721b657d7b0a44dbc8d14e02528 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161982 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-01-10editeng: move for loop to range basedTomaž Vajngerl
Change-Id: I6d997d6315f8d5043de33fe43b6aaabf5bef7cdd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161820 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-02editeng: remove operator[] for EditDoc (use GetObject instead)Tomaž Vajngerl
Change-Id: Ie41d2baf84d230b9ee280859d390e24b9da70be7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161482 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-02editeng: better lifecycle control for ContentNode in EditDocTomaž Vajngerl
Don't use raw pointers, when it is possible to move the unique_ptr around into another object that is responsible for the object's ownership. The ContentNode is either in a vector in the EditDoc class or it is moved to the EditUndoDelContent class for the undo/redo action. Those 2 classes are responsible for freeing the ContentNode. Change-Id: I977d8e418947bb48781f23575d62420260025e57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161480 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-01editeng: make it clear EditDoc is responsible for ContentNodesTomaž Vajngerl
Change-Id: I38b9b1a5ba48d73438865f5a040f2483f6814c40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161479 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-01editeng: prefix members of EditDocTomaž Vajngerl
Change-Id: I403db061b6e3e184e97c5ec3ce5746d2fdff0749 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161478 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-01editeng: simplify constr. and destr. of ParaPortion{List}Tomaž Vajngerl
Change-Id: I8f7e242b66463baa9adcc0dee8eb8f4206630c7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161477 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-01-01editeng: move impl. of TextPortionList methods to own cxx fileTomaž Vajngerl
Also move some simple methods to header file and clean-up the constructors and destructors. Change-Id: I5113d785ecc71d36b4c6a480b15427ca68eb2e0b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161474 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-31editeng: cleanup operators and constructors for EditSelection + testTomaž Vajngerl
Move the constructors into class body, cleanup operators so they use more standard class based operators and use default for != as it will just be a neagtion of ==. Change-Id: I1b99db6c9a82468ab76091eb93a5f3641024c65b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161365 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-31editeng: cleanup operators and constructors for EditPaM + testTomaž Vajngerl
Move the constructors into class body, cleanup operators so they use more standard class based operators and use default for != as it will just be a neagtion of ==. Change-Id: I6534db60dcb23cb3daefb91d5f27579a690a9637 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161364 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-30editeng: move EditLineList methods definition into headerTomaž Vajngerl
Class is simple enough and more or less just wraps the vector anyway. Change-Id: I65a2980e8dd3c70b87e617920db623782d43b1b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161361 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-30editeng: move impl. of EditLine methods to own cxx sourcefileTomaž Vajngerl
Change-Id: I9856302967de59368dc60b3e01f4a36fdb97e00e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161359 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-30editeng: EditLine test and refactor constructors, operatorsTomaž Vajngerl
Change-Id: Ia60ce07073725bf66bf299edaf7b3cd24cfe59c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161358 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-29editeng: move source of ContentNode & co. to own sourcefileTomaž Vajngerl
Move ContentNode, CharAttribList, ContentAttribs methods to own source class. Change-Id: Idd1371430ecaf36431de763dc4e3e3978ba60641 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161355 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-29editeng: prefix members of ContentNode, CharAttribList, ContentAttribsTomaž Vajngerl
Change-Id: I2af96b6525ee0d4410200775ce4daf71bcc80db4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161354 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-29editeng: ItemList - prefix members, move methods in classTomaž Vajngerl
- Move methods into class def. as the class is simple enough. - Prefix member variables. - Remove unneeded includes. Change-Id: Ide567c64dad3606f1a9faf837571ae2a5c3d69ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161352 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-29editeng: move TextPortion to own header fileTomaž Vajngerl
Change-Id: I54d0bbad4ef142705191672319774f26abf3e735 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161348 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-11-25tdf#158317 fix cleanup of SfxPoolItems in editengArmin Le Grand (allotropia)
It is not possible to use implCreateItemEntry/implCleanupItemEntry, that is tooling limited *by purpose* to svl/Item/ItemSet stuff. But what I can do is to do that SfxPoolItemHolder I already talked/thought about. It is a helper that can safely hold a SfxPoolItem in cases where an SfxItemSet is too expensive. Think about it as a SfxItemSet for a single item. That solves the problem why DirectPutItemInPool/DirectRemoveItemFromPool is used in general (each usage is a 'compromize'). Did that now, works well. Editengine is now free of DirectPutItemInPool/DirectRemoveItemFromPool. Replaced ::CursorMoved with checkAndDeleteEmptyAttribs since all these got static with no longer need to DirectRemoveItemFromPool. Corrected create/delete counters. Change-Id: Ia6e53f48ac2e479b461546515e68697039b5b628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159931 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-18c++20: use std::erase(_if) instead of std::remove(_if)+erase (part 4)Julien Nabet
Change-Id: I6af5501e3fde07024dcc74f00c8fd69bd369d8d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159613 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-07ITEM: Get away from classic 'poolable' Item flagArmin Le Grand (allotropia)
To understand this, some look back in history will be needed to see why it is as it is today. In some (reworked) comments 'poolable' is described as flag to hold Items in the ItemPool, also always having only one incarnation of each possible Item. This is not the original intention, but a side-effect. The reason is what the binary format in the office did: To save a document, the Objects & the Pool were saved, *not* individual Items *together* with the objects. The Pool was completely (binary) saved (and loaded) in one run. Temporary IDs were used to represent at the objects in file which Items were referenced. This *required* to have only one incarnation per item to have a minimal binary file size, thus this high effort was put into this. At doc load, the pool was loaded, all Items were set to RefCount 5000, the references from the objects were restored and then for each Item the RefCount was lowered by 5000 again and - if being zero - deleted. Items for UI were marked 'non-poolable' to *not* safe them with the document, so poolable was a flag to decide if that Info/Item was to be saved with the document - or more direct: if it is Model Data. Items are small, so if we prefer runtime it is okay to no longer being strict with this, anyways does not happen often and has only marginal memory effects - compared to runtime effects/savings. Other problems which this caused: One example is that objects in the UNDO stack were still in the pool, so e.g. deleted pictures were saved with the document despite no longer being used (!). That is the reason we have an UndoItemPool and a method MigrateItemPool to move stuff to that Pool when objects go to the UNDO stack - all of this is also no longer needed. Cleaning this up means to ideally have all items in the SfxItemSet, no longer at the Pool. The Pool should be reduced to a 'Default-Item- Holder' and a 'Slot-to-whichId-mapper'. This needs thorough cleanups/removals, but will be worth it because that massive simplification(s) will increase safety an runtime and make migrating to the goal of completely type-based ItemSet stuff easier for the future. Hopefully only view code in the office working with items will have to be changed for this. In this 1st step I already found that some 'compromizes' will be needed: - There are still Items that have to be at the pool to make the Surrogate-stuff working. This gives back all Items in a Pool of a type and is used in ca. 80 cases. Each one looks at these Items *without* context (e.g. a SfxItemSet at an Object would be a context), so if e.g. a dialog is open that temporarily uses Items of that type you would also get these - without knowing about it... To make that work there is still a mechanism to have Items at the Pool, but now just *registering* (and un-reg) them without any sort/search/ remove needs. Also only for Items that need that, so I evaluated the GetItemSurrogates calls and added some asserts when GetItemSurrogates tries to access an unregistered item type which needs to be added. - Another caveat is that there are about 250 places that directly put Items to the Pool (not all remove these, that is done at pool deletion, so some kind of silent 'garbage-collection' is in place). To have an overview I renamed the accessing methods to separate them from the same functionality at the SfxItemSet, which had the same names. An implementation does still add these directly to the pool, there is no way to cleanup those usages for now. In principle all these should be changed to hold the data at an SfxItemSet. I am still hunting problems. But you can build the office, all apps work (including chart) and you can do speed comparisons already. There are test throwing errors, so I hunt these now. It is hard to give an estimation about how much more changes/corrections will be needed. Completed adaptions to new registered Items at Pool, that reduces the failing tests. Still many that I need to hunt. Added stuff to work around that 'compromize' in ScDocumentPool: It overloads ::PutImpl of the pool to implement special handling for a single Item in SC, the ScPatternAttr. In former code that method was used from SfxItemSet and ::PutImpl at the pool directly, so it was only used in one place. I am not sure if it was used from the SfxItemSet functionality, but better offer it for now. To not waste too much runtime the callbacks depend on the boolean 'NewItemCallback' at the SfxPoolItem, it gets set for that single Item in SC and only then the callbacks trigger. I hope to get rid of those again, e.g. newItem_UseDirect is only needed since we have no 'real' StaticPoolDefaults currently - another thing that needs to be cleaned up in a next step. Since usages of impl(Create|Cleanup)ItemEntry and Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it globally available in svl and use it also directly for Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that fallback (e.g. tryToGetEqualItem) was used before, thus this is the same class of errors (SfxPoolItem ptr-compare) as the others which I will need to find anyways. Also fixed some missing stuff. Have now idenified and redirected all SfxPoolItem ptr-compares to be able to debug these - one cause for the remaining errors is probably that before with bPoolable those often were sufficient, but are no longer. Used the [loplugin:itemcompare] and a local clang build to do so, see https://gerrit.libreoffice.org/c/core/+/157172 Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter to implCreateItemEntry to signal that it gets called from DirectPool stuff - currently needed. Hopefully when getting rid of that DirectPool stuff we can remove that again Added two more debug functionalities: - Added a SerialNumber to allow targeted debugging for deterministic cases - Added registering & listing of still-allocated SfxPoolItems at office shutdown Found PtrComp error in thints.cxx - POC, thanks to areSfxPoolItemPtrsEqual. Will hopefully help more with other tests Found some wrong asserts/warnings where I was too careful and not finding something/succeeding is OK, fixes some UnitTests for SC For SC I now just tried to replace all areSfxPoolItemPtrsEqual with the full-ptr-content compare SfxPoolItem::areSame. I also needed to experiment/adapt the newItem_Callback solution but got it working. Did that replacement now for SW too, found some places where the direct ptr compare is OK. Continued for the rest of occurrences, now all 160 places evaluated. Also done some cleanups. Massive cleanups of stuff no longer needed with this paradigm change. Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now. It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that already needs many exceptions. Also useful for testing if errors come up on this change to test if it is related to this. Added forwarding of target Pool for ::Clone in SvxSetItem and SvxSetItem, simplified SfxStateCache::SetState_Impl and returned to simple ptr compares in SfxPoolItem::areSame to not do the test in areSfxPoolItemPtrsEqual. Debugged through UITest_calc_tests9 and found that in tdf133629 where BoxStyle is applied to fully selected empty calc the Item- reuse fallback has to be used not only for ATTR_PATTERN, see comment @implCreateItemEntry. Maybe more... Problem with test_tdf156611_insert_hyperlink_like_excel. Found that in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField is found and returned as ptr, but it's usage crashes. That is due to the SfxItemSet aEditSet used there gets destroyed at function return what again deletes the SvxFieldItem that is holding the SvxURLField that gets returned. This shows a more general problem: There is no 'SfxPoolItemHolder' that safely holds a single SfxPoolItem - like a SfxItemSet for a single Item (if Items would be shared_ptrs, that would be a safe return value). That will be needed in the future, but for now use another solution: Since I see no reason why EE_FEATURE_FIELD should not be shareable I wil change this for ow in the SfxItemInfo for EditCharAttribField. That way the Item returned will be shared (RefCnt > 1) and thus not be deleted. I changed the return value for GetURLField() and GetFirstURLFieldFromCell() in ScEditShell: At least for GetFirstURLFieldFromCell the return type/value was not safe: The SvxFieldItem accessed there and held in the local temporary SfxItemSet may be deleted with it, so return value can be corrupted/deleted. To avoid that, return a Clone of SvxFieldData as a unique_ptr. With all that UnitTest debugging and hunting and to get the paradigm change working to no longer rely on shared/pooled items I lost a little bit focus on speed, so I made an optimization round for the two central methods implCreateItemEntry/implCleanupItemEntry to get back to the speed improvements that I detected when starting this change. It was mainly lost due to that 'strange' chained pool stuff we have, so I added to detect the target pool (the one at which the WhichID is registered) directly and only once. Next thing to cleanup will/should be the pool and it's concept, all this is not needed and really costs runtime. Since implCreateItemEntry/implCleanupItemEntry are executed millions of times, each cycle counts here. Had an error in the last changes: pool::*_Impl methods use index instead of WhichID - most of them. Another bad trap, I really need to cleanup pool stuff next. Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>