summaryrefslogtreecommitdiff
path: root/chart2
AgeCommit message (Collapse)Author
2024-03-08tdf#159456 - chart view: fix wrongly shifted value Y axisBalazs Varga
We only have to shift the category axis only, and not the value axis, if we have a chart data table. Change-Id: Ie77ea829e8f8987702dce7d17cb3e20054f3d8cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164539 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-03-08tdf#159422 - chart view: fix symbols position of data table legendBalazs Varga
Calculate the correct/optimal row height after calculating and set correct width of a table cell. Then we will have the correct row height for the symbol positions. Change-Id: I65bc0f0579ea100906b0b32449c2200a54c2a353 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164512 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-03-08tdf#159443 - chart view: fix Data table is not rendered below chartBalazs Varga
If we have 1 dataseries we will have no tickmarks, in that case the distance between two tickmarks is the width of the chart. Change-Id: Ifea11329f1dcb80e8e390c1408306d1df7d49ded Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164471 Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-03-05tdf#99969: chart2_uichart: Add unittestXisco Fauli
Change-Id: Iddf64e07b4f6ee6913965b294d8a41904d2fc558 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164418 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-03-03tdf#153706: do not add categories, when source data doesn't have themMike Kaganski
lcl_AllOperator is used in XChartDocument::attachData implementation. When a data without existing categories is passed there, like an XY scatter, lcl_AllOperator used to force creation of the categories in the target, by returning 'true' unconditionally from setsCategories. This meant, that a new sequence of numbers starting from 1 was used as X values, and the old X data was interpreted as an extra Y series. This changes lcl_AllOperator::setsCategories to try to check if its data actually contains categories. Thus, XChartDocument::attachData will use categories either when the chart already uses categories, and ChartDataWrapper::applyData detects that using a call to DataSourceHelper::detectRangeSegmentation; or when the new data has it; but not when neither had it. When it's not possible to detect if there were categories in the new data (e.g., with user data), old behavior is used, setting categories. It could be an alternative to detect the chart type using xOldDoc->getDiagram()->getDiagramType() == "com.sun.star.chart.XYDiagram" in XChartDocument::attachData; and then decide to force the creation or not. But it seems hackish, and not really universal: other chart types must be tested (bubble?), no idea how to handle hypothetical cases when applied data contains categories in case of XY chart, etc. Change-Id: I86b34f6799c30b103f7fc6b2faf6ec255a9d137b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164298 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-03Make Chart Object Properties Dialogs Asynccodewithvk
How to reproduce it: When double-clicking on a chart, it will now open the Chart Object Properties dialog box. Previously synchronous, this commit updates it to be asynchronous. Signed-off-by: codewithvk <vivek.javiya@collabora.com> Change-Id: I54c24e0cd30d6ec8b2bfa93567e830405d2fd30c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162576 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 748a5a01165d40e9bcaa7bfc75b0e6f74fc5a07d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164125 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
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-03-01set default if no ViewShell yetCaolán McNamara
Change-Id: Ib6381ec963a9dc641d880eef1f9a3e556100a98e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164142 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-29cid#1169880 Uninitialized scalar fieldCaolán McNamara
Change-Id: I0ac1cc740f8d559cf8fa7b69947b6f152eae807a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164138 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27cid#1592375 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: I9d110911504832d7a8a6725ca3f9040a4fd0c4c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164010 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-23crashtesting: isNaN as fUnitCircleWidthAngleDegreeCaolán McNamara
presumably since recent tdf#50934 work affect files are: forums/xlsx/forum-mso-en4-295952.xlsx forums/xlsx/forum-mso-en4-523214.xlsx forums/xlsx/forum-mso-en4-656086.xlsx forums/xlsx/forum-mso-en4-702681.xlsx Change-Id: Ifc436d382f9cda13d2ae4459d436a72c5e40d8aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163784 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-20tdf#157882 svx: Remove cap/corner styles and move arrowhead control to new rowAkshayWarrier
Change-Id: Ifa38ec7ba9969627ff26abe22c58d06ec373ecb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162403 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2024-02-19tdf#50934: Fix compiler complaints and activate OOXML I/O testsKurt Nordback
Add tests for input and output of very basic pie-of-pie and bar-of-pie charts in OOXML. Change-Id: I6441d99941ea2aca9bf58ede40dbe8f3d38a3291 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160742 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-19ITEM: Speedup SlotIDToWhichID translationsArmin Le Grand (allotropia)
With ItemInfoPackages we now can have a buffered, static global translation table from SlotIDs to WhichIDs since the ItemInfoStatic used already contains all the needed information. Register that in registerItemInfoPackage at the Pool and use it for lookup. That speeds up the lookup from O(n) to O(1). Since that lookup is used in UI and UNO API implementations this has positive effect on load/safe, but also all interactive stuff in the whole office. NOTE: I tried to use a merged version of that translation table in the parent pool, but this shows double SlotIDs, what is no wonder since that's what those are used for: To get different WhichIDs for a SlotID in Item handling. This *might* prevent getting rid of the chanined Pools at all - sadly. The returned WhichID directly depends on which Pool the function(s) GetWhichIDFromSlotID and GetTrueWhichIDFromSlotID are called. NOTE: Very strange is that the parameter 'bDeep' in that functions is *not* passed down to the call to the secondary Pool - probably an error, but risky to fix, that may change already the behaviour :-( Change-Id: Iea77ffad0f6a5401ab74fea0bbfc2589c66680ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163597 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-02-19tdf#50934: Add one of-pie testKurt Nordback
Change-Id: I9af705ed671718486d2e46e481b5416e683cdbb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160741 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-19tdf#50934: Rudimentary UI images for pie-of-pie and bar-of-pieKurt Nordback
Change-Id: If2ddf1ea12804717583ab6df18dc7fbfffc37d31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160740 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-19tdf#50934: Fix color of composite wedge for imported of-pie chartsKurt Nordback
Change-Id: I5236ed53e418e31a470a66bdbe21eceaa5f6fc04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160739 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-19tdf#50934: Fix left of-pie ordering for imported chartsKurt Nordback
Change-Id: I490d6719f5190b0e889bd274ffa9c1b196e656d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160738 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-19tdf#50934: Try to fix wedge ordering for imported of-pie chartsKurt Nordback
Change-Id: I6e9a0d5426fb213c99ee99092596f68d688b928c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160736 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-19tdf#50934: OfPie inport from OOXML, plus initial work for exportKurt Nordback
Change-Id: Ie17b583af28d274b3e7817c646dd4f5873e03fef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160733 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-18tdf#50934: Add a commentKurt Nordback
Change-Id: I3986242fa584310acccba4830d8872043381cef6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160732 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-18tdf#50934: Implement connector lines for pie-of-pieKurt Nordback
Change-Id: Ifca083aa07b28d5c604382decaefedfe653ff8ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160731 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-17tdf#50934: Improvements to fill color for of-pie composite wedgeKurt Nordback
Change-Id: Ib9f7e3b135bb86e1817edf97b963e3620af7fdf2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-17tdf#50934: Ensure of-pie connector lines are blackKurt Nordback
Change-Id: I0548b395455eb17ec06f85ffce63affa15075391 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160729 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-17tdf#50934: Initial implementation of connector lines for bar-of-pieKurt Nordback
Change-Id: I586dd5ae784f5e86ad1e0d863765b058873eac68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160728 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-17tdf#50934: Fix of-pie subchart colorsKurt Nordback
Change-Id: I43e0118786853b0258741e5181f7e622c6f747ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160727 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-16Chart: Make Data Range Dialog Asynccodewithvk
To reproduce the step, double-click on the chart and right-click to open the context menu, where you can see the option for data ranges. Signed-off-by: codewithvk <vivek.javiya@collabora.com> Change-Id: I0697d5918d35d132aa7c17f86204742017f7ff17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163358 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit afbb4e44478e520b866032df8f0a0a344568233e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163402 Tested-by: Jenkins
2024-02-16tdf#142467: restore "final" in CandleStickChartType classKevin Suo
The "final" was removed in commit e06f2bb00137655dbf6f0a8c8c2fc555720f4d3f (tdf#142467 crash on calling 'getInfoHelper' in final class, 2021-05-26) and commit 6cb1745c24c7651050e30216860c539fa13cc0e2 (tdf#142467: Update comments with GCC bug ID, 2021-05-31) due to a bug in gcc <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797>. Now it has been amost 3 years past and that gcc bug has long been fixed, so it is time to restore the "final". Change-Id: I7db9fe59209cfbae4c04bb3a91cd764db9a38d98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163447 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-16tdf#50934: Implementation of bar-of-pie, plus minor of-pie fixesKurt Nordback
Change-Id: Ib343953ee30124524884859c8fe9e88d2dc7d822 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160726 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-16tdf#50934: Implement PieDataSrc and related structureKurt Nordback
Change-Id: I6affb326600d77ddf756d9bc223e7dcc29f87d23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160725 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-15tdf#50934: Some rejiggering of of-pie code, plus implementing subpie chartKurt Nordback
Change-Id: I91fca31db0eb0bfb673e77f1369abe110fe405b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-14tdf#50934: Restructuring for of-pie chartsKurt Nordback
Change-Id: I9682c314efb888d57e94f82f084cc6d0825a4408 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160723 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-12use more UNLESS_MERGELIBSNoel Grandin
Change-Id: I351a9127fb26369d8f598b6d6519d7e490fa476b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163190 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-09cid#1591760 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1591761 COPY_INSTEAD_OF_MOVE cid#1591763 COPY_INSTEAD_OF_MOVE cid#1591768 COPY_INSTEAD_OF_MOVE cid#1591769 COPY_INSTEAD_OF_MOVE Change-Id: Ia1c829f96148dc79cea02a69b3442c18d51e1288 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163162 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-09tdf#50934: Ensure BarOfPie has ScaleData::ShiftedCategoryPosition == falseKurt Nordback
Change-Id: I86c7ba4df89a1350f544345938a29c210903c06d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160722 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-07double operator < is not a strict weak ordering due to NaNStephan Bergmann
...so recent LLVM 19 trunk libc++ in debug mode complained during CppunitTest_chart2_export3 about > ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering at > 5 libsystem_c.dylib 0x0000000183279a40 abort + 180 > 6 libc++.1.0.dylib 0x0000000101045d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0 > 7 libchartcorelo.dylib 0x00000002f9e05990 _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000IPdNS_6__lessIvvEEEEvT_S4_RT0_ + 732 > 8 libchartcorelo.dylib 0x00000002f9e055ac _ZNSt3__111__sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPdEENS_6__lessIvvEEEEvT0_S7_RT1_ + 172 > 9 libchartcorelo.dylib 0x00000002f9e054d4 _ZNSt3__14sortB8de190000INS_11__wrap_iterIPdEENS_6__lessIvvEEEEvT_S6_T0_ + 68 > 10 libchartcorelo.dylib 0x00000002f9e04f94 _ZNSt3__14sortB8de190000INS_11__wrap_iterIPdEEEEvT_S4_ + 64 > 11 libchartcorelo.dylib 0x00000002f9dfea10 _ZN5chartL22lcl_fillDateCategoriesERKN3com3sun4star3uno9ReferenceINS2_6chart24data13XDataSequenceEEERNSt3__16vectorIdNSB_9allocatorIdEEEEbRNS_10ChartModelE + 1404 > 12 libchartcorelo.dylib 0x00000002f9dfe28c _ZN5chart26ExplicitCategoriesProvider4initEv + 280 > 13 libchartcorelo.dylib 0x00000002f9dff0b8 _ZN5chart26ExplicitCategoriesProvider10isDateAxisEv + 28 > 14 libchartcorelo.dylib 0x00000002f9bcb738 _ZN5chart14VSeriesPlotter9addSeriesENSt3__110unique_ptrINS_11VDataSeriesENS1_14default_deleteIS3_EEEEiii + 200 > 15 libchartcorelo.dylib 0x00000002f9b951e4 _ZN5chart8BarChart9addSeriesENSt3__110unique_ptrINS_11VDataSeriesENS1_14default_deleteIS3_EEEEiii + 280 Change-Id: Ie0711ca60130759f3daaf8332ab326fa29cb5cba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163074 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-07double operator < is not a strict weak ordering due to NaNStephan Bergmann
...so recent LLVM 19 trunk libc++ in debug mode complained during CppunitTest_chart2_export2 about > ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering at > 5 libsystem_c.dylib 0x0000000183279a40 abort + 180 > 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0 > 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960 > 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268 > 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68 > 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508 > 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528 > 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440 > 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728 > 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692 > 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288 But the introduced use of `std::strong_order(first[0], second[0]) < 0` then triggered a false > lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] > 105 | return std::strong_order(first[0], second[0]) < 0; > | ^ so needed some hack in loplugin:nullptr. And old versions of libc++, still used at least on Android, do not have any implementations of std::strong_order. So detect those cases in configure.ac (checking for std::strong_order for double, which is what is actually being used in the code) and fall back to operator <=> for now, even if that will not provide a strict weak ordering and will thus continue to violate the requirements of std::sort. And then our venerable clang-format 5.0.0 would have broken the token `<=>` into `<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment. Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-06Async Dialogs for Few Chart Propertiescodewithvk
Updated the chart properties dialogs to work asynchronously. The changes affect the following dialogs: Chart Type: Accessible by double-clicking on a chart to select it, then right-clicking to open the context menu. Selecting 'Chart type...' opens the dialog for modifying chart types. Insert Axes: Triggered by double-clicking on a chart to select it, then right-clicking and choosing 'Insert/Delete Axes' from the context menu. This dialog allows users to add or remove chart axes. Insert Titles: Opens when you double-click on a chart, right-click, and select 'Insert Titles...' from the context menu. It's used for adding titles to the chart and its axes. Insert Trendline: For column charts, you can double-click on a column, right-click, and choose 'Insert trendline..' to open this dialog. Insert Error Bars: In a column chart, after selecting a column, right-clicking and choosing 'Insert X Error Bars..' or 'Insert Y Error Bars..' opens the dialog for adding error bars to the chart. Signed-off-by: codewithvk <vivek.javiya@collabora.com> Change-Id: Id7bb8682150f2e3115420d9259c6afd41682641e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162655 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 71a3cfb71dddba8098d74d7bb1dd414e4696914b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162824 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-06tdf#50934: Add a version comment, and more structure for of-pieKurt Nordback
Change-Id: I9d7c25e47a3f4a78360f9b2deffe8650e378866d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156305 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-04use ViewShell DOCCOLOR when available for chartsCaolán McNamara
Change-Id: I200538bd94d60867d84b7dc37811094b65dd9aa5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162850 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-02tdf#50934: Initial plumbing and infrastructureKurt Nordback
Change-Id: I355bdc8e6d67e7cdd47e4d6eccecedc4b53ac11b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155851 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-01-31related tdf#146756 chart2: code-readers documentationJustin Luth
Sorely needed to avoid misconceptions. Change-Id: I9980bd2344f5f6db3fd1719476836b91803d7b6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162609 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2024-01-31tdf#146756 pie chart2 import: use consistent outside-label max text lenJustin Luth
This is a followup to commit 85f4395b6f40c0295a190cca09ecd51858fc3b31. Although there is no pressing need for this patch in my opinion, it DOES fix a 7.1 regression in importing MSO charts with long labels. MSO wraps text at 1/5 the width of the chart. 7.1 Regression commit 75a8b367f2a06e0d485fc2b9f4472e8bb29d71e3 Author: Balazs Varga on Tue Aug 25 12:32:02 2020 +0200 tdf#136105 tdf#134883 pie chart: improve data label position Before Balazs' commit, the text width for everything was simply fTextMaximumFrameWidth = 0.8 * fPieRadius. I personally think Balazs' no wrapping looks better (for outside labels, when there is enough space) but in order to be consistent with how we handle wrapping for bestFit-that-didn't-fit labels, and to have our charts be as interoperable with OOXML as possible, it makes good sense to use the same logic as the previous patch here. Interestingly, Balazs broke some unit tests that specifically were testing to make sure that text wrapping existed. Fixed: // text wrap: wrap all text labels except Yellow one make CppunitTest_chart2_xshape CPPUNIT_TEST_NAME=testPieChartLabels2 Fixed: // text wrap: wrap no text label except Yellow one make CppunitTest_chart2_xshape CPPUNIT_TEST_NAME=testPieChartLabels3 Interestingly, I couldn't just copy/paste Ctrl-F12 dump to fix make CppunitTest_chart2_xshape CPPUNIT_TEST_NAME=testPieChartLabels4 so I instead did a copy/paste of SAL_WARN("DUH",getXShapeDumpString()); Change-Id: I19f2ce2ce9c7653ae92dd596f0aaca1ed83f41bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162764 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2024-01-30Fix typoAndrea Gelmini
Change-Id: I384f3c97286a5b336d44df42e911870100542198 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162766 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-01-30tdf#159288: Assertion on insert trend lineJulien Nabet
5 0x00007fd6780533a2 in __assert_fail (assertion=0x7fd66de41177 "ImplGetSVData()->mpDefInst->GetYieldMutex()->IsCurrentThread() && \"SolarMutex not owned!\"", file=0x7fd66df2c58b "/home/julien/lo/libreoffice/vcl/source/app/dbggui.cxx", line=35, function=0x7fd66de5d0c6 "void ImplDbgTestSolarMutex()") at ./assert/assert.c:101 6 0x00007fd66f0dd6a2 in ImplDbgTestSolarMutex() () at /home/julien/lo/libreoffice/vcl/source/app/dbggui.cxx:35 7 0x00007fd677522f10 in DbgTestSolarMutex() () at /home/julien/lo/libreoffice/tools/source/debug/debug.cxx:54 8 0x00007fd66f3aea88 in ImplFontCache::GetFontInstance(vcl::font::PhysicalFontCollection const*, vcl::font::FontSelectPattern&) (this=0x564a8f77e0c0, pFontList=0x564a8f7783d0, aFontSelData=...) at /home/julien/lo/libreoffice/vcl/source/font/fontcache.cxx:117 9 0x00007fd66f3ae987 in ImplFontCache::GetFontInstance(vcl::font::PhysicalFontCollection const*, vcl::Font const&, Size const&, float, bool) (this=0x564a8f77e0c0, pFontList=0x564a8f7783d0, rFont=..., rSize=Size = {...}, fExactHeight=12, bNonAntialias=false) at /home/julien/lo/libreoffice/vcl/source/font/fontcache.cxx:111 10 0x00007fd66eb905f6 in OutputDevice::GetDefaultFont(DefaultFontType, o3tl::strong_int<unsigned short, LanguageTypeTag>, GetDefaultFontFlags, OutputDevice const*) (nType=DefaultFontType::CJK_SPREADSHEET, eLang=..., nFlags=GetDefaultFontFlags::OnlyOne, pOutDev=0x564a8f6bfca0) at /home/julien/lo/libreoffice/vcl/source/outdev/font.cxx:573 11 0x00007fd62e86669d in chart::CharacterProperties::AddDefaultsToMap(std::__debug::unordered_map<int, com::sun::star::uno::Any, std::hash<int>, std::equal_to<int>, std::allocator<std::pair<int const, com::sun::star::uno::Any> > >&) (rOutMap=std::__debug::unordered_map with 19 elements = {...}) at /home/julien/lo/libreoffice/chart2/source/tools/CharacterProperties.cxx:358 12 0x00007fd62e951686 in (anonymous namespace)::GetStaticRegressionEquationDefaults()::$_0::operator()() const (this=0x7ffe3f9b6b80) at /home/julien/lo/libreoffice/chart2/source/tools/RegressionEquation.cxx:121 13 0x00007fd62e9500e7 in (anonymous namespace)::GetStaticRegressionEquationDefaults() () at /home/julien/lo/libreoffice/chart2/source/tools/RegressionEquation.cxx:117 14 0x00007fd62e94ff98 in chart::RegressionEquation::GetDefaultValue(int, com::sun::star::uno::Any&) const (this=0x564a90aa2870, nHandle=4, rAny=uno::Any(void)) at /home/julien/lo/libreoffice/chart2/source/tools/RegressionEquation.cxx:196 See full bt here: https://bugs.documentfoundation.org/attachment.cgi?id=192072 Change-Id: I8048b9a69761dba618ef556335c2cadab6647627 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162737 Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-01-30tdf#146756 pie chart2 import: improve response to bestFit failureJustin Luth
Fixes a 7.2 regression from commit b0068342398786ca50304260434a18880dddf74d author Tünde Tóth on Wed Dec 16 18:26:26 2020 +0100 tdf#138777 pie chart: improve long data label width When a label fails to bestFit inside the pie slice, it will be placed outside of the pie of course. However, we can't assume that there is any chart space available to place a label outside. Tünde got that part right. He limited the space available based on the chart edge. But there are some optimizations that can improve that. 1.) Every little bit can help. As we go away from the X-axis, we gain a little bit of space, so use that... 2.) Don't assume that the pie chart is in the middle of the page. 3.) Use a consistent algorithm for all degrees - much simpler. make CppunitTest_chart2_import CPPUNIT_TEST_NAME=testTdf146756 Change-Id: I0d8528bc227768f91237cda6b74bf9365820bfa7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162704 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-01-30tdf#146756 pie chart2 import: use manualLayout Width for pie chart labelsJustin Luth
... and use a compatible 1/5 width if not specified. This patch depends on the previous oox patch (commit 301e27cbebf7d6e4c9b82290d7cd555c43f0c999) which actually reads the width into the model. Fixes a 7.2 regression from commit b0068342398786ca50304260434a18880dddf74d author Tünde Tóth on Wed Dec 16 18:26:26 2020 +0100 tdf#138777 pie chart: improve long data label width and is basically a re-write of 7.1's commit 20da1a5dd37c7edac620566c992d5a53b23a5f12 author Tünde Tóth <toth.tunde@nisz.hu> on Fri Oct 09 09:24:18 2020 +0200 tdf#134978 Chart OOXML Import: fix pie chart label custom position This is very risky, but then ANYTHING changing chart2 is risky. There were a lot of changes made in 7.1, and they all invited regressions. However, our chart implementation is not in a good state, and certainly is not very interoperable, so it is worth taking the risk. Anything dealing with manualLayout at this point should have originated as a pptx, so forcing a compatible max width should be fairly safe. It probably isn't actually all that risky after all. largely copied code from commit 4223ff2be69f03e571464b0b09ad0d278918631b Author: Balazs Varga on Wed Jan 15 16:31:35 2020 +0100 tdf#48436 Chart: add CustomLabelPosition UNO API property Fortunately this all goes away after a round-trip since custom label placement is lost on export to OOXML, and that really helps to reduce the risk. make CppunitTest_chart2_import CPPUNIT_TEST_NAME=testTdf146487 Change-Id: I9722fc6c759c15ac3924780e6fc124f02fba07e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162590 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-01-29NFC chart2: trivial avoidance of unnecessary calculationsJustin Luth
Change-Id: Ia3bfce9ba6c7b8cab55e46e4d1e8c2afe54a65b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162588 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Justin Luth <jluth@mail.com>
2024-01-29NFC chart2: remove unnecessary variablesJustin Luth
Change-Id: I089972f0fd60fbaaff27a304c248a7eb882b972b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162587 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com>
generated by cgit (git 2.34.1) at 2025-01-10 08:37:51 +0000