Age | Commit message (Collapse) | Author |
|
Change-Id: I4225ce786b83f44178a477ac034d8f8f5198159e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101852
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The member aURL does not belong here and needs to be refactored,
the reason is that there can be two type of URLs - XML and binary
URL.
Change-Id: Ieb4e57a6f144070f95282a7fd02d08bda6d11f3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101084
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
ever since
commit 9a081484321b3f42bee3b43d18c4bd75b9603b01
Date: Fri Sep 14 13:42:47 2012 +0200
fdo#49571: ODF import: ignore "text:enable-numbering" attribute
Change-Id: Id90b9aa0feafc3d7427558d3a2394c4958111434
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101849
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I523a42b721056f17a04870229834b0f2db00ff39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101836
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icecc024c4385ec69508369d2645d8412e6dbff69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101835
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...from which an OString can cheaply be instantiated.
The one downside is that OStringLiteral 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 containers 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::string_view, without loss of efficiency
compared to the original OStringLiteral, and without loss of expressivity (esp.
with the newly introduced OString(std::string_view) ctor).
The new OStringLiteral 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 OStringLiteral is in all cases where an
object that shall itself not be an OString (e.g., because it shall be a
global static variable for which the OString ctor/dtor would be detrimental at
library load/unload) must be converted to an OString instance in at least one
place. Other string literal abstractions could use std::string_view (or just
plain char const[N]), but interestingly OStringLiteral might be more efficient
than constexpr std::string_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.
sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC
bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". Those places, as
well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx
and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been
replaced with OString::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).
This change also revealed a bug in at least recent Clang 12 trunk
CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least
in some calls from loplugin code (for which it can be fixed for now in the
existing compat::getSubStringAsWritten).
A similar commit for OUStringLiteral is planned, too.
Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I97608bcabb30eba94278562254f7f9954af080f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101837
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
It passed "make check" on Linux
Change-Id: I8336c2a639a1d45c8370fd13204896f3f1494b4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101801
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
It passed "make check" on Linux
Change-Id: I8bcc1598c7b885a025dd990eb2f75551e15b5c13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101794
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...to 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral from
char[] to char16_t[]"
Change-Id: I661e1b1ce59461f30a9c1d75a1e4acb71fa113f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101770
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic5ac71d88bab7627e14220912f4b9c935f2f1f26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101709
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I90d380efecbd5ed88e16b5f20603ff0183144302
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99945
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Abstract class for GalleryBinaryEngine and upcoming GalleryXMLEngine. This
interface will be used by GalleryTheme.
Change-Id: I2193e3ea9860c41a1580d5ca59da68bf41b70a3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100025
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: If76dc19adc13548afc0ee5b521321ca439da638d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101782
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
It passed "make check" on Linux
Change-Id: I5aff28a8d241441335d4cede12a013384945aa9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101789
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
It passed "make check" on Linux
Change-Id: I9f3d98df05495e7d655a93c5cd5bbd41db6a9bea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101788
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I57611e6bc3a8dadcdeb7aff99f4788aac4d7e105
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101799
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Move m_aDestDir out of GalleryTheme because only GalleryBinaryEngine seems to be using it.
Use SetDestDir() to delegate the member value to GalleryBinaryEngine.
Refactor WriteData() so that it's called writeGalleryTheme()
Change-Id: I5f6b6f0857695adeb102342e617ad341553abd14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99940
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
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>
|
|
It passed "make check on Linux"
Change-Id: I53b40e36c6b1c0aa115044208b5a372fb101347b
|
|
Change-Id: I64b8e461cc692c6c9683df52dc1fea6b2e5a937e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101697
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Move "grahic" to "graphic"
It passed "make check" on Linux
+ Use "#pragma once" in include/svx/svxgraphicitem.hxx.
Change-Id: Ia8a42afd1a822e19093ecee7b0b8791f96de2867
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101623
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
It passed "make check" on Linux
Change-Id: I7596db11cae77c2dcadd740c44cc72fd5dbceb9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101619
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
new ODF chart series style attribute for saving not default
(switched off) state of data labels in custom positions.
Note: import of the embedded chart of the DOCX unit test
document uses also ODF format in the background, testing
also this loext attribute, i.e. the chart of the unit test
document doesn't contain custom leader lines.
Change-Id: Ia6b76e8d7fe5b6b6204761f3bbc2309f1b631008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101442
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
...introduced with 2e21240f23ac2191a3535d697a7308b29303c67c "Goodbye
O[U]StringView, welcome O[U]String::Concat". Thanks to Mike for spotting them!
Change-Id: Ic401c564eac03a34184204f09cb8d0cb6be4e6e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101689
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
O[U]StringView had an odd mixture of uses. For one, it was used like
std::[u16]string_view, for which directly using the latter std types is clearly
the better alternative. For another, it was used in concatenation sequences,
when neither of the two leading terms were of our rtl string-related types.
For that second use case introduce O[U]String::Concat (as std::[u16]string_view
can obviously not be used, those not being one of our rtl string-related types).
Also, O[U]StringLiteral is occasionally used for this, but the planned changes
outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral
from char[] to char16_t[]" commit message will make that no longer work, so
O[U]String::Concat will be the preferred solution in such use cases going
forward, too.
O[U]StringView was also occasionally used to include O[U]StringBuffer values in
concatenation sequences, for which a more obvious alternative is to make
O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat
machinery.
Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6a1596bdbfa4db128730a663fc590c9e5bfa249d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101659
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2be47d2faf883b519f693e2d5ad58a5ab111849f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101629
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I977f1cf198652d3c73e5a0f473794975a5647617
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101564
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
0c8fa58a2d73702770687ed15b98822d09f96ac3 "Support ConstCharArrayDetector also
for UTF-16 arrays" had introduced those LIBO_INTERNAL_ONLY ctor and operator ==
overloads, but they never got called because the existing 'sal_Unicode const *'
overloads always won.
(The other function overloads introduced with
0c8fa58a2d73702770687ed15b98822d09f96ac3 should be unproblematic, as they do not
have any 'sal_Unicode const *' overload counterparts.)
Also fix the resulting loplugin:elidestringvar and loplugin:stringconstant
fallout. For one, those plugins look at the actual ctor overloads being used,
so had missed those cases that accidentally had used an unexpected overload.
And for another, the heuristic the plugins used to detect the
ConstCharArrayDetector overloads turned out to be too simplistic now and would
have started to cause false positives.
Change-Id: I4426890979fb832d53f391c7e1b62bc1ad501a65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101582
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3980bbaf269260243c8fcd8fe95cc03deac144ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101558
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id92cf1d685559665562d979d70662319ff4b36d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101504
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibc22de48f1ef92d8efbe0167aff3a434ecef9afb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101503
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib0389fa53ce2516cdd1f9ad8e68d9209455b4359
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101534
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6c224a68057c7c593dd37299cc4079bd97519cb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101550
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I310fe566ba3df511e4499afe0c9f7206f3451ff9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifc17271a202a36cc2801fcb67057c294791033ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101499
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5bb603fe1d615f7df790bcd352beb09d65dcb3a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101536
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I4b4f98dae1e719511fcfd943e046644c56b3c252
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101498
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9c73dba293cd831834a560e9fd8e8c2d135e2358
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101494
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.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>
|
|
Change-Id: Ic0a4e4911bb56fd9731e0e9d3850387b1f26b1d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101474
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ice3c01019d3e961c0ef1dce7d3eaf4f602269fff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101488
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@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>
|
|
Change-Id: I77dbc21910b01524d281869a83d9d12efd419bf6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101446
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib7fda3bbf25046f307dcd080e918d159358b4c90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101445
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If78be8caf1b1a87ef16abf04a29bc30762ddb90b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101440
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I563f917c741130909a9d726754cd3eb23a651a11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101429
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I49c4a95dc30584753724c1f824f12ce33317312d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101428
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If7791d51d055ad918b54a52bee3f13a79c5468f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101435
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|