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>

(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>