aboutsummaryrefslogtreecommitdiff
path: root/source/he/sc
ModeNameSize
d---------source60logplain
d---------uiconfig / scalc32logplain
value='feature/propose-master-cib'>feature/propose-master-cib LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/chart2/source/controller/drawinglayer/ViewElementListProvider.cxx
AgeCommit message (Collapse)Author
2024-03-27tdf#146619 Remove unused #includes from C/C++ filesRafał Dobrakowski
'chart2' module was cleaned. Change-Id: Ib4cdb3c8a21d0ed47f4970894d416327df5e68a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164864 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
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>
2022-08-29ref-count SdrObjectNoel Grandin
Which means we can get rid of the majestic hack of ScCaptionPtr Previously, SdrObject was manually managed, and the ownership passed around in very complicated fashion. Notes: (*) SvxShape has a strong reference to SdrObject, where previously it had a weak reference. It is now strong since otherwise the SdrObject will go away very eagerly. (*) SdrObject still has a weak reference to SvxShape (*) In the existing places that an SdrObject is being deleted, we now just clear the reference (*) instead of SwVirtFlyDrawObj removing itself from the page that contains inside it's destructor, make the call site do the removing from the page. (*) Needed to take the SolarMutex in UndoManagerHelper_Impl::impl_clear because this can be called from UNO (e.g. sfx2_complex JUnit test) and the SdrObjects need the SolarMutex when destructing. (*) handle a tricky situation with SwDrawVirtObj in the SwDrawModel destructor because the existing code wants mpDrawObj in SwAnchoredObject to be sometimes owning, sometimes not, which results in a cycle with the new code. Change-Id: I4d79df1660e386388e5d51030653755bca02a163 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan Bergmann
...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>
2022-05-05loplugin:unusedvariableplusNoel Grandin
Change-Id: Id93086be1224b6f6bf0bdaa1d50b4f289099027e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133876 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-01-03add new SvxShape hierarchy classNoel Grandin
to serve as a shared/common base class, so I can plumb SvxShape types through chart2. Change-Id: I8758fff1599c92a214b334ee44cf7b4e582c1915 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127873 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-30use concrete types in chart2, SvxShapePolyPolygonNoel Grandin
Change-Id: Ica53484d44e6992278b8d188ffb536e238aeb195 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127725 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-28no need to allocate these on the heapNoel Grandin
Change-Id: Ic1a1577ed837d3fa2b7b99474f4cee30300628f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116290 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-07ref-count SdrPageNoel
which simplifies ownership handling, particularly with regard to undo/redo Change-Id: Ie8f300ebfdae6db3c06f78a87e35a07497d6b825 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111991 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-28New loplugin:unsignedcompareStephan Bergmann
"Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-21tdf#42949 tdf#119699 Fix IWYU warnings in chart2/Gabor Kelemen
* Recheck after recent refactorings and improvements in f-u-i * Drop now unused TabPageIds.h * The problem noticed in bug #119699 now seems to be gone too so drop those lines from the blacklist. Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I44f26c7370f5328c8f67ac61cd8f0cdb29077f15 Reviewed-on: https://gerrit.libreoffice.org/83182 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-08-23Mark move ctors/assignments noexceptMike Kaganski
This should enable using move semantics where possible e.g. in standard containers. According to https://en.cppreference.com/w/cpp/language/move_constructor: To make strong exception guarantee possible, user-defined move constructors should not throw exceptions. For example, std::vector relies on std::move_if_noexcept to choose between move and copy when the elements need to be relocated. Change-Id: I6e1e1cdd5cd430b139ffa2fa7031fb0bb625decb Reviewed-on: https://gerrit.libreoffice.org/77957 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-07-19loplugin:referencecasting in canvas..chart2Noel Grandin
Change-Id: I3a3671b5c44d1a7e5ca320d3d76dd5d902382cbc Reviewed-on: https://gerrit.libreoffice.org/75935 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-14loplugin:logexceptionnicely in chart2Noel Grandin
Change-Id: Ib7933723e5506578bbc85cc431d54d1ed8466376 Reviewed-on: https://gerrit.libreoffice.org/74019 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-02-11tdf#120703 PVS: remove obsolete check (leftover from static removal)Mike Kaganski
V560 A part of conditional expression is always true: !pSymbolList. In commit a2cd17d19085d739b979445d7f9ec7158b89df49, pSymbolList and xSymbols were made non-static. The check below was left though. Actually, I don't know if that was a safe move, since it's unclear how the lifetime of the returned pointer is managed now to prevent use-after-free. Change-Id: Ia51a9790503694f909ce7953337d3caaebfabfc1 Reviewed-on: https://gerrit.libreoffice.org/67512 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-12-14tdf#42949 Fix IWYU warnings in chart2/source/controller/*/cxx (1)Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Cleaned directories are: accessibility, drawinglayer, itemsetwrapper, main, sidebar Change-Id: I612eae9dec636d57a3a3a00102d74b964da5b54c Reviewed-on: https://gerrit.libreoffice.org/64307 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2018-10-17clang-tidy readability-redundant-smartptr-getNoel Grandin
redundant get() call on smart pointer Change-Id: Icb5a03bbc15e79a30d3d135a507d22914d15c2bd Reviewed-on: https://gerrit.libreoffice.org/61837 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-09-06loplugin:simplifyconstruct in canvas..cuiNoel Grandin
Change-Id: I02eba1df117a9d0df42bcac13c3251cb4fa6da14 Reviewed-on: https://gerrit.libreoffice.org/60074 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>