For example, we don't build the vclmain library for non-DESKTOP.

Change-Id: I01a1bcd6387e86c60e5543fcb8009fd1df914a20

Change-Id: Ifa725c40c5756ba7999423a782180c1ac3901d30

Change-Id: Iea825271825119bddfdaa79af3b111659f084d0b

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

just hit this with the same all-modal hammer we now use in the extension manager,
a modeless dialog, with modal subdialogs run by a normal non-async subloop, turns
into a modal dialog for all other toplevels

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

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

Since SvxShape::GetBitmap is UNO API implementation
the results have to be in 100th_mm, that is how UNO
API is defined.
Adapted Bitmap creation common case to do so using
primitve embedding if source is not 100_th_mm.
Also added a shortcut if object in question already
is a SdrGrafObj and contains a Bitmap.
Needed to update the checksum of a graphic for
testN777345.

Change-Id: I995100406a262e2872597dc64e943271e92eb4cb
Reviewed-on: https://gerrit.libreoffice.org/65505
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>

MS PowerPoint template format now supported not only for import,
but for export too.

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

Change-Id: I504f30190bc1ea00eb1ea7a84c9638e73931dc95

Change-Id: Ie1fcda19141a12dfe2b965d88e16c85cc2a64cb2

instead of std::vector.

Change-Id: I5927e061b5d2944cad68b96e313934738c63c321
Reviewed-on: https://gerrit.libreoffice.org/65400
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>

Change-Id: I5a9f99b7530ed54011c1a4a677f3c6bb46914abb
Reviewed-on: https://gerrit.libreoffice.org/65498
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

We need to do rView->GrabFocus() , before calling any other function.

Change-Id: I95a64f44c40070caa0064c3e73fb5d7b04b3bf4b
Reviewed-on: https://gerrit.libreoffice.org/65437
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

* Update helpcontent2 from branch 'master'
  - Fix menu paths Help pages after translators review
    
    Change-Id: I4afa7097d47b186c0f9732f68abadcbd73633042
    Reviewed-on: https://gerrit.libreoffice.org/65487
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

* Update helpcontent2 from branch 'master'
  - 2 typos corrected
    
    Change-Id: Ic3e2524861d91480da0cdb53400f22ca46d10e45
    Reviewed-on: https://gerrit.libreoffice.org/65499
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

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

The anchor position of a fly frame can be on an empty node after the
last non-deleted text, and SwAnchoredObject::CheckCharRect()
needs to get a valid frame index for that.

This can be reproduced with ooo69593-1.odt.

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

Change-Id: Ieb3b1846a5a31915297cdc80053dba3d1656aba2
Reviewed-on: https://gerrit.libreoffice.org/65365
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

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

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

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

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

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

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

To not increase the size of the main org.libreoffice.LibreOffice app further,
the plan was to realize this as an org.libreoffice.LibreOffice.Help extension.
Ideally, this would be a localized extension, so that, by default, only a
relevant subset of the extension would be downloaded and installed.  (But see
below.)

There are multiple technical problems, as discussed at <https://github.com/
flathub/org.libreoffice.LibreOffice/issues/35#issuecomment-447295308> "Add
integrated LibreOffice Help offline":

* LO can't pass a file URL with query part to xdg-open, so uses a temporary
  wrapper .html file that redirects to the target URL.  But for the flatpak case
  this wrapper can't be in /tmp (which isn't visible from outside the flatpak
  sandbox), but is instead stored in a new temp dir under $XDG_CACHE_HOME (which
  is always set for flatpaks and /is/ visible form the outside) that is
  removed on LO exit.

* The file URL stored in the temp file must be rewritten from the internal path
  (/app/libreoffice/help/...) to the path as seen outside the flatpak sandbox.
  While the path for the org.libreoffice.LibreOffice /app is stored in
  /.flatpak-info, the external path for the org.libreoffice.LibreOffice.Help
  extension is different and not stored there.  So use a hack trying to
  construct that path from what information is available in /.flatpak-info.

* But the help content consists of locale-specific and shared files, and those
  reference each other with relative links.  But a localized flatpak extension
  cannot contain shared files, it can only contain per-language sub-dirs.  And
  if the shared help files were kept out of the extension, as part of the app
  itself, the relative paths among these files inside the flatpak sandbox would
  differ from those outside of it, so would be broken when viewing the content
  in the external browser.  A solution would either (a) need to somehow rewrite
  the content of all the help files being served from LO to the external
  browser, or (b) replicate the shared help files in all the extension's per-
  language sub-dirs (and if some localization uses en-US content as a fallback
  for only part of its translated content, e.g., in the case of media files,
  would need to also replicate that en-US content), or (c) use a non-localized
  extension that always contains the content for all localizations.

For now, I chose the third approach.  This makes the
org.libreoffice.LibreOffice.Help extension relatively large (the current
/app/libreoffice/help tree has a size of ca. 100MB), so that I decided to not
have it downloaded and installed automatically ("no-autodownload": true in
solenv/flatpak-manifest.in).  (I checked with Flatpak 1.0.6 that if the
extension should be changed to a localized one with the same name in the future,
updating from an older version would work.  If the old extension was not
installed, just the relevant localizations of the new version will be downloaded
and installed.  If the old extension was installed, the full set of
localizations of the new version will be downloaded and installed.)

(As also mentioned at <https://github.com/flathub/org.libreoffice.LibreOffice/
issues/35#issuecomment-447295308>:  "A second, minor, nuisance is that, for
security reasons, an `xdg-open file:///...html` call from a flatpak leads to an
intermediate popup dialog letting the user chose which application to use to
open the URI, while e.g. an `xdg-open http:///...html` is allowed to go directly
to the user's preferred browser.  So accessing help content from LO flatpak
would present that popup dialog first, forcing the user to select a browser to
proceed.")

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

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

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

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

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

Commit f3ce30ec changed this to return
after first non-throwing XNameContainer::hasByName, regardless if it
returned true or false.

This changes it back, to iterate over all the providers again.

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

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

It passed "make check" on Linux

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

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

It passed "make check" on Linux

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

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

Use range-based loop or replace with STL functions

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

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

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

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

* Update helpcontent2 from branch 'master'
  - Dissolve contraction, don't -> do not
    
    This was already fixed for 6-2 with commit
    d08d1c486558d6c113863d579f89e1faf8d89572
    
    Change-Id: I00e67478ae41cd5724d2df8abe105faef4343c21
    

OLE objects by exporting their VisibleArea settings

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