summaryrefslogtreecommitdiff
path: root/unotools
AgeCommit message (Collapse)AuthorFilesLines
2020-10-12Changed font order for Korean locale tdf#137392DaeHyun Sung1-1/+1
changed font order priority. 1. put 'Noto Sans KR' ahead of 'Noto Sans CJK KR'. Because, New Noto Sans CJK font change the name. New Noto Sans CJK V2.001 released on 10 Apr 2019. In these font files, removed 'CJK' on names. Nowadays, New Linux distributions includes Noto CJK font V2.0. In Korean Linux environments, Noto CJK font v2.0 'Noto Sans KR' & 'Noto Serif KR' are already set default. 2. fixed Windows fonts for Korean on LibreOffice I watched Windows 10's Korean Font List Microsoft Docs: Font List Windows 10 - Typography; Korean Supplemental Fonts https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list#korean-supplemental-fonts I missed 굴림체;GulimChe, 돋움체;DotumChe, 굴림체;GulimChe. So. I added MS Default Korean fonts. As a result, I changed font order and add default Windows font names. Ref. 1: Google Noto CJK fonts Repository: https://github.com/googlefonts/noto-cjk 2: Microsoft Docs: Font List Windows's Korean supplemental fonts https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list#korean-supplemental-fonts cf.Apple Docs - Format Chinese, Japanese, or Korean text in Pages on Mac https://support.apple.com/guide/pages/format-chinese-japanese-or-korean-text-tanfbd4156e/mac Change-Id: I12594aa8f3122c05810a07a718aae7ec185ba481 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104189 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-04loplugin:reducevarscope in toolkit..unotoolsNoel2-2/+2
Change-Id: I439b9f456ac0bfaa3eb9bf17472053bd4787e828 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103840 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel4-24/+26
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-03use more TOOLS_WARN_EXCEPTIONNoel1-2/+1
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-25Fix typo in codeAndrea Gelmini1-3/+3
It passed "make check" on Linux Change-Id: I78ef6952782cedead97cf118588f4b7923bb0909 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103306 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-09-24tdf#134782 sw,unotools,officecfg: adapt configuration and UIMichael Stahl1-0/+2
Store AddParaLineSpacingToTableCells in configuration as "AddTableLineSpacing", consistently inconsistent like AddTableSpacing (the <desc> elements are not subject to translation). Adapt SwCompatibilityOptPage with some ugly hacks to allow 3 different states (TriState) for the corresponding checkbox that map to false/false, true/false and true/true. The checkbox widget doesn't allow to change *to* indeterminate but at least the status of the document can be displayed this way, with a non-obvious tweak to optcompatpage.ui to reference "checktri1" column. Change-Id: I5f32e05c93b5e16e782cba5d1d055809d9e5e251 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103318 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-21update pchesCaolán McNamara1-1/+2
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann1-1/+5
...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-07UNOTOOLS : simplify AccessibleStateSetHelper by not using an impl classArnaud Versini1-96/+37
Change-Id: Iae7a028d2845d8b0bef2aefdce2ae00fa7f5660f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102110 Tested-by: Jenkins Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
2020-09-05Simplify creation of the FontNameDictionaryStephan Bergmann1-242/+228
Some of the key sal_Unicode arrays contained embedded NUL characters, for which everything after the first NUL was ignored. But from the corresponding comment, it looks like those sal_Unicode arrays were presumably meant to contain multiple keys that should all map to the same "English name," which I have added now. (The original history of this source file beyond 942dbe34b9a1400c926a81f88e849d248b58ed55 "#i103496#: move some fontsubstitution stuff from vcl to unotools to get xmloff vcl free" appears to be lost, unfortunately. Another comment had already wondered why keys were terminated by double NULs, where the second NUL maybe was originally meant to terminate that sequence of individual keys all stored in a single sal_Unicode array.) There was also another // TODO: check if all dictionary entries are already normalized? in the construction of the FontNameDictionary aDictionary, of which I'm not sure what it should mean exactly, and whether I should have left it in. (This change is a prerequisite for making the OUString ctor taking a raw pointer explicit.) Change-Id: I168778307a67c6b72bf483dc34bfd45f8a48a143 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102086 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-03-Werror,-Wcompound-token-split-by-spaceStephan Bergmann1-1/+1
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-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann2-71/+71
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-19Fold Bootstrap::Impl::getVersionValue into its single useStephan Bergmann1-18/+10
...thereby fixing that it returns _sDefault instead of an empty string when "version.ini (versionrc) doesn't exist" Change-Id: Ie38afb6d87bd908f8a9773daaf5cee56751ae950 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101000 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-19tdf#135133: Don't try to read BuildVersionMike Kaganski1-9/+0
The option to set it was removed in 5fdf2009d21fa220dfee70ea755bd698c16257a7, and now the check is redundant - and even harmful until the remnants of the setting is dropped from bootstrap.ini. Currently the dummy value found there makes the About dialog miss the build id, and copying info to clipboard gives <buildversion> instead of proper build id. Previously the string was always empty in most builds (including TDF), which made the code proceed to buildid. Bootstrap::getBuildVersion got unused now, and is removed. Change-Id: If59e456655da29bb9421edc0e15d421829d0a02b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100957 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-08-19Drop fallback to read buildid from boostrap ini fileStephan Bergmann1-9/+2
f9e6d8d7c33a308f6f1c15929dd839de2abae3b5 "INTEGRATION: CWS nativefixer18: fix: #124825# read build id from version.ini" from 2005 had left the previous code to read from the bootsrap ini file as a fallback, presumably intended for some (short) transition period. (Plus loplugin:elidestringvar fallout. And fix the comment, which appears to have been non-matching right from the start.) Change-Id: Ia50228f4ae21e9f7ded48fe47d68fcd9931b090c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100967 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-18Fix typosAndrea Gelmini1-1/+1
Change-Id: I85a91d24943430b42217ac91611f182059d8ec69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100919 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara1-2/+4
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-05loplugin:flatten in unotoolsNoel Grandin10-351/+351
Change-Id: I2fad16061bca6dc3e57926863e7a3b71947a8ade Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100139 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-29replace and drop SvtExtendedSecurityOptions classCaolán McNamara3-232/+0
Change-Id: Ibe3443531c83eb44080217b61f5746be9cce9c49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99695 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-29replace and drop MiscCfgCaolán McNamara3-255/+0
Change-Id: I5ea9e3663fc5d30d725cf18757badb9b9802da18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99675 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-29replace and drop SvtPrintWarningOptionsCaolán McNamara3-325/+0
Change-Id: I17fd4156eb940fbdc925d9761301096e5349135f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99674 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-29drop newly unused SvtFontOptionsCaolán McNamara3-308/+0
Change-Id: Iaab664770d96a7d197354949bbe6d82c248f1037 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99648 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-29replace and drop SvtCompatibilityViewOptionsCaolán McNamara3-176/+0
Change-Id: Iab187468cf25b4a4afc7c79578677156ff224df9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99651 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-12update pchesCaolán McNamara1-6/+2
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-10replace usage of blacklist with excludelist for IWYUThorsten Behrens1-1/+1
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-09unotools: create instances with uno constructorsNoel Grandin10-71/+86
See tdf#74608 for motivation Change-Id: I7a68484564aea9b416c12d5364d20ff8af77f40b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98380 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: unotoolsStephan Bergmann9-176/+176
Change-Id: I9f4684834002d09fb5408e2b705dec37ffa498fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97734 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-24use more std::container::insert instead of std::copyNoel Grandin1-2/+1
which is both more compact code, and more efficient, since the insert method can do smarter resizing Change-Id: I17f226660f87cdf002edccc29b4af8fd59a25f91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96948 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-06-05Upcoming loplugin:elidestringvar: unotoolsStephan Bergmann1-21/+7
Change-Id: If77111b78496420514fb73d6d98d22e759282093 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-01ofz#22822 use TOOLS_WARN_EXCEPTIONCaolán McNamara1-1/+1
Change-Id: Ib8947dbe464c7b5b1f6fc55e7b0754e1c75491fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95268 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-29loplugin:simplifybool in ucb..vclNoel Grandin1-1/+1
Change-Id: Ib63623f5ca3f6559e02a0013c3cbd6174f7aec14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95108 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-25[MS-OFFCRYPTO] convert oox implementation into UNO serviceVasily Melenchuk1-2/+3
To permit pluggable crypto services, abstract existing implementation behind an XPackageEncryption API. Previous code already had two halfway-polymorphic classes (agile and standard 2007 engine), so we're not adding much additional layers. As MS crypto always uses OLE storage to wrap content into one single file, current implementation passes all substorage names down into XPackageEncryption APi, so different downstream implementations (e.g. for MS RMS, or Azure AIP) are possible. Because OleStorage classes are internal to LibO core, access is provided via XInput/XOutput stream API function. Change-Id: Icc32a4e0ce215090c3b739f1dcaa0654b36b7f08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84436 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-05-21use for-range on Sequence in testtools..xmloffNoel Grandin1-4/+2
Change-Id: I05b02a2f8b4b9091c7de0f7e98409d5b608ed250 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94610 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-18officecfg,unotools,cui: add ODF 1.2 Extended / ODF 1.3 versionsMichael Stahl1-0/+4
... to configuration and UI. The new default is ODF 1.3 Extended, which is now ODFVER_LATEST and stored as value "3" in configuration. Adapt a few places related to DocumentDigitalSignatures etc. to new default. Change-Id: I420da4f7787cc864c6bd88470d61b146b9399aa1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93177 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-05-10compact namespace in ucb..uuiNoel Grandin3-4/+4
Change-Id: I644d5e418028b4b4e66cf67b20a1155a689acab0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93906 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-07tdf#132796: use LO language settings to set default XLS languageMike Kaganski1-0/+6
This partially reverts fixes for i#63105 and i#71033, i.e. parts of commits 6ca96e7aee937affef218e0bb892e6904f4ef358 and 35777f0b401ba7bee21a24c32739e86598ba608b. Instead of using hard-coded Win-1252 for Excel files by default, use LibreOffice locale language or default document language (as used for old WMF, DXF and RTF files - see 20f6a6b159c69771dc0e087f63b6c701908e32e2, 1a9a77f84cac68bd5374df3e9ee4df88dc87a0ac, and f26bbdb386f9e66b1a154d0589b1a446ea2dd8d5). When a font in XLS specifies ANSI_CHARSET (0), allow using the default encoding, not the corresponding Win-1252. This mimics Excel behaviour for such fonts. Do not use first font's encoding as file default encoding, as Excel doesn't do that. Do not consider font-specified encoding in ImportExcel::Rstring to mimic Excel behaviour for cell number formats (but keep using it in ImportExcel::ReadLabel for cell content). Change-Id: I9860013a1244dc12f06f30c81a67909012c04913 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93612 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-27Extract getting default locale for filters into separate unotools functionMike Kaganski2-0/+28
Change-Id: Ic97b1a4507d5629963f360147ecc20eb10f5d391 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92957 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-27Make upcasting css::uno::Reference ctor require complete typesStephan Bergmann1-0/+1
The main reason for the "home-grown" UpCast introduced with 904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for css::uno::Reference" in 2013 was probably that we could not yet rely on C++11 std::is_base_of back then. A (welcome) side effect was that the derived class could be incomplete. However, specializations of UpCast relying on whether or not T2 is incomplete are obviously an ODR violation if the type is incomplete in some TUs and complete (and derived from T1) in others. And even if UpCast had internal linkage, it would still be brittle that its behavior depends on the completeness of T2 at the point of the template's instantiation, and not necessarily at the point of use. That means we should better base that ctor on std::is_base_of (which we can do now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on Clang and GCC if the completeness requirements are not met. This change fixes all the cases where types need to be complete now, plus any resulting loplugin:referencecasting warnings ("the source reference is already a subtype of the destination reference"). Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-27Don't convert OUString to char*Mike Kaganski1-105/+87
Change-Id: I3bfcc6fedb782b12be1fb1d42981756287f29f82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92956 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-21Fix warning when compiling for iOS: unused parameter 'bCreateParentDirs'Tor Lillqvist1-0/+1
Change-Id: I3d27837ea49ad964a40f53083d90f2a287bae8a0
2020-04-17loplugin:buriedassign in tools..xmloffNoel Grandin2-75/+93
Change-Id: I31df6c4fd82c6f6d15bbe5228e92e5171cacba51 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92410 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-17Fix autorecovery using wrong directorySamuel Mehrbrodt1-11/+12
Autorecovery should save in the user profile in the "backup" directory. However, when that directory did not exist, the temp directory was used instead. Fix this, and create the requested directory if it did not exist. Change-Id: Ie298855a740932bc6e6c9f62d4b4bf1b52b80c58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92402 Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-03-31Translate German variable namesJohnny_M1-3/+3
Ende -> End Change-Id: Ia3df5ee48e0d61051d99ac93e62c8a6dceafb41d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91218 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-03-25Remove unused using declarations in oox...xmlsecurityGabor Kelemen2-3/+0
Found by: run-clang-tidy-10 -checks=-*,misc-unused-using-decls Change-Id: I3e95791e223ef01e140a6217e29a9efae428a784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90876 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-21tdf#128276 Font names are not localized on macOS CatalinaTomofumi Yagi2-4/+23
1. We would like to call CTFontDescriptorCopyLocalizedAttribute function simply. We don't need to compare language settings of LibreOffice UI to OS lang- uage settings. This comparison was a way to save users from confusion, but it was bad idea. Because CTFontDescriptorCopyLocalizedAttribute function before macOS Catalina returns RFC 3066 bis as a language tag, but LibreOffice and macOS Catalina uses BCP 47 as a language tag. CTFontDescriptorCopyLocalizedAttribute function use the language setting for the operating system, therefore Users will change it if needed. 2. Fix font aliases on macOS Catalina I added some entries because I notice that those doesn't working with a Hiragino Sans font alias. Change-Id: Ie05a96f45cba13a19fcc1b855bd908f397e585a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/81145 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-18tdf#131069 always produce utf-8 from gettextCaolán McNamara1-0/+3
Change-Id: I311e647f08b4d541825e7790d971b98b5b5bfe40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90668 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-03-16Revert "loplugin:constfields in unotools..uui"Noel Grandin7-17/+17
This reverts commit d8ac55e3e53564aca4b0bade5a5b5cb01b4519b1. Change-Id: Ib7cf67d5d0b7780dfde9453cdddb8f11ca5d3a6a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90542 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-27tdf#42982 added description on RuntimeException for unotoolsAlanTang1-4/+4
Change-Id: I528d0bd7408ab9761de2d6fe8e60a5a521dda4dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89414 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2020-02-25Fix currency symbol selection in Calc on mobileTomaž Vajngerl1-1/+1
In LOK we use one language identifier for both - UI language and the locale used. This is a problem when we determine that we a language for UI is not available and fall-back to the default "en-US" langauge, which also changes the locale. This introduces a separate variable that stores the language tag for the locale independently to the language. Another problem is that in some cases we don't reset the staticly initialized data, when the new document is loaded, which is on the other hand used to define which currency symbol is used as SYSTEM locale. That can in some cases select the wrong currency symbol even when we changed the locale to something else. This fix introduces a reset function, which is triggered on every document load. Change-Id: I55c7f467600a832895f94346f8bf11a6ef6a1e49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89320 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89343 Tested-by: Jenkins
2020-02-21Drop o3tl::optional wrapperStephan Bergmann2-5/+5
...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-25 12:48:19 +0000