Treat all of QT5_CFLAGS, QT5_GLIB_CFLAGS and KF5_CFLAGS as
C++ flags, since those contain C++ flags in the first place.
Therefore, set them using 'gb_Library_add_cxxflags',
not 'gb_Library_add_defs'.
(Strictly speaking, those variables contain includes as well,
but handling that properly would require splitting this
up further, either in 'configure.ac' or see e.g. how it's done
in 'RepositoryExternal.mk'.)

This also prevents the values of those variables from ending
up in the wrong section in IDE integration generated by
gbuild-to-ide.

Handling them as includes previously resulted e.g. in 'vcl/vcl.pro'
(generated by 'make qtcreator-ide-integration') containing

    DEFINES += BOOST_ALL_NO_LIB \
    ... \
    VCLPLUG_GTK3_KDE5_IMPLEMENTATION  -isystem /usr/include//KF5 -isystem /usr/include//KF5/KCoreAddons [...]

and Qt Creator would show a (rather unhelpful) warning like the
following when opening a header file inside 'vcl/inc/':

> Warning: The code model could not parse an included file,
> which might lead to incorrect code completion and highlighting,
> for, example.
>
> 4:9: error: macro name must be an identifier

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

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>

This is a hybrid plugin which mostly wraps the GTK3 vclplug. Only
the file and folder picker are replaced by KDE dialogs. This gives
us a well-maintained GTK LO base with basic KDE integration with
minimum effort.

To prevent issues with nested event loops, the KDE dialogs are
launched from a separate process, the new lo_kde5filepicker helper
executable. A trivial stdin/stdout IPC mechanism transfers the data
between LO and the Qt/KDE helper. The usage of an external process
also allows us to copy'n'paste between LO and the KDE file dialog
without freezing the UI, as would happen when one would do this
in-process. This is in general also the architecture applied by the
kmozillahelper, which is used to integrate KDE file dialogs into
Firefox.

While the KDE dialog is shown, the GTK3 main window is disabled and
close requests are ignored. The KDE dialog in turn also sets the LO
window as transient parent. Together, this makes the illusion perfect
and the KDE dialog behaves like a modal dialog. This works properly
also with multiple LO main windows, and only individual windows will
get blocked as one would expect.

Functionality wise, most of the features of the KDE4 dialog are
supported. You can pick files and folders, and save files under a new
name. Some custom checkbox widgets are supported, but lists, buttons
and preview widgets are not yet implemented. Also, loading remote
files via KIO is not possible yet.

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