Change-Id: If9dd9437ebdc83e9093d4ea00f31d2e2da95b7d2

Building against libstdc++ effectively always requires -pthread anyway (as
various standard C++ headers require it, see the comment added to
solenv/gbuild/platform/unxgcc.mk), so many explicit uses of -pthread/-lpthread
can be removed.

Doing a (partial) test build on Linux with Clang -stdlib=libc++ suggests that
libc++ indeed doesn't need -pthread as libstdc++ does.

The remaining uses of -pthread/-lpthread are mostly in configure.ac for the
various BSDs (which somebody else might want to clean up now), and related to
external projects.  I tried to be careful to remove -pthread/-lpthread from
makefiles only when C++ object files are involved (so -pthread will now be
included on the link command line by default).

Change-Id: I936e082839cb9a434bd273ce5a1f187a4245dfa1
Reviewed-on: https://gerrit.libreoffice.org/71291
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I22431e026c1802e33064aa60267de0edbdf856ca
Reviewed-on: https://gerrit.libreoffice.org/71253
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

in a FOR loop, by removing the range(x,,)-like double
commas in this case, too, during program compilation.

Previous empty (missing) argument of RANGE was checked
by the terminating comma, but it can be a white space
after it, as in the following example:

FOR i IN RANGE COUNT 'letter' [ PRINT i ]

Change-Id: I67d0a4f089be06f30003d1b979b8f1801dbfa2e9
Reviewed-on: https://gerrit.libreoffice.org/71263
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>

At least since 7a08bfea "tdf#122244 Put
InfoPlist.strings files at correct places on macOS" those directories that have
actual content are created on demand.  (That is, empty such directories are no
longer created, but I assume that's a feature rather than a bug.)

Change-Id: If753483c78fbf39e76c9565a407e7ff27ca32efb
Reviewed-on: https://gerrit.libreoffice.org/71300
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

See https://lists.freedesktop.org/archives/libreoffice/2019-April/082479.html
Ths partially reverts commit 1463625a

Change-Id: I36ec01c8d331d879143f60e12dc239158a8822ec
Reviewed-on: https://gerrit.libreoffice.org/71301Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

(1) Migrated all still existing binary load/save stuff
in SfxPoolItem to legacy files. Isolated from Item
implementations. Adapted all usages. No more methods
Create/Store needed, also GetVersion removed

(2) Removed operator= for SfxPoolItem. Adapted all
usages. Goal ist to handle Items more as Objects
('Object-Oriented') in the sense to move/handle
instances, not to copy one instance over another one
(which is more and more problematic with hard to copy
content as UNO API stuff or similar). This lead to
much more usages of std::shared_ptr which correlates
well with future plans fr Items (see dev branch).
Next logic step will be to also remove copy constructor

Linux build and corrections done
Fixed Writer test and removed unused defines
Fixed another unused m,acro
Started to unify the AutoFormat stuff
Changes to OUString constructor usages, tests completely
No idea why, but SfxStringItem constructor which
takes a OUString& now insists of not getting ::OUString's
handed in - changed all 'SfxStringItem.*OUString.*".*"'
accordingly

Change-Id: Ibed7358b18fb019994a7490332b9d797a6694c29
Reviewed-on: https://gerrit.libreoffice.org/71075
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>

Change-Id: Ibe76cc8950e26f0b78425f91faae2f44b5474ea7
Reviewed-on: https://gerrit.libreoffice.org/71264
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: Ie608aea0cd65d6bc6a3c5d700650ac3b9d3241a9
Reviewed-on: https://gerrit.libreoffice.org/70998Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Similar to 88be8aa1

Change-Id: Ia6f725fd6c6cee3135191a998ea43c1e6f90fc23
Reviewed-on: https://gerrit.libreoffice.org/71287Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Change-Id: If10507a51cf4b680034e225ec011f43f624ca34c
Reviewed-on: https://gerrit.libreoffice.org/71259
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ib4b6031b31500a8a2086721124b5b8f554f7c1c5
Reviewed-on: https://gerrit.libreoffice.org/71296
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

...at least since 7a08bfea "tdf#122244 Put
InfoPlist.strings files at correct places on macOS", though it wasn't under
Contents/ at least as of lately, anyway.

The code to remove it had been added with
f345a2c5 "We don't want those
bin/InfoPlist_*.zip files in the app bundle".  I don't know how to do a
--enable-macosx-code-signing build on macOS to verify that it can indeed be
removed, though.

Change-Id: I61d91bd47abf8f4b5d9e117d9943e0682ebef2cb
Reviewed-on: https://gerrit.libreoffice.org/71298Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: I9d0204161a0efe91ebcddaf5b2931ab156221b79
Reviewed-on: https://gerrit.libreoffice.org/71283
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Icd00e2aaa5932564668cd12ce4ee63aecc34419a
Reviewed-on: https://gerrit.libreoffice.org/71226
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I1f46c6043b3263ef983991ffa4aa0418006d55a7
Reviewed-on: https://gerrit.libreoffice.org/71292
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I54c1f438a755267db0896637c79f915de9113f83
Reviewed-on: https://gerrit.libreoffice.org/71074
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>

follow-up of 10c93414

Change-Id: I2085173dffd71dbbc68a0574400bebe132626dd9
Reviewed-on: https://gerrit.libreoffice.org/71284Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Change-Id: I28e8d8e4ab940ae838fc555702b5580dc76931dd

InfoBarType::Success adjusted to the newly added successbox
see also I829218d014c13698d075e0fcd3162801d31ba093

Change-Id: I6b542928f3d1d1940b9da36b4c40cd8af97fb2f5
Reviewed-on: https://gerrit.libreoffice.org/71285
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>

Change-Id: I7fb59039429361dad04fb68507f40545f9c4dd6d
Reviewed-on: https://gerrit.libreoffice.org/71290Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

* Update translations from branch 'master'
  - update translations for master
    
    and force-fix errors using pocheck
    
    Change-Id: I04522500fe14e0d09925b196ccf7b7f94f3bfe64
    

Don't know how this got broken, presumably somewhere along the line from
01344a8c "convert sysui to gbuild and add to
tail_build" through 4430ace3 "tdf#90753:
AutoInstall more packages" to the current state, where a spurious bin directory
containing InfoPlist_*.zip files containing (empty) InfoPlist.strings files is
placed in instdir/ and in the root window of .dmg files.

As discussed in the <https://developer.apple.com/library/archive/documentation/
General/Reference/InfoPlistKeyReference/Articles/
AboutInformationPropertyListFiles.html> "Localizing Property List Values"
section, those InfoPlist.strings files shall apparently be placed into the
Contents/Resources/*.lproj/ directories.  (And the zip wrappers were presumably
needed in the past to transport their payload to the proper places in the
installation set, and are now obsolete.)

The list of Apple language IDs for the *.lproj directories was already
duplicated in Makefile.in (test-install target) and
solenv/bin/modules/installer/simplepackage.pm (sub create_package).  Ultimately
those lists should all be consolidated.  Also, mapping from our language IDs
(see solenv/inc/langlist.mk) to the Apple *.lproj ones needs some fixing (e.g.,
from zh-CN to zh_CN), and it is not clear to me why the old code explicilty
added en-US to the gb_WITH_LANG list of languages for which to generate
InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the
non-localized strings stored in Info.plist itself).  But as mentiond, those
InfoPlist.strings files are all empty anyway (which may be due to another bug?),
so it shouldn't matter much---at least for now---what
Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an
installation set.

Change-Id: Iaadce2375ed319928891bace44f9866622ec3084
Reviewed-on: https://gerrit.libreoffice.org/71277
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

I faced the same problem in
https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/commit/?id=f631db9e5e83706ed2678fb4db737700dd623a1b

Change-Id: I1adcc418e0efa7e77e1dda5b9dccd7c55cb5267f
Reviewed-on: https://gerrit.libreoffice.org/71280
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ia7dc9879aeaa978d1cb1b0573fb69bd63bd5d4e0
Reviewed-on: https://gerrit.libreoffice.org/71278
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: I16dfde335816053e5821d5e975b27b6e4819b1a8
Reviewed-on: https://gerrit.libreoffice.org/71135
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: Ie5310d3c3d4fde59a0718dbda228c638b7e0c366
Reviewed-on: https://gerrit.libreoffice.org/71235
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I829218d014c13698d075e0fcd3162801d31ba093
Reviewed-on: https://gerrit.libreoffice.org/71265
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: I1a3396d434f6cc5bb615bcb2fe06a819bc11c013
Reviewed-on: https://gerrit.libreoffice.org/71256
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Similar to 88be8aa1

Change-Id: I616ad50bfdc4c11be9b377e218636092adc3bd42
Reviewed-on: https://gerrit.libreoffice.org/71249Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Change-Id: I350c2c96cd178878ae687dd5214fcabfcf7675e7
Reviewed-on: https://gerrit.libreoffice.org/71254
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

This is the first try of a new TabBar look - borders have been
removed, selected tab doesn't change the font to bold, adjustment
to the selected tab line.

Width and height of a tab item has been adjusted to make it
better to fit the icons in and to not be so cramped.

Draw "protected" status of an tab icon (in Calc) as an icon and
not as a unicode glyph.

Change-Id: If2ee930a573343166fbe9efcd94ae5159a620f22
Reviewed-on: https://gerrit.libreoffice.org/71238
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

Seems like this is a somewhat pathological document, has lots of
duplicated ranges. Checking for duplicates makes it load in <10s on my
machine

Change-Id: I25da24e0f8b1d4ad99d00474be168c75586ea579
Reviewed-on: https://gerrit.libreoffice.org/71251
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I6607ef2c9ca0860643cd57f9bde171ea1a7ca3af
Reviewed-on: https://gerrit.libreoffice.org/71269
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>

When 'QFileDialog::Directory' is set, the native
Plasma QFileDialog does not consider the clicked
directory to be selected, but rather the base directory
shown in the dialog, s.
https://bugs.kde.org/show_bug.cgi?id=406464 .

Therefore don't set the option when in a KDE Plasma desktop
environment (which the kde5 VCL plugin also doesn't do).

This works around the above issue in the Plasma desktop
integration.

Change-Id: Ib3d0978ab56b6e50ee45f7ad997ec051b35faf54
Reviewed-on: https://gerrit.libreoffice.org/71223
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>

Change-Id: I7db23f84a3de4772b38c9538704f501a9169ce09
Reviewed-on: https://gerrit.libreoffice.org/71267Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: I02e84f888950c85e19f50ffe7ace52e71a24e397
Reviewed-on: https://gerrit.libreoffice.org/71266
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

...but only with old MSWord compat flag SplitPgBreakAndParaMark.

All of the other cases (COLUMN_BREAK and non-empty runs) split
the paragraph, so why not here?  This document shows it is needed,
but only for SplitPgBreakAndParaMark documents.

Note: Word 2003 doesn't display "modern" docx well in this regard.
It adds extra paragraphs where it shouldn't. There are already
example unit tests that ensure that extra paragraphs aren't written
for SplitPgBreakAndParaMark == false.

The actual bug's document is not related to the compatibility flag.
That will be handled in separate commit.

Change-Id: I27399780c909663f9a2b21974a5b385bea67f9ec
Reviewed-on: https://gerrit.libreoffice.org/70835
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>

Move TableColumn Java tests to C++ for ScTableColumnObj.

Change-Id: I3f17fa1f25c2676124b56c384364e36736fac849
Reviewed-on: https://gerrit.libreoffice.org/71261
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Change-Id: I08d5b060b6756a89972eeec57c1f9c85e6f65500
Reviewed-on: https://gerrit.libreoffice.org/71262
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>