summaryrefslogtreecommitdiff
path: root/cui/source/options
AgeCommit message (Collapse)Author
2020-12-07remove OpenGL VCL backend codeLuboš Luňák
It is by now practically unmaintained, even bugreports in bugzilla have been already closed for it. AFAICT this used to be really used only on Windows, where it's no longer the default. There's still some OpenGL code left, because there are still two other places that use OpenGL. One is OpenGL slideshows, which reuse some of the base OpenGL code (and I've checked they still work even after this removal). Second one is OpenGL canvas, which it seems has never been finished or enabled (or so it most probably should be dumped too). Change-Id: I7ea5aef77ec252eb8e712d167db591209be84a13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107290 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-07remove SID_BASIC_ENABLED and BasicEnabled optionNoel
which has never been used since creation in commit fd069bee7e57ad529c3c0974559fd2d84ec3151a Author: Jens-Heiner Rechtien <hr@openoffice.org> Date: Mon Sep 18 16:07:07 2000 +0000 initial import Change-Id: I018b1f734c8263167dab3d5c6f98a400666f01d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107047 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-03convert SvtPathOptions::Paths to scoped enumNoel
Change-Id: I2e6cab798309a1bc2ade00661bc95dd5ae20f748 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107045 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-02tdf#138596 don't destroy SfxItemSet that are still in useCaolán McNamara
update the existing ones instead Change-Id: I67fd6c4ecb5d4294efae0262d558281e6840b5dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107079 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-01drop the needless and broken SkiaConfig abstraction (tdf#137935)Luboš Luňák
I originally copy&pasted this from the OpenGL setting, but this appears to be just an unnecessary complication. Both the option and writing is in fact simple, and trying to make it abstract and complicated doesn't provide much, and it causes the options not saved if only 'Apply' is used in the config dialog. Change-Id: Ibd55052467988b54429358567d70cbfbb0a34653 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106900 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-01OSL_FAIL.*exception -> TOOLS_WARN_EXCEPTIONNoel
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-30loplugin:stringviewparam include comparisons with string literalsNoel
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-25clean up enabling/disabling GUI options related to SkiaLuboš Luňák
This should properly enable/disable 'force Skia software rendering' and 'use hardware acceleration' checkboxes when Skia is enabled or disabled. Technically the two options are duplicates, since 'use hardware acceleration' is the exact opposite of 'force Skia software rendering'. But the implementation of the hw accel option is so tied to the implementation of the canvas module that it's simpler to ignore it for Skia. Change-Id: Ia7c54140aec72d6ef75b7ba53ce83037311f0caf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106491 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-17tdf#137930 Apply button changes values to previous onesCaolán McNamara
Change-Id: I374b4f448715db9563f6073c433b82caf3482874 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105953 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-16tdf#138049 different parents for restart dialog depending on ok vs applyCaolán McNamara
and in ok case hide the to-be-dismissed dialog before putting up the next dialog Change-Id: Ie9c0dfc1a7c10f8fd1d7a70749e07db123de2bf9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105951 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-13tdf#123936 Formatting files in module cui with clang-formatPhilipp Hofer
Change-Id: I473e2950bb9bd53043feeae31a27ae0c2fc7801d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105659 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-06tdf#42949 Fix new IWYU warnings in directories c*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Iac1e7802dbe1efa01c2befdd10406231788d4fc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105315 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-04negative returnsCaolán McNamara
Change-Id: I6f710f1aecc2e242b6006a3360e31bf2a9438fe7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105286 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-11-02use officecfg or MacroRecorderModeNoel Grandin
Change-Id: I2a8d4f401ddfd4368a7b50b4c3c8a72724f9afa3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105154 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-01use officecfg for UseSystemFileDialogNoel Grandin
Change-Id: I1419af229a67d6ebb1cf2c63757656beb3f512db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105142 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-01use officecfg for UseSystemPrintDialogNoel Grandin
Change-Id: I0e0bdc925f106884cbcede6405cc6ef7152ad405 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105139 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-01use officecfg for Experimental flagNoel Grandin
move IsShowOutlineContentVisibilityButton out of header to avoid having to add extra include paths to all the unit test makefiles. Change-Id: I2763390e07cd85b8f09b6f2ad7702039daecb22f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105100 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-29have just the one handler for ok/apply optionsCaolán McNamara
'apply' is only really working the first time it is pressed in a page, I want to be able to apply to change e.g. notebookbar icon size and then change that again and apply and get the expected display size Change-Id: I7f051ad4063f0e99f822cc06fbe4a0ab49588fbd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105020 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-29call ExtPage::DeactivatePage for apply as well as okCaolán McNamara
I think the concerns at https://gerrit.libreoffice.org/c/core/+/54980/ are on balance overly conservative and its safer to make apply behave the same as ok wrt that call Change-Id: I889290c23dc9a7d4bb751769a509932142be5795 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105019 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-29move block for RET_OK conditional return into Ok handlerCaolán McNamara
making it clearer what happens on "ok", no logic change intended Change-Id: I1d57500d2fbeded4cd7c7fd48fd1f4296b78e41d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105018 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-28cid#1468666 'Constant' variable guards dead codeCaolán McNamara
Change-Id: Ie27df6c7e4a10d943d0a2e2a6880a5fe2c34fbcb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104922 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-22Don't make list of JREs active when parent frame is inactiveMichael Weghorn
When the Java framework's direct mode is used, there is no use in allowing the user to change the Java options in the "Advanced" options page, so the corresponding frame is grayed out, s. commit 2976590ed9f727c24064c97d80a51e9891253119 ("Gray out Java options when framework's direct mode is used", 2020-10-21). For the native gtk3 implementation, this also means that the child widget holding the list of JREs ('m_xJavaList') automatically remains grayed out as long as the parent widget ('m_xJavaFrame') is. However, it turns out that this is not true for the plain VCL implementation (used e.g. by the gen or kf5 VCL plugins) where the child widget can be made sensitive while the parent widget is insensitive. Therefore, commit 3935a0bd3bcf747aa9bede59b045d23ab598f2d4 ("Properly (un)tick Java checkbox in Java options in direct mode", 2020-10-21) resulted in the widget holding the list of JREs becoming active again when the 'EnableHdl_Impl' handler was called in the non-gtk3 case (while the parent widget and the buttons to add JREs, edit Java parameters and classpath would remained grayed out). Make sure the widget holding the list of JREs remains grayed out along with the whole frame holding the Java options. Change-Id: Ic46bf317afec9bc566493ec56ab5319a78050da0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104657 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-10-22Properly (un)tick Java checkbox in Java options in direct modeMichael Weghorn
While the Java settings cannot be changed when the direct mode of the Java framework is used (s. Change-ID Ife017f9b5c6c6488f84201dd78b23305c67bec1b, "Gray out Java options when framework's direct mode is used"), it still makes sense to (un)tick the (grayed out) checkbox which indicates whether a JRE is used or not, which depends on whether the JRE that is set (e.g. via env variable 'UNO_JAVA_JFW_JREHOME') is usable or not. Change-Id: I13822bb7535e3f05cbc6ef83b3c82e2739c45ad6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104064 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-10-22Gray out Java options when framework's direct mode is usedMichael Weghorn
The 'javasettings_${_OS}_${_ARCH}.xml' files are only meant to be used when the application mode of the Java framework is used, not in direct mode. From ure/source/README: > You can also use the > UNO_JAVA_JFW_JREHOME deployment variable to specify the location of a JDK/JRE > installation. For more information on this variable, see > http://udk.openoffice.org/common/man/spec/javavendorextension.sxw. From that http://udk.openoffice.org/common/man/spec/javavendorextension.sxw : > The direct mode of the framework is used within the build environment. > Java is needed there in order to register Java UNO components with the > regcomp tool. Direct mode means that no settings are written or read. > That is the parameters UNO_JAVA_JFW_USER_DATA and > UNO_JAVA_JFW_SHARED_DATA are not used. > [...] > Another example for using the direct mode is the SDK. The SDK uses the > libraries from the office installation. When an SDK is configured then > one specifies what Java is to be used. This Java shall then be used for > all task which require Java including registration of UNO components. In > order to override the java settings of the office the script which > prepares the SDK environment sets these environment variables: > UNO_JAVA_JFW_JREHOME=<file_URL_to_selected_Java> > UNO_JAVA_JFW_ENV_CLASSPATH=true > UNO_JAVA_JFW_VENDOR_SETTINGS=<file_URL_to_javavendors.xml_from_OOo> > By setting UNO_JAVA_JFW_JREHOME the framework is switched into direct mode > and the office settings are disregarded. Therefore, gray out the Java options in the "Advanced" page in "Tools" -> "Options" to not give the user the wrong impression that settings made there actually have any effect when using direct mode, e.g. by starting LibreOffice like this UNO_JAVA_JFW_JREHOME=file:///usr/lib/jvm/java-11-openjdk-amd64/ ./instdir/program/soffice --writer and then realizing on restart that all manually made settings were discarded (e.g. newly added Java installation does not show up,...). Change-Id: Ife017f9b5c6c6488f84201dd78b23305c67bec1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104002 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-10-21use tools::Long in comphelper..cuiNoel
Change-Id: I65167999c6049038f8f5d530a0c5cb0552ab0e06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104609 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-20clean up handling of the UI Skia optionsLuboš Luňák
Disable the sub-option when the main option is disabled. Enable it for the proper VCL backends ("win" and "gen"). Change-Id: I38c2f605c10eb0f3cfae3f05cd4bada4877cdc2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104426 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-20remove ui for 'forceskia' AKA 'ignore skia denylist' (tdf#137159)Luboš Luňák
I originally copy&pasted this from the OpenGL code, but now that I think of it, having an easy checkbox to make LO use drivers that LO decides are faulty is a bad idea. There's still the expert configuration if somebody insists (and if they're not expert enough to find the expert setting then they better not mess with it), but this is asking for unnecessary trouble. This also solves the problem that the UI option is misleading. As the description in Common.xcs says, "This one forces the use of Skia even if the denylist would block the driver.", so the option is independent of the 'enable skia' option, but the UI didn't make it appear so. Change-Id: I74bf3574f16899405272dbb3aec54580a5e3f0bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104425 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-10-15tdf#137432 only do EnableInvalidate(false) optimization when not shownCaolán McNamara
Change-Id: If7f35d19061a7a2db2e5df31227834526bbf0905 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104381 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-14Resolves tdf#137447 - Access icon themes via tight extensionsHeiko Tietze
Button and code added to optgdlg Change-Id: Ib4aa0883a6af2844ab68ed3c0b7f0e21bc655d94 Signed-off-by: Muhammet Kara <muhammet.kara@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104233 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2020-10-12Resolves tdf#137187 - More dictionaries via extensions dialogHeiko Tietze
UNO command and linkbutton interaction replaced with the internal dialog DICT_REPO_URL removed, README adjusted Change-Id: I401737b538da229ac0d432007e7564105672ff40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103769 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2020-10-06move set_user_managed_scrolling to an initial weld argumentCaolán McNamara
gtk is creating a11y objects on widgets changing parents so manage when that can happen to avoid premature creation of custom widget a11y objects Change-Id: I4879a93a897b2e4084cf6af0c9c0b0f0c1062254 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104025 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel
Change-Id: Id83c478af5d04ad548c7cf4239fe2fb3ee154dc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103861 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02loplugin:reducevarscope in cuiNoel
Change-Id: Iedfda307d149fe2a5a196c83d3ea02b618e7dd23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103809 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02tdf#137032 make tools-> options sidebar widerandreas kainz
Change-Id: I7f41cfe4458c50b4671b227f026bbdc2b0e33b93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103808 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
2020-09-13tdf#124176 Use #pragma once in cuiGeorge Bateman
This commit was carried out by a Python script, source of which is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97. Change-Id: Ia0099ecd621f008e497260f26e5754d55d0f09aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102549 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-07tdf#136534: Font replacement table loads existing rule incorrectlyJulien Nabet
Regression from cd384e2d31f74223948ea70d8aa3c318d3ceeb50 author Caolán McNamara <caolanm@redhat.com> 2020-06-05 16:11:39 +0100 committer Caolán McNamara <caolanm@redhat.com> 2020-06-08 20:21:35 +0200 commit cd384e2d31f74223948ea70d8aa3c318d3ceeb50 (patch) tree 49ae5191c2bd4b13c3cd547951933fbc37cda0fa /cui/source/options/fontsubs.cxx parent c3669c8bd62ecf5eaa6b5e95289825bc11b2688a (diff) rework treeview initial toggle button col to be like expander col cause this assumption is baked into the vcl one making it hard to adapt remaining cases Change-Id: I31854211be5f558b51f345af6a11c471a9bd120d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102148 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-03Make ImpSvNumberformatScan::GetColor constMike Kaganski
Change-Id: Idbcce18029944ab884cdde03e21190cbb574a00f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102005 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2020-09-03-Werror,-Wcompound-token-split-by-spaceStephan Bergmann
Between <https://github.com/llvm/llvm-project/commit/ 0e00a95b4fad5e72851de012d3a0b2c2d01f8685> "Add new warning for compound punctuation tokens that are split across macro expansions or split by whitespace" and <https://github.com/llvm/llvm-project/commit/ 0da84535b1e328188efbc1bb697dc7276f9e7d27> "Remove -Wcompound-token-split-by-space from -Wall", Clang 12 trunk emitted such "'::' and '*' tokens forming pointer to member type are separated by whitespace" warnings, so just clean those places up for good even if the warning would not hit out of the box with any official Clang release. Change-Id: Ic58c0da4b3dcce428f5aaa54e13d15299394cf9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101987 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-31Related: tdf#136189 don't assert on unsetting non-existing previous sort columnCaolán McNamara
Change-Id: If2330cc83ace9ec0133b99eec8c2f0be3919013e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101708 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-28move GetMinimumEditHeight calc to weldutils and reuse in calcCaolán McNamara
Change-Id: I3980bbaf269260243c8fcd8fe95cc03deac144ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101558 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-20Fix typo in codeAndrea Gelmini
Change-Id: I7c78c0fed4e92371ef7c6f4480227d4eca3a38fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101008 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-18loplugin:unusedvarsglobalNoel Grandin
tackle some read-only vars. Mark some of them const to make it obvious they are not really used, and to make the constantparam plugin see more data. Change-Id: Ia25927745866746aa1aa9d5affd5857ad9f9ee24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100895 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-17Always display highlighted JRE's locationStephan Bergmann
...when opening the Advanced options page and after adding a new JRE via the "Add..." button, not only after highlighting another JRE line. (I suspect this broke with 1aa246a8e8c7d974ab0f7bdfa16cda36cb700e03 "weld SvxJavaOptionsPage" towards LO 6.4.) Change-Id: I5f9b63e2d33a351eeef09712969b703f1e99ef7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100860 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-13Remove some unused includesMiklos Vajna
Change-Id: Iea6b931b1f2328886354f70ad81a3e07367db717 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100669 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-13loplugin:stringstatic also look for local staticsNoel Grandin
Add some API to O*StringLiteral, to make it easier to use in some places that were using O*String Change-Id: I1fb93bd47ac2065c9220d509aad3f4320326d99e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-05tdf#135367 enable_toggle_buttons sets SvTreeFlags::CHKBTNCaolán McNamara
designating that the special auto-sized toggle column is in use Change-Id: I23aa927c56e706590f397d15ef7329d20e0b18a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100136 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2024-06-30 12:09:07 +0000