...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>
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>
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>
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>
...in Windows-only code, after c927aab29e "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>
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 74ac65c49c
(#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
Regression from commit 2dc3a6c273
(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
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "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>
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>
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>
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
94a7a71b07 - "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>
i.e. restore the fix for i#65734/i#75851, which for some
reason was disabled in 3c471fa548.
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>
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 f0a9ca24fd
("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 40fefd8e0d ("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>
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>
This is broken since commit 5c39b28a87
("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 2559cab126
("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>
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>
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>
Regression of commit 7383ab5170
("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>
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 1cbbf63b76
("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>
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>
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>
Started as a copy-paste error introduced in commit
a2f4aed322 ("fdo#66524 - defer
loading and scaling AddOns images until necessary."), which
was removed later in 9a65df2513
("coverity#1078526 Logically dead code").
Also, the high contrast properties are no longer supported,
but they still read and were overwriting the big image property.
Change-Id: I005bf5873fe821896c143d8fb513b2f73f05bba1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101028
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Noel