Age | Commit message (Collapse) | Author |
|
Change-Id: Ibce58dc277a703881de91bebdfd8b328c820a28e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124373
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I88909cf813f39a52c70d3cbcb19ff326d9bb42d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123069
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa
Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
mostly by doing
$ git grep -l '#define.*\"' -- *.cxx
| xargs perl -pi -e
's/^#define\s+(\w+)\s+(\".*\")/constexpr OUStringLiteral \1 =
u\2;/g'
Change-Id: Idface893449b0ef2a3c5254865a300585d752fbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119669
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9903a2717fe9019c45c4ecc3e7dcaed7e1a9d9f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If2ea21cd52ddae821598398524c84b5b22817c33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119729
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's a bad style, doing that in headers can affect many source files
(especially with PCH used).
Change-Id: Ic9091a1d018e74606c9fa95df71a55faaa93d4ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119011
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...ever since the code's introduction in
4e386a897cd43aae3664ce68e47dd46b271de780 "INTEGRATION: CWS macosxspellchecker"
Change-Id: I932b7ff4cc8aabf2e70379ed9ebe361881246c46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116997
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The system German dictionary accepts 'ß' which is not used in Swiss
Standard German but completely replaced with 'ss'. We assume that the
LibreOffice German dictionary is installed, too. It has correct
spelling for de_CH.
It would be good if we knew in the macosxspell code whether the
LibreOffice German dictionary installed, and act correspondingly. But
figuring that out seems more complicated than what I am willing to
spend on this for now.
Change-Id: I380d7734cea34a2408d9ed20a8c3d9efe6a8fea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115690
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I2cc70345d508da17d466d04c6a9a59b689e9ae16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113797
Tested-by: Jenkins
Reviewed-by: Hossein <hossein.ir@gmail.com>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Build our lnth library and the external mythes library. Install
thesauruses for the app's Xcode project to pick up and include in the
app bundle. Look for them in the place where they will end up.
To get thesauruses you need to configure with --with-myspell-dicts.
Change-Id: I2d850ca3c821c5c764cb061340a265440d04e41b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113066
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113073
Tested-by: Tor Lillqvist <tml@collabora.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>
|
|
Fixes https://github.com/CollaboraOnline/online/issues/1463
Change-Id: I9fffd4bc9499aee2098258f5c3a9181330b339a1
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112670
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112690
|
|
The iOS system German dictionary is not good for Swiss German. (And it
doesn't even claim to be, it says it is for de_DE.) The system German
dictionary accepts 'ß' but that is not used in Swiss German, 'ss' is
always used instead.
Build the spell library for iOS, too, and don't assume that the system
de_DE dictionary would be usable for de_CH and de_LI. Copy those
dictionaries for inclusion in the iOS app bundle.
Change-Id: I0f8020812221024756c792bddc16a707de35b827
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112603
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112635
|
|
... where the object is created in-place, and its type is known
Change-Id: Ifabfcf2f3ad0d60152f14e8d970c1faa42115288
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112256
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id68d9c9733738595aeb4bad24d77f77da2878e83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111830
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7471725f1e658940b5e6993361c327be6ccf0d31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111064
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I02790afc314c8633a24dbf23001f3d5cffe169b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108478
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...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: Ia156fe8eb259fda0c23275fcaebc6b37790f11f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105688
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
|
|
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I802ee5ac618aa706b126630c8bb4e7e2e83c59f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103852
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
regression from
commit 3fbadfa1ad41a3477804c592e06caec708c05218
lingucomponent: create instances with uno constructors
Change-Id: Ie53c56a88dc1c15178219b0098803586164837da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99038
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Before
commit 3fbadfa1ad41a3477804c592e06caec708c05218
lingucomponent: create instances with uno constructors
Thesaurus was constructed but Thesaurus::initialize was NOT being called
from GetAvailLocales.
However, we have some code marked "HACK" in
cppuhelper/source/servicemanager.cxx
i.e.
ServiceManager....::createInstanceWithArguments
which DOES call initialize.
And we have code in GetAvailLocales which passes what Thesuarus
considers an invalid number of arguments, because all the other similar
services DO take 2 args (even though they don't use the second arg!)
So we have a bunch of temporary hack and backwards compat stuff
interacting, causing a SAL_WARN.
So make Thesauras::initialize a little more tolerant, which means we're
now initialising it, which is a change in behaviour, so if this commit
comes up a regression, we will need find another warn to stop the
warning.
Change-Id: I60e0ed1bd2d4fbccbc539b5536aba055a7dfc6c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99039
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: I850e5b243750cbe168136907523d1ada7050c453
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98924
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: I11770c8873d14cfd0e438fb580d8d0ea9e99f594
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98709
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Common::Misc::OpenCLWhiteList -> OpenCLAllowList
Change-Id: I65636b19b13e4af1e4851f70e78053f3443d6bb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98181
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I70423a669527f2ce6ec25f58b8c409c0e2231962
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97604
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I45c85db44c3dfd92e0929f66c8c95cb309c91e05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96609
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
|
|
Workaround to fix non-BMP Unicode characters in
the case of Hung (Old Hungarian) module, resulted by
std::wstring limitation on Windows.
Change-Id: I4f6a72ad0e3d4f70ef7e35910bb4147aedb0e4ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96562
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
It was fairly pointless to be able to --disable-libnumbertext.
Besides, disabling it broke the ordinal page (etc) numbering feature:
"1st", "2nd", "3rd", etc showed up as "Ordinal-number 1",
"Ordinal-number 2", "Ordinal-number 3" etc.
Change-Id: I645169054a8fdc8dac89cd48b6c369fd61749467
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96119
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
In right-to-left paragraph mode, transliterate
Hungarian text word by word during typing, also
add the associated checkbox to Localized Options
page of AutoCorrect dialog window.
Old Hungarian (ISO 15924: Hung) is a historical
and renewed script which is still in use to
transliterate Hungarian writing.
As a localized AutoCorrect feature, the patch supports
the followings:
– word-by-word transliteration of Hungarian texts only
in right-to-left paragraph mode.
– consonant disambiguation of digraphs and trigraphs
based on hyphenation (now pattern-based Huhyphn
dictionary of libhyphen, planned dictionary based
Hunspell later)
– transliteration by extended hu-Hung module of
Numbertext library.
Note: transliteration of the selected text using
AutoCorrect Apply function has't been implemented, yet.
Change-Id: Iee0f18e2485c974c35acf0a3abc3a49c2cf80196
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95303
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I1de87468b56b86a1eeee09a612551ab119a1be8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93857
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic0bf912a22e8efeae1a4f4864397f3f3d474c632
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91803
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If95f1ea5a81de62eb4f725e5fcb30ccb8530062a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87372
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Using only the system spell checker (through MacOSXSpell) is what we
have been doing anyway.
Do not build the hunspell or mythes externals for iOS. Do not build
the lnth or spell components for iOS.
Change-Id: I2e2abc268d7719e540072e5daff3f7960e04ed27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86172
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86174
Tested-by: Jenkins
|
|
Change-Id: Ib30fe34123ad7e5d892e8db9c742e08c4ca8fcd2
Reviewed-on: https://gerrit.libreoffice.org/85477
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I333d91ea5ce78c82e9bb107f934614efc7bfb8f7
Reviewed-on: https://gerrit.libreoffice.org/85078
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* Add checkbox to pagraph dialog
* Store property in paragraph model
* Move docx import/export from grabbag to paragraph model
* Add ODF import/export
* Add ODF unit test
* Add layout test
Change-Id: Id4e7c5a0ad145c042f862995d227c31ae2aa0abd
Reviewed-on: https://gerrit.libreoffice.org/83979
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Idf5b7be45d48076fbe191fbf1a2fa63c6da71902
Reviewed-on: https://gerrit.libreoffice.org/83617
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...to find matches of
... << s.getStr()
(for the rtl string classes) that can be written as just
... << s
Some notes:
* The OUStringToOString(..., RTL_TEXTENCODING_UTF8) is left explicit in
desktop/source/app/crashreport.cxx (even though that would also be done
internally by the "<< OUString" operator) to clarify that these values are
written out as UTF-8 (and not as what that operator << happens to use, which
just also happens to be UTF-8).
* OUSTRING_TO_CSTR (include/oox/helper/helper.hxx) is no longer used now.
* Just don't bother to use osl_getThreadTextEncoding() in the SAL_WARN in
lingucomponent/source/hyphenator/hyphen/hyphenimp.cxx.
* The toUtf8() in the SAL_DEBUG in pyuno/source/module/pyuno_module.cxx can just
go, too.
Change-Id: I4602f0379ef816bff310f1e51b57c56b7e3f0136
Reviewed-on: https://gerrit.libreoffice.org/80762
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I40d51fbdd712d1e6e64cede05338c07a06261d8a
Reviewed-on: https://gerrit.libreoffice.org/80568
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I858870d883de10a673d7ce2798bda8c8f511cee5
Reviewed-on: https://gerrit.libreoffice.org/79889
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Apply the constmethod plugin, but only to accessor-type methods, e.g.
IsFoo(), GetBar(), etc, where we can be sure of that
constifying is a reasonable thing to do.
Change-Id: Ibc97f5f359a0992dd1ce2d66f0189f8a0a43d98a
Reviewed-on: https://gerrit.libreoffice.org/74269
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use range-based loops, STL and comphelper functions.
Change-Id: I975a9c09265976d5ce4a1d7ac2023cbb75bb7f28
Reviewed-on: https://gerrit.libreoffice.org/78242
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
look for places we should be using std::as_const on for-range
loops over uno::Sequence, to avoid triggering a copy
Change-Id: I7efb641bf09d37c87946f03428ee4eec90298c8a
Reviewed-on: https://gerrit.libreoffice.org/77441
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I72cc7132721706b3a5e06480efbae42065c36661
Reviewed-on: https://gerrit.libreoffice.org/77319
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|