summaryrefslogtreecommitdiff
path: root/framework
AgeCommit message (Collapse)Author
2020-12-19make *String(string_view) constructors explicitNoel Grandin
to make it more obvious when we are constructing heap OUStrings code and potentially inadvertently throwing away performance. And fix a handful of places so revealed. Change-Id: I0cf390f78026f8a670aaab53424cd31510633051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08Clean up some logging in passingTor Lillqvist
The first parameter to these SAL_INFO calls, "fwk", already tells that it is about "framwork", and mentioning "cd100003" is useless. Change-Id: Ia094a22cefb3badbc65737b88ed7427b1376b621 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107442 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-08lock/unlock toolbar doesn't show an unticked checkboxCaolán McNamara
when in the off state Change-Id: I1a3c2a1281029ef7d80836db8431f306aeb76db7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107428 Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Jenkins
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-04update pchesCaolán McNamara
Change-Id: I3e22c2000da03f6f3345353846213203993aa865 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-03convert EHistoryType to scoped enumNoel
Change-Id: I115fc0ed81d6392d3649757727c4d9468213619d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-03tdf#124176 Use #pragma once in framework/inc/uifactorycu-16bcs1798
Change-Id: Ibb2d7c8a8fac7fabace2d751f0082533ce2c1f50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107132 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2020-12-02simplify SvtDynamicMenuOptionsNoel Grandin
just use the struct instead of passing around sequence of sequence of PropertyValue Change-Id: Ic03c066962a10daac6f83f30413a5ab09e1bfd5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106915 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-25tdf#131441 Disable "UNDOCKTOOLBAR" when toolbar is lockeddiwanshu885
Change-Id: I3a7fdf2fbde55a8ac4083f1fa8cd76e55718b2e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106476 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
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-17loplugin:stringviewparam check methods tooNoel
not just functions Change-Id: Icca295dd159002b428b73f2c95d40725434f04d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105789 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-16replace std::max(std::min()) with std::clampNoel
Change-Id: I890d19f5e2177294dc1175c90c98b964347f9e85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105751 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-13tdf#123936 Formatting files in module framework with clang-formatPhilipp Hofer
Change-Id: I8210a1d4bb51519f59265f370f5e8bab8a3c4179 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105674 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-12New loplugin:stringviewparamStephan Bergmann
...to "Find functions that take rtl::O[U]String parameters that can be generalized to take std::[u16]string_view instead." (Which in turn can avoid costly O[U]String constructions, see e.g. loplugin:stringview and subView.) Some of those functions' call sites, passing plain char string literals, needed to be adapted when converting them. Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-12tdf#42949 Fix new IWYU warnings in directories [e-f]*Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I963aa5fb892a0be36212fd0587b69f217f017947 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105469 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-11-11Fix 64-bit --disable-pch build on WindowsMike Kaganski
Change-Id: Ieeef0309faa77558fb30fceaed83ad97fb6e26ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105590 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-11convert more long -> tools::LongNoel
found by grepping and changed by hand. Change-Id: I3c720859dba430fde3abc76c6c5cb58269efaf4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105512 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02Windows 7 support is already supportedMike Kaganski
The comment was added in commit e9daae2025279d04155ddeb794bb35952e627ed7 in 2010; Windows 7 support was eventually implemented in 2013 in commit 776db316d271d14e653426e21e66b983ec52100a. Change-Id: I830321ef2131ad56ac664867ac71857fce8d9c75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105061 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-11-02toolbox always has flat styleNoel Grandin
ever since commit c1cd6af623e86b5b1b45f9d09dc17d6fbb907f02 Author: Jens-Heiner Rechtien <hr@openoffice.org> Date: Mon May 10 14:51:02 2004 +0000 INTEGRATION: CWS nwf (1.64.66); FILE MERGED 2004/03/31 09:28:33 ssa 1.64.66.1: #i25130# force flat toolbox buttons except for a completely and utterly undocumented hack of a registry key, introduced in commit 736dc0956a50315ec72ad126406556657a750d37 Author: Rüdiger Timm <rt@openoffice.org> Date: Thu Apr 17 14:19:46 2003 +0000 INTEGRATION: CWS vcl08 (1.57.2.4.18); FILE MERGED 2003/04/14 17:46:27 ssa 1.57.2.4.18.1: #108699# disabled flat toolbox buttons not exported anymore which only seems to apply to Windows. So just remove this. Change-Id: Idf315b8c89c3119883a5e6880d003d379fe6faec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105155 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-22Resolves tdf#137607 and tdf#137500 - Improvements to TotDHeiko Tietze
Shows tooltip for UNO commands Check if the UNO command is available in the current module Don't show the menu entry on the start center Change-Id: I5c67ec3f8543b5442a6e2c2a478bfeb4ec0e1f3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104558 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2020-10-22long->tools::Long in forms..frameworkNoel
Change-Id: I4cb29aade5ad1d3c3588b9437197e8493292872e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104625 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-16fix some *printf which are using "%l" ie. long specifiersNoel
which are not portable between Linux and Windows because long is not portable. In preparation for converting long -> tools::Long Change-Id: I8bf1aa1570946ca887a6c83dd5f99c024d437336 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104374 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-14More fixes of uses of now-explicit OUString ctor taking raw sal_Unicode pointerStephan Bergmann
...in Windows-only code, after c927aab29ebfff1ce3ac0b2f27ae343025a9890c "Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicit". Interestingly, these occurrences were accepted by MSVC and only cause errors with clang-cl, so happened to go unnoticed until now. Change-Id: I33e7653e28a21541ef793b4b0750abb6037752db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104314 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-14tdf#137356 framework: fix opening the same document twice for long loadsMiklos Vajna
If the document loading is long enough that the statusbar is updated, then we can have this situation that we start loading the document, then spin the main loop during load and do a second load of the same document as part of the main loop spinning: #0 SwDoc::SwDoc() (this=0x1c6a180) at sw/source/core/doc/docnew.cxx:194 ... #6 0x00007ffff359a6dd in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x1c5c260, seqArguments=uno::Sequence of length 15 = {...}) ... #33 0x00007fffeeb81ecd in Application::Reschedule(bool) (i_bAllEvents=true) at vcl/source/app/svapp.cxx:460 ... #36 0x00007ffff4265251 in framework::StatusIndicator::start(rtl::OUString const&, int) (this=0x1aace80, sText="Loading document...", nRange=1000000) at framework/source/helper/statusindicator.cxx:51 #37 0x00007fffd026dfd3 in XMLReader::Read(SwDoc&, rtl::OUString const&, SwPaM&, rtl::OUString const&) (this=0x1bb7d20, rDoc=..., rBaseURL="file:///.../test.odt", rPaM=SwPaM = {...}, rName="") at sw/source/filter/xml/swxml.cxx:630 ... #42 0x00007ffff359a6dd in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x1bce4d0, seqArguments=uno::Sequence of length 15 = {...}) at sfx2/source/doc/sfxbasemodel.cxx:1883 The reason for this is is that by the time LoadEnv::impl_searchAlreadyLoaded() searches for frames which already have this doc open, the first load is still in progress, and we assiciate the frame with its controller (which has the URL) only once the load finishes. Fix the problem by setting the URL on the frame directly for the duration of the load: this way an in-progress load also counts as a duplicate and we'll have just one document open at the end. Regression from commit 74ac65c49cc1d53b1aa93c2b7c720255867aace2 (#i114963# Enable IPC before OpenClients to allow client connections when printing., 2016-09-06), we just didn't process incoming requests on the socket before, so the problem was less visible. Change-Id: Ib138c4c264e2508c20104ab268501bcca31e2790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104310 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-02loplugin:reducevarscope in frameworkNoel
Change-Id: I79237d68d815f9b46277a496a05b596f58b4028b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103813 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-24Fix typoAndrea Gelmini
Change-Id: Iec2ac77967b3a5222dfedff4d7e7874c5502950d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103347 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-24framework: lock the solar mutex in loadComponentFromURL() with OnMainThreadMiklos Vajna
Regression from commit 2dc3a6c273cb82506842864481d78df7294debbf (framework: allow loading a component on the main thread, 2018-12-19), which was a forward-port from a 5.4-based vendor branch, where this was (it turns out) just working by accident, but never on master. It can happen that loadComponentFromURL() is invoked on a thread, which does not own the solar mutex. Then once vcl::SolarThreadExecutor::execute() is called, it'll try to release the solar mutex. But SolarMutexReleaser is unsafe: it'll release the mutex even if it is owned by an other thread. To make this a bit more safer, it'll abort in comphelper::SolarMutex::doRelease(), in case the current thread doesn't have the mutex already. Fix the problem by taking the solar mutex in loadComponentFromURL(): this is meant to cause no performance problems, since the actual importers typically start with taking the solar mutex anyway. Taking it earlier would be problematic, since this can be invoked by UNO clients directly. Taking it later in vcl/ would be also unusual: typically vcl just asserts that the solar mutex is locked, doesn't take it itself. Change-Id: I752006a91f16a02254d1b5ac6301100ab282630b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103264 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
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-18lok: make labels and tooltips translated for commandsSzymon Kłos
In the online we can have multiple sessions with different languages so load cached translations only if match current language Change-Id: I6fcf23f1c340c0c0daffa8862f0b74e4e458c1fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102016 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102960 Tested-by: Jenkins Tested-by: Szymon Kłos <szymon.klos@collabora.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-12replace sal_IntPtr with simple integer typeCaolán McNamara
Change-Id: I5aaf606b684b69641a872b3405b4d4d378289ad4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102466 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-10Remove some obsolete commentsMaxim Monastirsky
Change-Id: I80aa3a42818795168e9188cda3ceeff706254d89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102157 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-08Related: tdf#130445 Fix custom icon scale checkMaxim Monastirsky
There were two problems here: - For large size 26x26 was specified, but this was the case only for Galaxy. All other themes have 24x24, and that's the size specified also in the icon selection dialog (See SvxIconSelectorDialog::SvxIconSelectorDialog). - When a wrong size detected, the image was always scaled to 16x16, instead of to the current image size. Change-Id: I586abfd01441d6b1cdbf1dd011b0e12a31f02dd4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102225 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-08tdf#130445 Use actual icon sizeMaxim Monastirsky
maImageSize was always 0x0, unless the image list was first loaded from a correctly saved file. Just drop it, and use the actual size of the first icon of the list. Change-Id: Ifcda130ed1acdde7ce53dda6f4e1b3636be2bb03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102224 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-07loplugin:singlevalfieldsNoel Grandin
Change-Id: Ib3c8dc4e98ca46026ec9a8171bae4066bcec7b22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102176 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07loplugin:constantparamNoel Grandin
Change-Id: I83722d99fa0d5919a7e878d32311dbb6de1c6714 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102175 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07Pass correct module id and dispatch provider to the window menuMaxim Monastirsky
This matters in a merged menu bar (e.g. insert chart), where the Window menu belongs to the container rather than to the embedded object. (Same as for the File menu, see also commit 94a7a71b070d3911b39d1026ba266768b71ba8a6 - "MenuBarManager: Actually use xPopupMenuDispatchProvider".) Change-Id: Ia502674b778554378546f5629ea44bbb17c830ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102158 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-07MenuBarManager: Simplify module id handlingMaxim Monastirsky
Now that we have a single ctor, which always calls FillMenuManager. Change-Id: Ib6b04882ddde252a1dc81670576f76b4fc21ea09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102138 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-07MenuBarManager: Actually use xPopupMenuDispatchProviderMaxim Monastirsky
i.e. restore the fix for i#65734/i#75851, which for some reason was disabled in 3c471fa5480d58e867e05a1ef474a23aef94b07d. This can be tested by inserting chart into Writer or Calc, and looking at the File menu. Given that this menu is merged from the container app, it makes sense to use its dispatch provider for everything, not just for a few commands hardcoded in CommandDispatchContainer::getDispatchForURL of chart2. Change-Id: I03f233a84249284354ea709d8aa7c950390294e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102137 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-07MenuBarManager: Simplify addon menu creationMaxim Monastirsky
Addon menus were created with a different ctor, which called Init instead of FillMenuManager. But the former is just a subset of the latter, and I don't see in the latter anything particularly harmful for addon menus. There was however the bool _bHandlePopUp parameter, which controlled whether to create popup menus to be used by popup menu controllers, but: (a) it doesn't make any sense to me to allow controllers in some addon menus but not in others, and (b) the Activate method creates controllers unconditionally, which means that a controller might still be created, but then get nullptr for the popup menu, and crash. There was also m_bIsBookmarkMenu, which was set to true for addon menus, and used in the Select method to add Referer argument to the executed command. As a matter of fact, this argument is useless, as the referer is never evaluated for any command or macro execution. Only affected case might be when content URLs used directly as menu commands. But such usage isn't common, and even then an empty referer is similarly accepted by SvtSecurityOptions::isUntrustedReferer. However seeing the message of f0a9ca24fd4bf79cac908bf0d6fdb8905dc504db ("rhbz#887420 Implement "block untrusted referer links" feature") it appears that it's better to have the explicit referer anyway (but with a different check, as m_bIsBookmarkMenu is now gone). (Historically, the referer argument wasn't even introduced for addon menus, but for the new document and wizards menus, which used to be managed by the menu manager back then. This can be seen in commit 40fefd8e0d5937666129278fe2b27c36cb58033c ("support for images and target frames"). Only later this code path was reused for addon menus. That's why the member was called m_bIsBookmarkMenu, as "bookmark menu" was the term used for the new and wizard menus, and there was also a related BmkMenu class.) Change-Id: Idd48a0416f8703ef1a5c91e949345537ec9a5ec0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102136 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-07MenuBarManager: Set command name for addon submenu itemMaxim Monastirsky
This is the proper fix for tdf#99527, instead of the workaround that was applied back then. Change-Id: Ibbcac747e2b0ef421fd71b79eb9e536dc2f31771 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101891 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-01Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I8be2457de5018e1e764e378e609c3a41c3cb9d11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101802 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-01Fix typo in codeAndrea Gelmini
It passed "make check" on linux Change-Id: I275334508796c38c7eaaf6a99e435b4ed7b56f4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101787 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-31Remove remains of private:image/ via ImageIdentifier addon propertyMaxim Monastirsky
This is broken since commit 5c39b28a87060f80404079ab77604f664addb063 ("tdf#96059 Replaced imageproducer with CommandInfoProvider") but so far no one complained (maybe because the usefulness of such internal images from extensions is questionable at least). Given also that the whole ImageIdentifier feature (even its still working part) is obsolete since OOo 2.0.3 (according to the OOo dev guide), and that the availability of a particular image from an internal hardcoded image list by a particular numerical id is more an implementation detail, let's just remove the broken code instead of fixing it. In the meantime, the code was also copied into the newly introduced notebookbar addon code, so I handled it there too. There are also the registry schema and a sdk example that mention this feature, and need to be adjusted. Interesting that the particular example used there - private:image/3216 is actually broken since 2011 with commit 2559cab126f81375197051fb5b07ba6abb9efc77 ("FDO#42454 - EasyHack: remove code associated with unused icons"). Change-Id: I968b4fb8c5b207654476dd92c57d8db0815520ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101529 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-30Related: tdf#107548 Make sure embedded images have higher priorityMaxim Monastirsky
As documented in the schema, the dev guide and a comment in AddonsOptions_Impl::ReadImageData. Noticed the problem while testing the ProtocolHandlerAddon sdk example which has the ImageSmall props defined yet didn't show the icons. Turned out this was a result of the previous commit that fixed ImageSmallURL, which started now to override ImageSmall. Change-Id: I0a9eb6b13b73a60efc801905601894c862d68cba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101666 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-29loplugin:unusedfieldsNoel Grandin
Change-Id: I3f14647eed72898b641fbd583d18f914c7461628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101630 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-01-01 17:42:47 +0000