Age | Commit message (Collapse) | Author |
|
Change-Id: I9d91fd5b260b82e05aac6567143386742953ecf6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119486
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This introduces internal tracking of last used directories.
Each caller of the file picker can pass a "context". The selected
directory will then be saved & restored when opening the file picker
with the same context again.
After ffa636ba74b04b3258ec9a696bc4eac33581fa24 , the Windows file picker
no longer tracks the last used directory itself.
This is a replacement and an improvement at the same time, since there is not
one global last used directory, but one per context.
Change-Id: I10650cfb9359922690954fa65c89b4e47477e2c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118597
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Rename ::StateChanged methods using SfxItemState to allow
better analysis of SfxItemState/SfxPoolItem usage(s),
discussion see tdf#130428 comment 30
Change-Id: I736be0160ad7a9b7882c1c8a4cc05d9396ee3305
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117366
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I0bb0ea9d39ed623928060ffd3f2e2bc36ba33209
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117272
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib08132199c343a057a398a50dc09ccab92ab944d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115632
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I076f16d0536b534abf0ced4d76051eadb4c0e033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: Ib3fc1b72d3d45377e2d4ccd0ff3e6835d2c29930
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113631
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Bit count for the image is a numeric value (sal_uInt16) but only
a handful of values make sense - namely 1,4,8,24 and 32. This
replaces the numeric value with an enum, which only accepts those
values and checks the correct values are used at compile time.
Change-Id: I0fc137c62bce3b0d021f05019a1648da628521bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112408
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
(*) fix bug in SfxToolBoxControl::StateChanged where it was using the slot id
instead of the toolbox item id
(*) I left the logic in SbaTableQueryBrowser alone, but it looks suspicious,
casting slot ids to toolbox ids
Change-Id: Ied229164c27fb4456b0515c6fdcbd1682766a1a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112186
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I91189ebd902b70e2fbe42fe8cc09b8677af1a5fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112194
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0cd6d6a4a45d77b25f04c3b49327f1cf9279c6a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111540
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I150a0f9ffe6ca10d9e92af347e5cc4b87a828125
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111351
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I99470067a34fab9fbc2ea53d2f8a634240f0d223
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111127
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I4f6aab6e1ad8d6db1575721312fd04b50dc29773
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110232
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
so the need to distinguish no longer exists
Change-Id: I4c11ddffbfa77f04497c454358c1c707ecf1d162
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109942
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
because of the side effects
using a bare GtkGrid as m_pSocket in vcl/unx/gtk3/gtk3gtkobject.cxx
is perhaps a poor choice, getting its xid causes poor side effects
wrt events belonging to its child widgets getting delivered to
the SalFrame widget, so duplicate scrolling after showing a opengl
slide and/or showing a video and lots of flickering
we're (generally at least) not using the xid under gtk3 so don't set it
unless it's explicitly asked for. Happily the gtk Player::createPlayerWindow
doesn't use its arg[0] xid in any case, so don't bother setting it for
that backend.
Change-Id: I1c59a607a332635091782c3b49de10647558f301
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109941
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
with an eye to making it on-demand
Change-Id: If6cefd68a336dc6afe23591c857bd71034215b54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109929
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I330e0ab6c9955939dad313f9d472f93e39dbd313
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109924
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This allows specifying a custom bitmap for a media shape. It's mostly
useful for audio-only streams where the additional bitmap may be e.g. a
speaker icon to indicate this a narration.
Change-Id: I21c1b492ac09b631cf6e3ec8120be8b82c01c26d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109763
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
However considering git history about vlc part (see
https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=vlc) it seems
there's no real patch since 2013 + it's been explicitely indicated as
experimental since 2015
See http://document-foundation-mail-archive.969070.n3.nabble.com/About-vcl-status-in-avmedia-keep-or-removed-unmaintained-code-since-7-years-tt4293282.html
Of course if someone wants to keep on the work on it, it's always possible to revert the patch.
Change-Id: Ia1602ea61b7ffa577148a80f974ebdcb71495fbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108283
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia462091459bd36c11511c88d384e352863f1cb81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108274
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Assertion when trying to insert a video in Impress, see bt:
https://bugs.documentfoundation.org/attachment.cgi?id=168161
According to https://en.cppreference.com/w/cpp/algorithm/clamp
"behavior is undefined if the value of lo is greater than hi"
Regression from:
commit 36b3b357fe2a882db6a5f5a006239e16200fb847
Author: Noel <noelgrandin@gmail.com>
Date: Thu Nov 12 16:10:56 2020 +0200
replace std::min(std::max()) with std::clamp
Change-Id: Idf33eb6c662b60174678f990f98aefc72edec2a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107722
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Change-Id: If7f47cf6dad860e4f8eab68931b72a38a7eda136
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107362
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia3f35f761cdfbfe6a57fce6bc632969759367c56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106603
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iba16ea38867499d2963e389dffec4e72daf1bcad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106605
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I76e34e8020d98292e8ffde387542b7029f85a42d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105754
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I341ef5abfc001e47d86a03960022b018aac8e35f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105741
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I66738a8bb23bb547249aa74f1f710b76bd7df516
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105643
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ib0008b9bb095f27e5e436d6b507dc709ab7bf01a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105313
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I67087c7a281e5bdecbaf227bd3147e7c12828791
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104587
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id4c2645652a9588d1a9a2658217662e93c59fdbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104387
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If3f882b4f28224d951492c26800d3009b8cb04b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103858
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
do more like
commit 121771e37f7e2de41cd5643475861062bf25627b
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...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>
|
|
Change-Id: I196549f168d67895510a239640c492cfc421fb07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97644
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I932675efaeb1072602775115fc368bbba7bfd2b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102134
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This commit was carried out by a Python script, source of which
is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97.
Change-Id: Iec8964e460e26778bbe9fe33e6130d7f179fae51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100142
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Icc264a185a025466c44351983919e0eb1010072b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If99d07d218499f7daa8b7294c216ddf2c0849b11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101908
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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: Ie429a10a8f54c6779d437ee4bc75a5ea0c427848
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100727
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
look for expressions like
!(a && !b)
which can be expanded out
Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|