/slideshow/

3-3.2'>distro/collabora/cd-5.3-3.2 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/include/vcl/FilterConfigItem.hxx
AgeCommit message (Collapse)Author
2023-09-30pdf-dialog general-tab: set_sensitive if config not read-onlyJustin Luth
Disable (gray out) Export as PDF options that are enforced (unchangeable) in the settings, similar to how optsave does it for tools - options. It is possible for an config extension to set oor:finalized="true", which needs to prevent the user from changing the value. Noticed during the LibreOffice conference in Bucharest, RO. mxCbExportBookmarks == Export Outlines Change-Id: I27f28107d1c1dc5d46fc6e2b8a8a83933e30d6ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157408 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2021-10-14Avoid COW overhead using css::uno::SequenceMike Kaganski
The scenarios are: 1. Calling sequence's begin() and end() in pairs to pass to algorithms (both calls use getArray(), which does the COW checks) 2. In addition to #1, calling end() again when checking result of find algorithms, and/or begin() to calculate result's distance 3. Using non-const sequences in range-based for loops, which internally do #1 4. Assigning sequence to another sequence variable, and then modifying one of them In many cases, the sequences could be made const, or treated as const for the purposes of the algorithms (using std::as_const, std::cbegin, and std::cend). Where algorithm modifies the sequence, it was changed to only call getArray() once. For that, css::uno::toNonConstRange was introduced, which returns a struct (sublclass of std::pair) with two iterators [begin, end], that are calculated using one call to begin() and one call to getLength(). To handle #4, css::uno::Sequence::swap was introduced, that swaps the internal pointer to uno_Sequence. So when a local Sequence variable should be assigned to another variable, and the latter will be modified further, it's now possible to use swap instead, so the two sequences are kept independent. The modified places were found by temporarily removing non-const end(). Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-03use more compact namespace syntax in /includeNoel Grandin
excluding the UDK headers of course Change-Id: Iac7ab83d60265f7d362c860776f1de9d5e444ec0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93268 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-10PropertyValue must be a complete type here (Windows --disable-pch)Stephan Bergmann
...when instantiating implicitly defined special member functions of VCL_DLLPUBLIC FilterConfigItem Change-Id: I3128a475e9363b0dc0960fbb34e25c64c2270f69 Reviewed-on: https://gerrit.libreoffice.org/66063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-27tdf#42949 Fix IWYU warnings in include/vcl/[f-h]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ice2eb8c5994bf2ccb88972332ca4a1d3ed41752a Reviewed-on: https://gerrit.libreoffice.org/63826 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2017-07-28loplugin:constparams handle constructorsNoel Grandin
had to change the structure of the plugin considerably, was too messy to structure it to do the calculations on a per-function basis Change-Id: I4edee7735f726101105c607368124a08dba21086 Reviewed-on: https://gerrit.libreoffice.org/40516 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-04-05loplugin:constantparamNoel Grandin
Change-Id: I1996319e5b664dff95f7a9b2346aea6092d333ec Reviewed-on: https://gerrit.libreoffice.org/36070 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>