...as a prerequisite for gbuild'ifying desktop/test/deployment/passive/, which
builds a test extension that does not match those default description/license
settings.

Change-Id: I200ff0ceb9750ed4b1c187305f10469f789d29cb

Patch By: Lei Debin
Found By: bjdujing@gmail.com
Extended for better Debug Info by: Herbert Duerr

Conflicts:
	filter/source/msfilter/msdffimp.cxx

Change-Id: Ibb2e7daae425a711b5b6cadfa81446e9adeb68f1

Change-Id: Ia05bc5b8d1f9396ed8c1d27d54976308e6df36f4

Change-Id: I492f93a9ef5244681a28aed16e81c7558e38a875
Reviewed-on: https://gerrit.libreoffice.org/2573Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

Change-Id: I889a32bce4f3c0eab5d3d5ef199dd321755cb177

Change-Id: I589ff778383f6e1a5fa910be687787658cb414a0

there seems to be some problem ( regression from 3.6 ? ) with dealing with
addresses returned from named ranges where the addressing mode of the named
range is different from the addressing mode of the document itself

Change-Id: Icfcd047819a4d1c89ae9509ea1a2e1b2d5386101

Note: some of the test documents have some tests disabled in order to run
without errors, these are identified by the following lines

Rem [#FIXME disabled 3.6 ] in the macro source.

note: some of these errors are expected and were always happening, some
errors e.g. those pastespecial specific ones in
qa/unit/data/xls/TestCalc_Rangetest2.xls
seem to be to do with problems with the test harness.

note: there are some others ( e.g. in Window.xls & windows2.xls ) that seem
to be related to hard sizes and screen resolution ( these should be adjusted
sensibly )

Change-Id: I07a43a2802d4e1794ac2f8c648f666b5bcd13a04

Change-Id: Ib2cbcc33e6188c60c183b5f47e9ae9c9d4c91b95

Change-Id: Ibac7f624f1a1dcce653dff4bec573be457d70075
Reviewed-on: https://gerrit.libreoffice.org/2125Reviewed-by: Muthu Subramanian K <muthusuba@gmail.com>
Tested-by: Muthu Subramanian K <muthusuba@gmail.com>

Change-Id: I74f1d7feb935be65629bdbd7464f9882229948e5

Don't know what this affects, though. Things seem to have worked as expected
even with the hardcoded bogus value?

Change-Id: I945bdcd53260fc5f43cf0031dfd96637168475f0

Change-Id: I815cc4a703b7ca6d2894807396a06a3394b40676

Change-Id: I9031ab98f263bcc32b747c85e1715b80c7059ae9

Change-Id: Iea153d6e1b648ac6a7bdf8978cfc1f8016158d6c

Change-Id: I4a0a6ab0998f41ce238d0570fba2133b79c8f19e

Now the type detection process is a lot more simpler.

Change-Id: I5a3a68afef8276a7f07be75c0b2db8151512b3fb

In theory we shouldn't have to do this any more now that we do test
against all possible format types in the first pass.  But let's test
if my theory is right...

Change-Id: I70d73a99aec56a66deaeb3f942fd2641a2cc7f48

Change-Id: I5a614ae032149b755d609ff05b9ef2fdb842dadf

I did my best to check each and every one of them and rank them to the
best of my ability.  Any mistakes are to be fixed as they are discovered.

Note that while working on this, I've noticed that we don't actually have
any real type detection codes for many of these format types, especially
the graphic file formats.  If we ever have trouble loading any file type,
check if it's caused by not having any detection code for it, and if so,
we should write one for that file type.  That said, my casual tests on
loading graphic files didn't cause any trouble.

Change-Id: I1398cbb72b2d4ccf75434a9aa0d2a5c5d17bdaad

Else it would incorrectly declare a non-zip archive format as a zip-based
format.

Change-Id: I017b63768dc89f7fe6e2202a661faf5f692b1a92

The old type detection would only test file format types that are
relevant to the current document service.  But this would not work
if the user tries to open an Excel document whose name ends with a
non-default extension (such as .tmp) from Writer UI.

To amend this, we need to test all possible format types that are
supported by all our modules regardless of the current module, but
prioritize them per current module.

TODO: The above scenario doesn't work yet.  I still need to fix
the individual type detection services to get it to work.

Change-Id: I51dbdff28299aa64cedc6752b9ff82b96d5d79cf

Change-Id: I5a059f7799255262d46e5248813da4409eb83a9a

Change-Id: If31092ecc2b746acbe5731bf9383560e93aa3a69

Change-Id: I1a591ec4061c73657c26552d41c58b970696038f

.. doesn't need to take comphelper::ComponentContext as a param
anymore, can now use Reference<XComponentContext>

Change-Id: Ie5fbe0c9e8459cc612426ffa9474f955b28593e3

Change-Id: I8d34bfca5009a4a44444b19a39c6f8338614e4c4

The services already existing, just needed to create the IDL files

Change-Id: Ifedd46722ba0bae2985e82d18827c61c1d12cd62

The service already existed, it just needed an IDL file.

Change-Id: I6b9a5a5fd02985bfdd29bb42f032265d0b5498c7

Change-Id: I2c9cdff2aeb97c8b9740aba91990e27315d5c85b

Change-Id: I4be6985d5f1c7729f74b8a5ddc41024a407e770c

No-one was calling the constructor with anything other than an
empty reference.

Change-Id: If1948ff236f6fdb3579e472d66c5f9c04879bc4e

Change-Id: I647a02e552acdd354463fc46c13c5a73b1c90d09

Change-Id: I62c37eb6d0e0b2a681a84e1fa0067d0a9f967cf2

Change-Id: I52eb4153c3396be88b72cab3b7899f0c6ab18103

Nah, seems that it was used after all on Windows, somehow.

This reverts commit 5754264f93001978a3c5f5f1cdabd7113de010b8.

In the damaged() method do a callback up to Java code in Desktop that
invalidates the view. For now store the view in a static field, but need to do
that in a cleaner way eventually. There might in some circumstancest be
several instances of the Desktop activity present. Obviously should also run
just one LO thread.

Get rid of the temporary self-invalidattion in onDraw() silliness.

Start the LO thread that runs soffice_main() from Java, not from native
code. Apparently only threads created from Java have proper class loaders in
Android.

No need for an own DoReleaseYield() in AndroidSalInstance, the one in the
SvpSalInstance base class does what needs to be done.

Change-Id: I4cb85b352fca1f1375f726620ec8c93d2047f113

Change-Id: I67d90eb58faa0427c4de894eac107cc2d05a3477

Change-Id: Ia4970bd63ae5a9af40a82c894ecd077b7ca199df

Upstream changes
https://ssl.icu-project.org/trac/changeset/32865
https://ssl.icu-project.org/trac/changeset/32908

See also
https://bugzilla.redhat.com/show_bug.cgi?id=918167

Plus changed UMutex to UMTX to make these compile in icu49.

Change-Id: Ib5dba7085e6b2dd3925c0c220b5d264e4c7bb4c8