/desktop/scripts/

stro/cib/libreoffice-5-1'>distro/cib/libreoffice-5-1 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/svx/source/dialog/dlgctl3d.cxx
AgeCommit message (Collapse)Author
2024-05-11loplugin:ostr in svxNoel Grandin
Change-Id: Ia765a03e033acb82e367873380d289587ea87d6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167449 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-03-03Resolves: tdf#159879 Crash when closing "3D View" dialogCaolán McNamara
Change-Id: I9c116007afe9cea97b597933ad8483dce25c3707 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164295 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.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>
2022-10-20fix assert in debug modeNoel Grandin
not actually a leak, just a deletion ordering problem warn:svx:29983:29983:svx/source/svdraw/svdmodel.cxx:200: SdrModel::~SdrModel: Not all incarnations of SdrObjects deleted, possible memory leak warn:svx:29983:29983:svx/source/svdraw/svdmodel.cxx:202: leaked instance of 12E3dSphereObj warn:svx:29983:29983:svx/source/svdraw/svdmodel.cxx:202: leaked instance of 8E3dScene soffice.bin: /home/noel/libo/svx/source/svdraw/svdmodel.cxx:204: virtual SdrModel::~SdrModel(): Assertion `maAllIncarnatedObjects.empty()' failed. Change-Id: Ia0e6e1387825c0d849904b1bc604eb1252090318 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141543 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-03-11new loplugin:trivialdestructorNoel Grandin
look for potentially trivial destructors that can then be elided Change-Id: I435c251bd4291b5864c20d68f88676faac7c43fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131318 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-03Recheck modules sv* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I25779cbfb1aa93c31d6e12ac95e136b3bdbbc058 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130403 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-11-19Drop F_2PIMike Kaganski
Change-Id: Ie98606607b2ce262e4eed76bb8cd86fbfe846f76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125506 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-19Use M_PI* instead of F_PI*Mike Kaganski
Change-Id: Ie2b7a1c74fc516781a17a20157b8217bc41e383d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125504 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-16Use basegfx::deg2rad instead of *0.01745329251994Hossein
* Replaced multiplying by magic number 0.01745329251994 with basegfx::deg2rad() which is equal to M_PI/180.0 * Instances of this could be found using: git grep 0.01745329251994 *.cxx *.hxx Change-Id: Ib813251f6223e4218fe977c0211732c22199295d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125294 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>