ucbhelper - lo/core - LibreOffice 核心代码仓库

LibreOffice 核心代码仓库

文档基金会

Mode	Name	Size
-rw-r--r--	Library_ucbhelper.mk	1972	log plain
-rw-r--r--	Makefile	225	log plain
-rw-r--r--	Module_ucbhelper.mk	464	log plain
-rw-r--r--	README	56	log plain
d---------	source	68	log plain

ed bugs, this may not be the long-term best approach for specifying which entries go into the composite, and it still only allows for the last entries in the composite. But it is a step towards allowing greater control. I've also changed the default number in the composite from 3 to 2, to better match MSO. I/O of the 'number in the composite wedge' parameter is not included in this commit. Implementing that for ODF and OOXML perhaps should be a separate bug or bugs. Change-Id: If4afc1417ea94c15e86a9a4dfe967a6f8ecb7ca8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168690 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> 2024-07-21tdf#82716 Add initial implementation of the Histogram Chartvarshneydevansh - Add the Histogram selection to the UI - Histogram bars showing with No Gap - Convert X and Y axis to group data into bins and frequency - Adjusted failing UI test (tdf138556) as a new chart type was added Change-Id: Id1f161adac943ead5e17c7fbb7e14c9ab7f1655e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167068 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> 2024-05-07loplugin:ostr in chart2Noel Grandin Change-Id: I2985b6793a776639214a25bf9732c000b9026bfc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167236 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins 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-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> 2023-05-11tdf#155231 CRASH: with embedded OLE chartNoel Grandin regressions from commits like commit 70595c0291e4cc137158c77f6136025b10ce6728 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Thu Mar 16 09:20:17 2023 +0200 move setDimension/getDimension inside chart2::Diagram Change-Id: I535d8e74d621821bde7d31894fe7f0350e91c941 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151664 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-03-29expand out ChartModelHelper::findDiagramNoel Grandin since it just calls findFirstChartDiagram Change-Id: I21eb9a747127ad54f3b5875074a7bf7ffbf79e4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149681 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-03-28move get/setScheme from ThreeDHelper to DiagramNoel Grandin so we can use the get/setFastPropertyValue methods Change-Id: I2b57212a1d3933cd2825e647f692e2ae3cb8b484 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149647 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2023-03-21move getTemplate inside chart2::DiagramNoel Grandin Change-Id: I05da4e4a9acb2683633eda42cf18d740913c2e37 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149180 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-11-19tdf#151846 Restore XChartTypeTemplateNoel Grandin Which I removed in commit 58766f997d59e4684f2887fd8cdeb12d2f8a9366. Turns out it does have some usefulness for extensions. So restore most of it. The exception is the getDataInterpreter method, for which I have added a placeholder, so that the restored class has the same vtable layout as the original. Change-Id: Ief9b48ef2c408580bc24b5a8a0e11131edb3b943 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142908 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-04-25Recheck module chart2 with IWYUGabor Kelemen See tdf#42949 for motivation This time using the new --noexclude switch to recheck validity of the excludelist; these were the obsolete exclusions Change-Id: Ifdf79b30ebaf198082c2194611a2ed2b664e6f1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133309 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2022-04-23Recheck module chart2 with IWYUGabor Kelemen See tdf#42949 for motivation Change-Id: Id4cdca3eed8618c289f30913d506f8f2bd46f0bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133112 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> 2022-01-31use more concrete types in chart2, DataSeriesNoel Grandin Change-Id: Ib07ed6ec3321dc617cfec872d16683cf5de60907 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129181 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-01-22remove css::chart::XChartTypeTemplateNoel Grandin these are purely internal interfaces, they cannot be used from outside chart2. Change-Id: Ib89e98e8099c34a530951bd85236fced216aff18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128784 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-01-21use more concrete types in chart2, ChartModelNoel Grandin Change-Id: I6930e09ed471592d7c8b8fb16565b355b17bffc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128731 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-01-21Removed duplicated includesAndrea Gelmini Change-Id: I9f8350f44952692a9efef297792a2326086d3d91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128704 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2022-01-20use more concrete types in chart2, ChartModelNoel Grandin Change-Id: Ie38d941f855978b04995162040d8871a2577255c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128641 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-01-19use more concrete types in chart2, BaseCoordinateSystemNoel Grandin Change-Id: I1c246a3ea37595647ac254f492170a9e18540794 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128623 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-01-19use more concrete types in chart2, ChartTypeTemplateNoel Grandin and return data using a little struct rather than std::pair, to make the call sites read a little better. Change-Id: Ieb6fc24e053f50823789167ed0112aa04a083725 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128613 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-01-19use more concrete types in chart2, DiagramNoel Grandin Change-Id: I870f6d9fa4c0b51cf7c887199079fdbabbca1fec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128597 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-01-19use more concrete types in chart2, ChartTypeTemplateNoel Grandin Change-Id: I1bfbc81ca0d44efc669e5bc2b525cfa8b51be1ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128561 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-08-31clang-tidy:readability-redundant-member-initNoel Grandin Change-Id: I5e8baec88d5f17ddda452bd945c87769623cb4e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121357 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-05-19tdf#124295 - Always select a 3D scheme in the chart wizardAndreas Heinisch Change-Id: Ic0a39b4cb6f7af6fbdd99fc93677a0c2d966234d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115671 Tested-by: Jenkins Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de> 2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann ...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>