summaryrefslogtreecommitdiff
path: root/unotools
AgeCommit message (Collapse)Author
2020-11-11loplugin:stringviewNoel
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-03ucbGet needs a non-null interaction handler after allStephan Bergmann
In db6c7a486395304f38e9ea52951f576f34749cbc "Use UCB instead of cURL to download https files", I had not further investigated why using the (GUI) interaction handler within utl::UcbStreamHelper::CreateStream would lead to deadlock during UITest_sw_options (UITEST_TEST_NAME=optionsDialog.optionsDialog.test_moreIconsDialog). Instead, I had passed a null XInteractionHandler into utl::UcbStreamHelper::CreateStream, assuming that would solve whatever the issue was (and it did make the UITest pass). However, that caused the AdditionsDialog to not be populated at all, with > warn:cui.dialogs:26878:26950:cui/source/dialogs/AdditionsDialog.cxx:95: Reading <https://yusufketen.com/api/Templates.json> failed with 0x20d(Error Area:Io Class:General Code:13) (see comment at <https://bugs.documentfoundation.org/show_bug.cgi?id=137922#c1> "Extensions button in Template choose does not show anything"), because interaction requests like com.sun.star.ucb.CertificateValidationRequest were not handled properly. As it turns out, the real reason for the deadlock was that the UITest quickly closes the dialog, causing the main thread to block at m_pSearchThread->join(); in ~AdditionsDialog waiting for the SearchAndParseThread to finish, while SearchAndParseThread::execute encountered a CertificateValidationRequest that needs to be handled and thus blocks in UUIInteractionHelper::handleRequest (uui/source/iahndl.cxx) waiting for the main thread to process the PostUserEvent. In an ideal world, the UCB would allow to cancel the download request issued from ucbGet while that download is waiting for the CertificateValidationRequest to be handled, and the AdditionsDialog CloseButtonHdl would initiate such cancellation. Lacking that, just keep the Close button disabled until the SearchAndParseThread has finished downloading. (Pressing the Close button earlier, ~AdditionsDialog would have blocked the main thread anyway until SearchAndParseThread had finished downloading, so this should not actually worsen the user experience. And the UITest now blocks waiting for the Close button to become enabled before pressing it; there would already be UITest.wait_until_property_is_updated available, but it has a hard-coded timeout which might or might not be relevant in existing uses of that function, so leave it alone and repeat the relevant code without an unhelpful timeout here.) This means that the additional utl::UcbStreamHelper::CreateStream overload introduced in db6c7a486395304f38e9ea52951f576f34749cbc "Use UCB instead of cURL to download https files" is not necessary after all, so remove it again. Two further items that should be looked into: * Should ucbGet pass the AdditionsDialog into utl::UcbStreamHelper::CreateStream as css::uno::Reference<css::awt::XWindow> xParentWin argument (which defaults to null)? * There might be similar deadlock issues involving ucbDownload, which can also be called (indirectly) from SearchAndParseThread::execute. Change-Id: I8d549066940fa4f259a814a31ec7c62960e0db8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105169 Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-10-28Use UCB instead of cURL to download https filesStephan Bergmann
Since 7dc6fc32eb618da6defb8a9f330978fa019677b8 "uitest: Check the more icons dialog opens" started to test the AdditionsDialog code, some ASan builds started to report use-after-poison from within SearchAndParseThread::execute -> curlGet -> curl_easy_perform -> ... -> https_connecting -> ... -> secmod_ModuleInit -> pemC_Initialize -> ..., see the comments starting at <https://gerrit.libreoffice.org/c/core/+/98226/ 10#message-2a55980ab2477e41dc7515e4aeabc7234afc2053> "tdf#133026: Tight integration of extensions - Adding thread structure". The exact cause for that ASan use-after-poison is not quite clear to me. First, I thought it was due to liberal use of curl_easy_init (without a central curl_global_init) in a multi-threaded process; see <https://curl.haxx.se/libcurl/c/curl_easy_init.html> for this being considered "lethal". But then, another issue could be that most of the nss libraries like instdir/program/libnss3.so (implementing the "... -> secmod_ModuleInit" part) come from LO's bundled --without-system-nss while /lib64/libnsspem.so (implementing the "pemC_Initialize -> ..." part) comes from the system, and there could be some mismatch when mixing these (esp. if the former are built with ASan). So whatever the actual cause, the right fix should be to use LO's UCB instead of directly calling into cURL anyway. That required a version of utl::UcbStreamHelper::CreateStream that uses a given XInteractionHandler (which may be null to indicate no interaction handling, instead reporting all interaction requests as exceptions) instead of internally creating an XInteractionHandler using the GUI, and which would cause deadlock in 7dc6fc32eb618da6defb8a9f330978fa019677b8's UITest_sw_options. (And introducing that additional utl::UcbStreamHelper::CreateStream overload required css::awt::XWindow to be a complete type now in vcl/source/graphic/GraphicLoader.cxx, for > include/com/sun/star/uno/Reference.h:277:18: note: in instantiation of variable template specialization 'std::is_base_of_v<com::sun::star::task::XInteractionHandler, com::sun::star::awt::XWindow>' requested here > std::is_base_of_v<interface_type, derived_type> > ^ ) (The removed code in cui/source/dialogs/AdditionsDialog.cxx should have been the last remaining use of curl in Library_cui. Apparently, e1e9e2aa16f08a8fd9e38db706d63e8eceeda8d1 "Kill Mozilla personas" had forgotten to remove it from cui/Library_cui.mk the last time Library_cui had become curl-free, before the introduction of the AdditionsDialog code.) (I did not remove the #undef ABSOLUTE FIXME from cui/source/dialogs/AdditionsDialog.cxx. c4bee547b02fbe3d07b1e9ee203c73e48f86e6bf "tdf#133026: Additions: Better Search Function" does not tell whether it had been added to mitigate a macro definition from the (now removed) #include <curl/curl.h>.) Change-Id: I1fec7488d36df81c3543d12d97da1291f77712fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104938 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-25UNOTOOLS : simplify AccessibleRelationHelper by removing useless impl patternArnaud Versini
Change-Id: I6cb14c5c973067c0ea1c64eab40e38b8b548174f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104776 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-12Changed font order for Korean locale tdf#137392DaeHyun Sung
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..unotoolsNoel
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_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-03use more TOOLS_WARN_EXCEPTIONNoel
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 Gelmini
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 Stahl
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 McNamara
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 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-07UNOTOOLS : simplify AccessibleStateSetHelper by not using an impl classArnaud Versini
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 Bergmann
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 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-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-19Fold Bootstrap::Impl::getVersionValue into its single useStephan Bergmann
...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 Kaganski
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 Bergmann
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 Gelmini
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 McNamara
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 Grandin
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 McNamara
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 McNamara
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 McNamara
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 McNamara
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 McNamara
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 McNamara
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 Behrens
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 Grandin
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 Bergmann
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 Grandin
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 Bergmann
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 McNamara
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 Grandin
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 Melenchuk
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 Grandin
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 Stahl
... 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 Grandin
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 Kaganski
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 Kaganski
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 Bergmann
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 Kaganski
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 Lillqvist
Change-Id: I3d27837ea49ad964a40f53083d90f2a287bae8a0
2020-04-17loplugin:buriedassign in tools..xmloffNoel Grandin
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 Mehrbrodt
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_M
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 Kelemen
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 Yagi
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 McNamara
Change-Id: I311e647f08b4d541825e7790d971b98b5b5bfe40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90668 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-20 09:04:52 +0000