lo/translations - LibreOffice 界面翻译代码仓库

Age	Commit message (Expand)	Author
2013-05-25	initial import of 4.1 translations	Andras Timar
2013-05-07	update translations for LibreOffice 4.0.3 rc1	Andras Timar
2013-01-06	update translations for LibreOffice 4.0 rc1	Andras Timar
2012-12-16	update translations for LibreOffice 4.0 beta2	Andras Timar
2012-12-03	update translations for LibreOffice 4.0 beta1	Andras Timar
2012-11-20	initial import of LibreOffice 4.0 translations	Andras Timar
2012-10-16	move translations structure one directory up	Norbert Thiebaud

Age	Commit message (Collapse)	Author
2023-12-22	Remove DeleteItemOnIdlex	Armin Le Grand (allotropia)
	There are some CrashReports in 7.6 which have DeleteItemOnIdle on the stack, but there is nothing reproducable. So I took a look... I first thought it's a MCGR regression, due to classes on the stack. But the Item involved is just random, can happen with any Item. Then I thought it may have to do with ITEM refactorings, but it happens with DeleteItemOnIdle involved, so also not the case. I already saw DeleteItemOnIdle when doing these and qualified as 'hack' in the way. already It is only on Windows and DeleteItemOnIdle is involved. This again (took a deeper look now) is an old hack to keep an SfxPoolItem 'alive' for some 'time'. For that, it triggers an async reschedule which then deletes the Item when being called. If the Item will be used after that is pure coincidence - seems to work in most cases. It seems as if for Windows the timing slightly changed for some scenarios, so a reschedule is too early. This can happen with this hack anytime. DeleteItemOnIdle is used in scenarios where SfxPoolItem* is e.g. returned, but is not anchored, so e.g. not member of an SfxItemSet. Or in short: Lifetime is not safe. DeleteItemOnIdle exists since 1st import, but was changed to AsyncEvent ca. 4 months ago (see 57145acf9ec47c23e307b7a5c0029d21d937cc35), so that may have caused it. It is possible that these errors happen on Windows since then. Before something more complicated was used to delete it late, but surely also not really safe. Due to ITEM refactor I have the knowledge/tooling to solve this. It will not be a 1-5 lines fix, but it is a hack and in the way for further ITEM refactor anyways. What we have nowadays is a SfxPoolItemHolder -> it's like an SfxItemSet for a single Item. It safely holds/ controls the lifetime of an SfxPoolItem. It is already used in quite some places. It helps to solve many hacks, also the ones putting Items directly to the Pool - due to there never was an alternative for that. In principle the ItemPool/ItemSet/Item paradigm was never complete without SfxPoolItemHolder. Thus I started to fix that (and remove that hack for good, sooo many changes over the years, sigh), but as said is not straightforward. Will have to change retvals of involved stuff to SfxPoolItemHolder - it's just two pointers and designed to be copied (one is a Pool, needed to cleanup when destructing). CopyConstruct/destroy just counts the RefCnt up/down, so cheap. 1st version compiling, let's check on gerrit... Corrected one error in QueryState for securitypage, also added some security features/asserts. Change-Id: Ida49fd35ca88ead84b11d93e18b978cb9e395090 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161083 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> (cherry picked from commit 789a737ac92c4f2b0eb9820b99c43cc8253c8b29) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161158 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-11-21	Cleanup some ScPatternAttr specific stuff	Armin Le Grand (allotropia)
	Removed some special stuff in the ItemSet/Item tooling regarding ScPatternAttr. There are still quite a view (grep for isExceptionalSCItem), but all these are identified and isolated. Only for that Item (of over 500) are these exceptions, so that raelly does not fit into the Item schemata in any way. Not even the pool default of ScPatternAttr is without trouble. It is the only and last Item that needs to be 'pooled' in the sense to avoid copies on any price. That is OK, but should not be done in the ItemSet schemata. In short: It should not be an Item at all. It should be changed and renamed to something describing it's role (CellAttributes..?) and get helped/assisted by something called CellAttributeHelper at SC's model or Pool. It should not even be derived from SetItem, it could just contain an shared_ptr of SfxItemSet (allows more and better optimizations - think about Clone() and op==). In parallel, all these hacks in the ItemSet/Item stuff could be removed, making that faster and easier. Also quite some usages of DirectPutItemInPool could be cleaned-up, this only exists since there is no defined place to hold that data (coud be CellAttributeHelper in the future). Putting Items directly to the pool (and in most cases never remove them again) is just nonsense and another hint that all this does not fit to the Item/ItemSet schema at all. This is now - after hard isolation of problems and have all working - doable. It may be one of the next things to do, but there are other candidates, too. Doing this would mostly only help SC... Found another hack that uses DirectPutItemInPool and never removes any Item again, see comments framelinkarray.cxx And another one: PoolItemTest::testPool() explicitely tests DirectPutItemInPool stuff - which makes no sense long-term, but for now keep it and make it work by marking the slots used as _bNeedsPoolRegistration == true Have now overhauled the framelinkarray stuff to work without DirectPutItemInPool and Cell not being a SfxPoolItem. That will be much less complex and use much less calls/checks. Since this is the data structure created for every calc repaint that should get faster, too. Also for now and memory loss security I added code to DirectPutItemInPool to behave the same as with the unchanged implCreateItemEntry: register Items so that the garbage collection still is used. This will/can be removed when all usages of DirectPutItemInPool is cleaned up. Directly registering in DirectPutItemInPoolImpl is more tricky than thought, but a good thing to do. Looking at that I saw that tryRegisterSfxPoolItem is not used anymore, so rearranged some stuff. Change-Id: If07762b0a25e2739027f81872441772dc82a25d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159685 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-08	Avoid initialization-order-fiasco in DBG_UTIL code	Stephan Bergmann
	...as reported by <https://ci.libreoffice.org/job/lo_ubsan/2973/> during e.g. Gallery_backgrounds, when initializing the global variable > const Cell OBJ_CELL_NONE; at svx/source/dialog/framelinkarray.cxx:281, > ==519895==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7fb3dc3e5570 at pc 0x7fb3daee1c56 bp 0x7ffe54584480 sp 0x7ffe54584478 > READ of size 8 at 0x7fb3dc3e5570 thread T0 > #0 0x7fb3daee1c55 in std::_Hashtable<SfxPoolItem const, SfxPoolItem const, std::allocator<SfxPoolItem const>, std::__detail::_Identity, std::equal_to<SfxPoolItem const>, std::hash<SfxPoolItem const>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::bucket_count() const /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/hashtable.h:673:16 > #1 0x7fb3daee1648 in std::__cxx1998::unordered_set<SfxPoolItem const, std::hash<SfxPoolItem const>, std::equal_to<SfxPoolItem const>, std::allocator<SfxPoolItem const> >::bucket_count() const /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/unordered_set.h:755:21 > #2 0x7fb3daeb1088 in std::__debug::unordered_set<SfxPoolItem const, std::hash<SfxPoolItem const>, std::equal_to<SfxPoolItem const>, std::allocator<SfxPoolItem const> >::insert(SfxPoolItem const&&) /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/unordered_set:369:35 > #3 0x7fb3db01987c in SfxPoolItem::SfxPoolItem(unsigned short) /svl/source/items/poolitem.cxx:506:28 > #4 0x7fb3cb2fddb4 in svx::frame::(anonymous namespace)::Cell::Cell() /svx/source/dialog/framelinkarray.cxx:204:5 > #5 0x7fb3cafa3b6f in __cxx_global_var_init.1 /svx/source/dialog/framelinkarray.cxx:281:12 > #6 0x7fb3cafa3ba9 in _GLOBAL__sub_I_framelinkarray.cxx /svx/source/dialog/framelinkarray.cxx > #7 0x7fb3e6821f19 in call_init.part.0 /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:72:3 > #8 0x7fb3e6822019 in call_init /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:118:11 > #9 0x7fb3e6822019 in _dl_init /usr/src/debug/glibc-2.28-225.el8_8.6.x86_64/elf/dl-init.c:119:5 > #10 0x7fb3e6836cb9 (/lib64/ld-linux-x86-64.so.2+0x1dcb9) > > 0x7fb3dc3e5570 is located 48 bytes inside of global variable 'incarnatedSfxPoolItems' defined in '/home/tdf/lode/jenkins/workspace/lo_ubsan/svl/source/items/poolitem.cxx:473:47' (0x7fb3dc3e5540) of size 96 > registered at: > #0 0x43c078 in __asan_register_globals.part.0 /home/tdf/lode/packages/llvm-llvmorg-12.0.1.src/compiler-rt/lib/asan/asan_globals.cpp:360:3 > #1 0x7fb3db01e7cb in asan.module_ctor (/instdir/program/libsvllo.so+0xb3c7cb) Change-Id: I490fb232e0944f18c49b734c621e1bf0c318baff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159120 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-07	ITEM: Get away from classic 'poolable' Item flag	Armin 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>
2023-09-29	ITEM: Correct handling of Items in sw	Armin Le Grand (allotropia)
	...that use internally an sw::BroadcastingModify*. This caused an error/crash with the testfile ooo58307-1.sxw, thanks to Caolan to find it. For BG info please see comments in the changed sw/source/core/attr/swatrset.cxx Change-Id: Ia91fff19ffb39873c7e2bd5ff8806b95fc5ac7ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157383 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-09-11	ITEM: Diverse further changes/cleanups/preparation	Armin Le Grand (allotropia)
	Added a counter for SfxItemSet usages, similar to the already added one for SfxPoolItems to allow quick info about evtl. problems/drawbacks of changes. Replaced enum SfxItemKind in favour of settable boolean flags directly at SfxPoolItem. These are organized as bitfield, do not need more space as the enum and allow to be set separately and multiple ones at the same time. Flags for PoolDefault/StaticDefault/DeleteOnIdle use this now and are quickly accessible booleans. It is not a problem that theoretically the flags for PoolDefault/StaticDefault could now both be set - this is internal to SfxItem stuff and not accessible from normal code, so can be managed. Added for debug build a bitfield boolean m_bDeleted that will be set in the SfxPoolItem destructor. Of course it's usability will depend on the freed space not yet being re-used, but will hopefully help in the debugger to detect reasons for failure (would have helped at least me before). Added for replacement of virtual method IsVoidItem() another bitfield bool m_bIsVoidItem that is set in the constructors of SfxVoidItem. Also had to add some constructors to do that which were defaulted before. This is mainly because the base class SfxPoolItem does not have a copy-constructor that copies the members (flags/RefCnt/WhichID) and we should keep that 'indirect reset' when Cloning. isVoidItem() is now a simple boolean member access - the bitfield does the needed masking. This spares one entry in the virtual function table of SfxPoolItem which is derived more than 500 times. Used the results of the experiment at https://gerrit.libreoffice.org/c/core/+/156774 to change some accesses to IsVoidItem() to use SfxItemState instead. This is for preparation of splitting up the two usages of SfxVoidItems, see commit text in the experiment. If this shows problems in the future those six places documented there may have to be changed back to use the new isVoidItem(), but should also check the ptr this time to be non-zero. Removed SFX_ITEMS_SPECIAL that is no more used anywhere. Change-Id: Ib687ca2362d72a4651c75aee0c67029088f68947 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156805 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-08-18	ITEM: preparations for more/easier changes	Armin Le Grand (allotropia)
	This change is not about speed improvements but diverse preparations to make changes/reading/understanding easier. It does not change speed AFAIK. Added a global static debug-only counter to allow getting an overview over number of all allocated SfxPoolItem's and the still alloated ones at office shutdown. The values are used in Application::~Application to make a short info statement. It allows to be able to quickly detect if an error in future changes may lead to memory losses - these would show in dramaitically higher numbers then (hopefully) immediately. Moved SfxVoidItem to own source/header. Added container library interface support to SfxItemSet, adapted already some methods to use it - not all possible, I will commit & get status from gerrit 1st if all still works and then continue. Changed INVALID_POOL_ITEM from -1 to use a global unique incarnation of an isolated derivation from SfxPoolItem. It allows to avoid the (-1) pointer hack. Since still just pointers are compared it's not worse. NOTE: That way, more 'special' SfxPoolItem's may be used for more States - a candidate is e.g. SfxVoidItem(0) which represents ::DISABLED state -- unfortunately not only, it is also used (mainly for UI stuff) with 'real' WhichIDs - hard to sort out, will have to stay that way for now AFAIK. Changed INVALID_POOL_ITEM stuff to use a static extern incarnated item in combination with a inline method to return it, called GetGlobalStaticInvalidItemInstance(). Isolated create/cleanup of a SfxPoolItem entry in SfxItemSet to further modularize/simplify that. It is currently from constructor & destructor but already shows that PoolDefaults are handled differently - probably an error. Still, for now, do no change in behaviour (yet). Got regular 'killed by the Kill-Wrapper' messages from gerrit, seems to have to do with UITest_sw_findReplace. That python/c++ scripting stuff is hard to debug, but finally I identified the problem has to do with the INVALID_POOL_ITEM change. It was in SfxItemSet::InvalidateAllItems() where still a (-1) was used -> chaos in detecting invalid items. Change-Id: I595e1f25ab660c35c4f2d19c233d1dfadfe25214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155675 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-08-03	move SwVirtPageNumInfo to SfxHint	Bjoern Michaelsen
	- also remove now obsolete GetInfo overrides Change-Id: Iaac75ed2e53daead06242ce4620fd2b879909e02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155061 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2023-07-19	Cleanup SfxApplication::Get/SetOptions, and drop unused SIDs	Mike Kaganski
	The removed stuff was never used elsewhere; e.g. all uses of GetOptions use Which Ranges that don't include the removed identifiers. Elements removed from SetOptions weren't passed to that function from anywhere. Change-Id: Id81b57014b82f89538a46a609f3e4b328864bbcf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154604 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-06-01	sw doc model xml dump: show address of SfxBoolItems	Miklos Vajna
	I want to know when a relevant keep-with-next pool item is read, but there are many of them, so seeing the pointer address is helpful. Change-Id: I5ff7654430a41eaea6c7b0cf722e34256cdd4d3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152480 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-02-25	refactor DocPosUpdate, part 2	Bjoern Michaelsen
	- separate the message send from the field manager to the fields containing no start index from those send from the field to the frames containing an index - use member functions where possible: SwFieldType, SwFormatField, SwTextNode Change-Id: I488e4003b75bf7b0ae700f39e2364d6e34a8bbfc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147490 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2023-02-15	clean up SwRefMarkFieldUpdate a bit	Bjoern Michaelsen
	- remove SwRefMarkFieldUpdate: * it has only one unused field * replace with a plain SwPtrMsgPoolItem - hint constness: * SwUndoFieldFromDoc: make ctor arg hint const * DocumentFieldsManager: make UpdateField arg hint const * however, seeing this hint is: a/ constructed on the stack, but b/ stored as pointer in undo likely it would be best to remove it altogether. For now, make it at least static, so that there is no use after free. Change-Id: Ica51a2a2ce19e1938c3a367e9b4a9e01bbb75374 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147030 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2022-09-25	unwrap SwDelChr to plain SfxHint	Bjoern Michaelsen
	Change-Id: Ief37a8025181b6cc8a6e484e2726d8a8d92f57ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140567 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2022-09-25	unwrap SwInsText to a plain SfxHint	Bjoern Michaelsen
	- also add some constnesss and move some things to private Change-Id: I67a45e1326361b5a8f7e320b3525e74e93b1ef12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140556 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2022-09-24	unwrap SwDelText to a plain SfxHint	Bjoern Michaelsen
	Change-Id: I559f8f1e837830426e820dace6226618c5e0fc62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140210 Tested-by: Jenkins Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
2022-06-16	tdf#128150 Add OOXML import/export for "use background fill"	Samuel Mehrbrodt
	and allow editing this fill property in area dlg Change-Id: Ic63ba11e9d499d4a0fb22f6739587e3e25140b8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134406 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>