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>

* Update helpcontent2 from branch 'master'
  - Fix code formatting in validity help pages
    
    Change-Id: I9b0558bb805512c98223eaf2305d37861e10c82c
    Reviewed-on: https://gerrit.libreoffice.org/65458
    Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
    

seems menubar gets set to dirty due to some menu activity that needs
a refresh, but then the hierarchy changes and as its already dirty
the maUpdateMenuBarIdle doesn't get launched

the placement of the mbMenuBar test inside the loop through parents
shows some confusion as to what which mbMenuBar might be met, the
one belonging to this, or that of the parent being traversed, but
it does seem to be the one belonging to this.

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

The user-visible problem was that embedded (OLE) objects contained in a
document that was loaded on a thread were not editable.

This works in the loaded-with-UI case because the Windows version of the
SalData constructor in vcl calls CoInitialize() (which sets the
concurrency model of the main thread to STA) and then later the
OleComponent constructor in embeddedobj calls OleInitialize(), which
just realizes that the concurrency model is already set, and OLE editing
works.

However, if the document is loaded on a thread, things are different.
The concurrency model of the thread is set to MTA in
oslWorkerWrapperFunction() in sal, so the later OleInitialize() will
fail with RPC_E_CHANGED_MODE, as it's not possible to set the
concurrency model of a thread once it's set.

Solve the problem by providing in opt-in way to execute the actual
import on the main thread, since remote UNO clients always invoke
Desktop::loadComponentFromURL() on a thread.

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

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

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

Change-Id: I866611929f75dd322ce81ec54a63ec08002f55cc
Reviewed-on: https://gerrit.libreoffice.org/65401
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Move XTableRows Java tests to C++ for ScTableRowsObj.

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

* Update helpcontent2 from branch 'master'
  - http -> https
    
    Turns out the https://www.oasis-open.org/standards#opendocumentv1.2
    page has linked them badly with http ...
    
    Change-Id: I64d26f79f4503a6b795c4990cf92327d20fbb08a
    Reviewed-on: https://gerrit.libreoffice.org/65459Reviewed-by: Eike Rathke <erack@redhat.com>
    Tested-by: Jenkins
    

* Update helpcontent2 from branch 'master'
  - Point to the OASIS Standards page at #opendocumentv1.2
    
    Change-Id: Idb6c0839694337855b42b22d0ab1d98c8ae30892
    Reviewed-on: https://gerrit.libreoffice.org/65455Reviewed-by: Eike Rathke <erack@redhat.com>
    Tested-by: Jenkins
    

* Update helpcontent2 from branch 'master'
  - Point to the correct ODFF 1.2 specification download link
    
    The previously pointed to office-formula page is the collection of
    working drafts.
    
    Change-Id: Id8bc75e2192ce8da26ca1af1d8779560ace14b6b
    Reviewed-on: https://gerrit.libreoffice.org/65454Reviewed-by: Eike Rathke <erack@redhat.com>
    Tested-by: Jenkins
    

Change-Id: Id1ae1c7cd7beb88c0dcb9ec9c36fc3a06920def1

Change-Id: I628631f4bba4952bfa5f6e03e58cc4ab2c9c3c69

* Update translations from branch 'master'
  - update translations for 6.2.0 rc1
    
    and force-fix errors using pocheck
    
    Change-Id: Iccf11f743d0aa5c3f7fd2f0fcc12dfe105d1c071
    

Change-Id: Ia031c95c5a211f655c32afdd351afb182349e065

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

possibly(?) since...

commit d999b55e
Date:   Sun Dec 10 10:56:38 2017 +0530

    tdf#114200  : added 'Trim space' feature in 'Text Import'

    made a checkbox to Trim extra white spaces from both ends
    while using seperators in 'Text Imort'

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

* Update helpcontent2 from branch 'master'
  - superfluous character
    
    Change-Id: I2c7641a6c7431a3b82b449364519f4f34bf8a8c9
    Reviewed-on: https://gerrit.libreoffice.org/65446
    Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
    

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

The point node isn't necessarily the start node; this will assert in
SwTextFrame::MapModelToView: Assertion `SwFrame::GetDep() == pNode' failed
when selecting a table and then File->Print->Print Selection.

Thanks Samuel for the hint.

(regression from 067a53bb)

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