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

* Update helpcontent2 from branch 'master'
  - tdf#122548 copy bascode and pycode to clipboard
    
    This will allow easy testing of coding examples.
    
    Change-Id: I30fc53642b1579744591f2de0c84a615d1755352
    Reviewed-on: https://gerrit.libreoffice.org/71385
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

* Update helpcontent2 from branch 'master'
  - topic tag correction
    mispelled link
    
    Change-Id: I34ecbbfca31285efe9af3eaa9ab0d2c1ee7b7b64
    Reviewed-on: https://gerrit.libreoffice.org/71377
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

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

On macOS it is possible to copy from a PDF a subset of a document,
which will be transported as a new PDF document containing the
subset.
LibreOffice didn't support PDF as a valid clipboard format and
previously it also didn't support showing PDFs inside the document,
so in such cases it copy-pasted a low resolution bitmap. The result
wasn't good.

As we are now able to display PDF documents as Graphic in LO, we
can also support this use-case. This adds support for the PDF
documents as a clipboard format in general and to the macOS
backend. This commit only adds support for Writer.

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

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

The UI default is in the SwForm ctor, where the content type sets the
link start char style to STR_POOLCHR_TOXJUMP.

Have the same default in the UNO API in case the import filters don't
set it explicitly, since that breaks clickable hyperlinks on PDF export.

This also fixes the OSL_ENSURE() failure for missing character formats
in SwTextINetFormat::GetCharFormat().

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

As the Qt documentation for 'QFileDialog::supportedSchemes'
says, setting supported schemes to a non-empty list restricts
the available options:
"Setting this property allows to restrict the type of URLs
the user will be able to select. It is a way for the application
to declare the protocols it will support to fetch the file
content. An empty list means that no restriction is applied
(the default)."

The call to 'QFileDialog::setSupportedSchemes' was copied
over from the gtk3_kde5 VCL plugin in commit
6196b729, where it had been
added by commit f1b60bd6
"Support opening of (some) remote URLs through the KDE file
dialog".

Since only either all schemes (if nothing explicitly set)
or a whitelist of supported locations seems to
be possible (s.a. the Phabricator changes referenced
in the commit message of commit
f1b60bd6), add the
"" scheme that makes removable devices shown -- while
there doesn't seem to be an official documentation on
the available schemes, at least not in
KFileWidget's API documentation [1].

A quick test with all new available options after removing
the call to 'QFileDialog::setSupportedSchemes' altogether
indicated that opening and saving files there doesn't work
reliably in all cases, so rather excplicitly add the ""
scheme rather than claiming support for all schemes
(including e.g. "timeline", "search", "remote", "trash").

[1] https://api.kde.org/frameworks/kio/html/classKFileWidget.html

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

Reverts the "fix" for i#42807 from CWS swqcore08 since there's
now SwUndoUpdateIndex.

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

* SwTOXBaseSection::Update(): refactor this to *first* collect the info
  from the document (creating CrossRefHeadingBookmark as a side effect)
  and *then* do the node deletion/insertion of the ToX itself

* add new SwUndoUpdateIndex class for the update itself; it does 3 of
  the 4 required steps, the last one is done by a SwUndoDelSection that
  is already created when the original title section is deleted

* SwUndoInsSection::RedoImpl() for a ToX should not Update the ToX
  because that's the job of SwUndoUpdateIndex

* SwUndoSaveSection::RestoreSection()/MoveFromUndoNds() need to create
  frames for the moved nodes; not sure why other users of
  RestoreSection() don't do this currently so add a flag

* SwUndoSaveContent::MoveToUndoNds() should *always* delete frames;
  seriously, why would leaving frames alive ever be a good idea?

* SwUndoSaveSection::SaveSection() should not delete the surrounding
  section node of the ToX, so add a flag to prevent it

This fixes tdf#123313, the SwUndoInsBookmark are now appended at the
right time.

This should fix the crash in i#42807 properly.

In order to fix these bugs, implementing the feature requested in
tdf#38703 was necessary.

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

Revert "tdf#123313 sw: workaround Undo problem with ToX Update"

This reverts commit 60ea01af - it was
quite simply a bad idea, and only pushed due to lack of time...

Much better to refactor things so that any new CrossRefHeadingBookmark
are inserted (with SwUndoInsBoomark) *before* nodes are inserted into
the ToX.

However! This patch does not fix the problem yet; that needs some more
significant changes.

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

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

* Update helpcontent2 from branch 'master'
  - added hasUnoInterfaces()
    
    Change-Id: I41e521c34c4dbf161b0bd4316da75d6db7ec4314
    Reviewed-on: https://gerrit.libreoffice.org/71214
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

Change-Id: I1893d52df505bc43428c37a624ca05c569ba1bc0
Reviewed-on: https://gerrit.libreoffice.org/70958
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>

Error code is captured and made available from outside
the access2base library

Reduce the number of items we set items/itemsets on the caption, which
reduces the number of times editeng does text layout.

Takes time from 151s to 78s

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

Reducing the number of times the editeng needs to reformat text takes
saving from from 278s to 151s

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

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>