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>
so we can differentiate the case of embedded welded widgets co-sharing the
tab-cycle sequence with vcl widgets vs the case its all welded widgets
Change-Id: I5c57b4e98d2f5c543522a72e31d554a67c259307
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101485
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Just store the last used menu id, and consistently get all the
information (command name, image id, target frame etc.) from the menu
instance. Also implement the XSubToolbarController interface, so we get
a chance to update the image on icon size or theme change.
The initial action and icon of the button are based on the url passed
by the .uno:AddDirect status update, given that there is a corresponding
menu item. The only defined fallback now is to .uno:AddDirect itself for
both executing and getting the icon, but this shouldn't happen normally,
as I fixed all the affected cases I found so far, namely Base (including
windows like table design etc.) and the Basic IDE.
Actually these cases were partially broken anyway, and as a result now
completely fixed:
- In Base main app window, the button used to default to a new Writer
document, although its tooltip advertises Ctrl+N as the kb shortcut, and
pressing that shortcut actually opens the database creation wizard (as
expected).
- In the Basic IDE, the button was working, but not the Ctrl+N shortcut.
Change-Id: I6537b3f38e7d7001ec1b39d78285445464fd8cbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99514
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
leaving a dangling reference to m_aName. Hold a reference until
ExecuteCommand is finished.
Change-Id: I82ac5cc73427a945c78b9317dee9edf6129bb975
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98214
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
cause this assumption is baked into the vcl one making it hard
to adapt remaining cases
Change-Id: I75dd5264c65b1ffbf4d26c9a86f6d4d08b400d90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95622
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...as discussed as an open TODO in the commit message of
fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for
libstdc++ std::shared_ptr". The necessary changes across the code base have
been done fully automatically with the rewriting plugin on Linux. (All those
changes apparently involve uses of macro arguments wrapped in parentheses in the
macro body, but always in conditionally-converted-to-bool contexts. In other
contexts, such automatic rewriting would add the "bool" to the macro body, which
would be wrong in general, but we apparently get away with that sloppy coding
for now.)
The parenExprs_ stack that fe6cce01c88d045a1fcf09acf049c34c22299b02 had
introduced to treat such (then-undetected, it had turned out) parenthesized
cases now turns out to not be needed after all.
Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
until the next event cycle in cas the LoseFocus is happening due to an
in-progress selection event from a mouse down in the treeview that would be
updated
Change-Id: Ia4448aa798a8af7cd35bc17215891f6c5ca8678a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94494
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
so the macro editor isn't forced behind the window with an active dialog
Change-Id: Iae89f6910a8183bcf01872eef71c04bc993f1550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92307
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Update() is effectively "paint immediately". Rather just let the
invalidate do it's thing and have the widget paint on the next paint
loop, along with the rest of the stuff.
This is probably mostly cargo-cult, from the days when our
invalidate/paint timer could take a long time to kick in.
Change-Id: Idff06526e9a2892244cfd8ce6947916032b0d1a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90567
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
