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

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

Remove that tabs from Bullets and Numbering dialog because they are
already exists on sidebar.

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

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

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

...so better make it std::atomic<> (and it also can be private).  And in
SolarMutex::doRelease, make sure that m_nCount is only read with m_aMutex
locked.

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

the only thing it picked up is the SvxFieldItem stuff, which cannot use
this feature because the editeng and sc code likes changing some of the
data in these supposedly immutable data classes

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

The separate filepicker executable 'lo_kde5filepicker'
used by the gtk3_kde5 VCL plugin needs the KF5 libraries
(in particular the 'KFileWidget' class) in order to
provide custom controls in the Plasma-native QFileDialog.

The gtk3 side ('lo_kde5filepicker') itself doesn't use
any functionality from KF5 libraries itself and therefore
didn't link against those.

When determining which VCL plugin to use on LibreOffice
start, a 'dlopen()' is used on the libraries of the
potential VCL plugins, which fails if linked libraries
are not available, so unsuitable VCL plugin are skipped.

This mechanism didn't work for the gtk3_kde5 VCL plugin
if KF5 libraries were not installed, since the 'dlopen()'
on 'libvclplug_gtk3_kde5lo.so' would succeed, but starting
the 'lo_kde5filepicker' process would later fail at runtime
due to the missing libraries.

To avoid this, make 'libvclplug_gtk3_kde5lo.so' link
against KF5 libraries as well to prevent gtk3_kde5 from
being used unless all required libraries are actually present.

Add a dummy KFileWidget use in Gtk3KDE5FilePicker to prevent
smart linkers from not linking unused libraries despite linker
flags.

While this is a hack, it seems to be acceptable, in
particular since gtk3_kde5 is more meant as a temporary
solution supposed to be dropped at a later point in time
in favor of the pure kde5 VCL plugin.

Change-Id: I3a37daaeb1307b4f24f6fd75d7b6ec5ffaade0fd
Reviewed-on: https://gerrit.libreoffice.org/71237Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Jenkins

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

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

since...

commit a91992e7
Date:   Fri Nov 16 16:26:38 2018 +0100

    sw: SwTextNode::GetAttr() inconsistency

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

Change-Id: I6c034310ffcc5eacf7db0064d739a9796d66d6e4
Reviewed-on: https://gerrit.libreoffice.org/71325
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

Replace OSL_VERIFY with SAL_WARN_IF and add some unit tests to ensure
the replacements don't some side effects.

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

Change-Id: I661de626d21df3ad2ec962a37e4bb33d53a958bc
Reviewed-on: https://gerrit.libreoffice.org/71342
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

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

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

Change-Id: Ia28bf8fa53fa81c73a422c2af280e0418bd2aaf0
Reviewed-on: https://gerrit.libreoffice.org/71341
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

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

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

Now that the btlr writing mode works reasonably well in table cells, the
next context is shape text. But turns out that DOCX shape text lacked
support in the easier tbrl case, so add that first.

Also remove the char-level text rotation code in oox, that is
effectively dead code since we import drawingML shapes as shape +
Writer TextBox.

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

so if that's active fallback to creating a vector of simple pams

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

Re-scale the primary Y axis if the secondary axis
is deleted and the dataseries still attached to the
secondary axis.

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

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

to support the registered databases (containing ODS, XLSX
sheet or ODT text table data sources).

Now database fields don't lose their database connection,
and File->Print can merge mails after DOCX export/import, if
the LO instance has got a registered database with the same
name and table, as in saved in w:settings/w:mailMerge/w:query
element of the DOCX document in the form of

SELECT * FROM [databaseName].dbo.[tableName]$

query.

Notes:

– This fix supports only single table usage.

– The exported DOCX document is editable in MSO, too,
  without losing the database connection in LO later.

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

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

The Bundle_Contents_Resources_Lang dir gids (its only use) have been unused
since f0b57c30 "Info.plist et al were no longer
found when creating a .dmg", and those Contents/Resources/*.lproj dirs are
created on demand now, anyway.

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

...since dfc4ace4 "fdo#62442: Move the
InfoPlist.strings files into the app from langpacks"

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

Change-Id: I155673b9b1b2ba1f275877ce7885cf3f99fcb2e3
Reviewed-on: https://gerrit.libreoffice.org/71340Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Enable test sc.ScCellRangeObj::com::sun::star::chart::XChartData
as of commit eb7a731b the test is ported
to C++ and discussed with sberg in
https://bugs.documentfoundation.org/show_bug.cgi?id=43309#c7.

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

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

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

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

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

Change-Id: I7fcefd5b2da2055f56cf574358a96d2a071c13b6

as noted here:
https://mail.gnome.org/archives/desktop-devel-list/2019-April/msg00016.html

wrt:
https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33

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

Only clarifications on 0x001A and 0x002E, plus two new reserved
0xEEEE and 0xF2EE.

Note that the whole bunch of 0x1000 "assignments" is not handled
and not listed here.

Change-Id: I3d3e86052c8d36a2ac49db9caa167957b5468ec3

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>