summaryrefslogtreecommitdiff
path: root/framework
AgeCommit message (Collapse)Author
2021-07-01sfx2: try to fix lifecycle of SfxOfficeDispatchMichael Stahl
This can be created either from the global SfxApplication, or from a SfxViewFrame. Particularly in the latter case, the SfxDispatcher and SfxBindings members are owned by SfxViewFrame, so in case that is destroyed, the SfxOfficeDispatch must clear its pointers. It looks like the member pointers are checked before access already everywhere, so just listen at the SfxViewFrame. Change-Id: If08825734e94dd54e32cb77546684fd583c336ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118162 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 7cbd6d768d282077053c354254315f3dc89bf254) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118195 Tested-by: Jenkins
2021-06-28tdf#143047: When no properties for command, use those from item containerMike Kaganski
This allows to use the "Label" property defined by user for macro items, that indeed have no built-in command properties. Thus the resulting tooltip will be a concatenation of the label and mnemonic instead of only mnemonic as happened before. Change-Id: I79d933fecd09ca7d64b7a3e7db0ef194e42c1c55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117787 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 8383175bd3c714c163eac40a00b1e8277d4d5307) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117857 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-06-10dtd files are not xml files and shouldn't have xml headersCaolán McNamara
so rpminspect is correct in complaining that they are not valid xml on inspecting files claiming to be xml Change-Id: I70379989326c2ea63e6a54b3658ebea4684fa5df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116892 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-01-24tdf#139774 fix wrong use List Box icon in Combo Box right click menuRizal Muttaqin
Change-Id: I23e48ea99f05c38c68747218a3191e76c715f0c9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109660 Tested-by: Jenkins Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id> (cherry picked from commit 3d3a0c412500a2b57ff1d49f05506ee62ef9d4c7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109802
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/+/107383 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
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-28Use ToolBarMerger::IsCorrectContextMaxim Monastirsky
Change-Id: I1256dcacd364b332232872f48a4eb3ec979fb0a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101512 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-28MenuBarManager: Extract the window list to own controllerMaxim Monastirsky
Change-Id: Iad3df8cfe0814f510effaac2b7ba6dd926baab7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101476 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-27Command icon changes not reflected in menusMaxim Monastirsky
Regression of commit 7383ab517030db0c2d7bf4f393f38743fbcaba04 ("loplugin:constantparam in f*"). To reproduce from UI: 1. Start Writer with gen. 2. Open the File menu at least once (so m_bRetrieveImages set to false). 3. Right click on the Standard toolbar > Customize Toolbar... 4. Right click the Open toolbar button > Change Icon..., pick some new icon, and confirm the changes. 5. Open the File menu and notice that the Open... item there still has the old icon. Change-Id: I89ba87aafc56192dc150741244d5cd7c6f7923e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101443 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-27Don't pass ResourceURL unconditionallyMaxim Monastirsky
In case !m_bResourceURL, this is not only unnecessary but likely incorrect, as it's a dispatch command name, not a UI resource URL. This helps avoid "The given URL is not valid: .uno:SaveAsMenu" warning when clicking the toolbar save button dropdown. This also reverts 1cbbf63b7670a3d85a5a29df6124467e954cc7e9 ("Always prefer Value over ResourceURL"), which no longer needed. Change-Id: Ic09c5893988c75c9f5dabb9eb5e2d557fc7fcbcf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101475 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-21Resolves: tdf#135965 blank helpids for EditControl childrenCaolán McNamara
so the helpid of the EditControl itself is chosen and LibreLogo's help can be shown with F1 Change-Id: I02cf0921dc96533f00149f8fdb4d41b62644ed32 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101144 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-20Base addon toolbars on the regular ToolBarManagerMaxim Monastirsky
ToolBarManager already supported addon buttons because of the toolbar merging feature. Besides the cleanup, this gives access to addon devs to all toolbar features like aliases or style buttons. Change-Id: I7adf830ac71c7f5354a924d60a531d8001e37571 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101071 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
generated by cgit (git 2.34.1) at 2024-07-13 18:44:43 +0000