Change-Id: I714c2fd747eae2e706355b4fae892af9f569b3ae

Change-Id: Ib5637a3601fc77588b2bd581f17dc6bcb36290db

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

Change-Id: I1aa1152940697f6390155871c0128519211abddd

Change-Id: Id0967358956868538f7563c51f7ed5e106771302
Reviewed-on: https://gerrit.libreoffice.org/3639Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

See developer mailing list for discussion, subject "LibreOffice is one or
several applications?"

Change-Id: I7a4a5a76f980eb458a2b6d4558a553b8508fd990
Reviewed-on: https://gerrit.libreoffice.org/3638Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Thus making the gtk+ backend more similar to the generic backend
in this regard; also be more strict about invalid monitors -> empty
screens.

Change-Id: Ia4f2e1205cb1d309fb1bb01f9631167339a3478e

Change-Id: I47ef674ec056d9a66c905420bf74b3e8a67840a9

Change-Id: I57d4768a26476d1a0535087c60535393b7004b24

Change-Id: I1457f5619984671e8cb88173d204d3157d3cb883
Reviewed-on: https://gerrit.libreoffice.org/3688Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Change-Id: I5da53ff44fdf00ec6c0fdf1a722f806971b6683a

I simply didn't have the krb5-devel package installed, and assumed there was
something more complicated going on.

This reverts commit 0e1cc996.

Conflicts:
	distro-configs/LibreOfficeWin64.conf

Change-Id: Ie3b226678862ed6388bcf1bf105da0b996f653d1

This adds a dropdown to the 'Open' toolbar tool.

Change-Id: I5b4aa99476e721c1479152b46bbc79cc0b095318

Change-Id: I44f032a6b943ad02b0d43e78b4e79275d6d2adfb

Change-Id: I03655bb502d6480d8f7f3f1adef17d8f635b8ed9

This touches up lightly on e986d3e3

Change-Id: If4d940433b27abec63a85c5975f5e9ebf672b79a

OLDPRODUCT2 - it was a workaround for OOo 1.9, obsolete
SAMEPRODUCTS - same product have the same ProductCode, so installer detect it
anyway under normal circumstances. It is possible that a tester/developer tries
to install the same version with different ProductCode over an existing installation
(e.g. dailyes or RCs). Then we are in trouble. However, SAMEPRODUCTS was not in use.
Moreover, Windows Installer uses only the first three fields of the product version.
So we cannot make difference between e.g. 4.0.3.1 and 4.0.3.2, and this is the new versioning
scheme.
BETAPRODUCTS - LibreOffice have never used different upgrade code (BETAUPGRADECODE) for betas.
OLDPRODUCTSPATCH, SAMEPRODUCTSPATCH, NEWPRODUCTSPATCH - related to old Star Division patching
mechanism, they were commented out anyway.
STUBPRODUCTS, STUBUPGRADECODE - these look useless

Change-Id: I77d67b72e18fa6b3ba4182b99e198c42f247cea4

Or, as it might happen, not... If there are differing opinions, please revert
and/or amend. Or start a discussion on the development list.

Change-Id: Ide5060802fda2d59a1c098d1ba8398fc095007c8

Also, don't claim TDF would be doing 64-bit Windows builds.

Change-Id: I3abdb13cf7b29c6d249d49fd6f66ce1b9993d97e

Try to make it more likely that a build without any autogen.sh options
succeeds. We didn't even get past the autogen.sh phase on openSUSE 12.3 thanks
to some krb5 stuff needed by the postgresql-sdbc checks.

To compensate, add --enable-postgresql-sdbc to those distro-configs/*.conf
files that didn't already have --disable-postgresql-sdbc.

Change-Id: I967616993875b99d9d5a9fd0721f281bb1161a87

commit f837c428 moved the handling of
w10:wrap tag in oox, but thus no wrapping was imported any more.

The fix consists in letting the w10:wrap element be handled by writerfilter's
dmapper if the shape has already been retrieved from oox (which is the
case for textboxes). In other cases, make sure that we don't set the
Surround property once again in writerfilter as that would override what
has been done in oox.

(cherry picked from commit 51d5e90b)

Conflicts:
	oox/inc/oox/vml/vmlshape.hxx
	sw/qa/extras/ooxmlimport/ooxmlimport.cxx

Change-Id: I8ab158641afcf6b9945c52238e7f5adb9e8b3adf

Change-Id: Ia09e30958392b660f694e8eefb6605108b3c0b57

Change-Id: I11a2a7e8e1f3f089c3b475df1147cefafecdb376

Some of these were doing nothing useful at all. I removed those.
A couple were protecting static data, and I fixed those to use Mutex
and MutexGuard properly.

Change-Id: I444d13f8b6c50e526cce8d69d09aeaf240e5c6ca
Reviewed-on: https://gerrit.libreoffice.org/3678Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: Ic8af47b52b06ef440b3fdaa966075780fb7a609b

Change-Id: I27df97ab6e35b03dfe70c7a979dd06f977086069

Seems this had bitrotted quite a lot. Calling it now like a cppunit
test works again.

Change-Id: I27479c3c3e1c1fe0639629e9bf8844456e0b0515

Change-Id: Ifd51f0c25418085ba8a6e8d331ac5c6d8139d18a

Yes, a simple test would have answered the question in the comment and
made clear that nanoseconds are not accepted by MSO.

Let's go with normal seconds as MSO does. It seems it also accepts
1/100s but who really needs that for a file timestamp.

Change-Id: Iaec6f9c08dc94d5086b83cb4bf520d0053b71b28

Change-Id: I6c70c000f60e7e6e43bd068ccb98b693b80746f2

Change-Id: I78e778408abb72772771daf5776a26f08c313ee2

Seems poppler changed outputdev virt func signatures with version
12, so with system poppler, we never got any image import functions
called. Added override annotation to prevent this from happening in
the future.

Change-Id: I565de80ce218e831e276d3a1d88ded3baee876e7

We shouldn't be trying to free the font table buffer when destroying the
blob, so pass NULL for destroy function instead of free(), and also use
HB_MEMORY_MODE_READONLY just to be safe.

Change-Id: I85b5a575249b4efc0f5799db205ee17cbeb66d22

Change-Id: Id7cb705b2b719cdd3bf16b8aba858c0319686599

Change-Id: I7a6ee4dce338b7529fa7500bb0c8341a4f2ebc22

Change-Id: I25794499711845cb8183664d1345e5513587d81c
Reviewed-on: https://gerrit.libreoffice.org/3679Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: I6ddeff7ae72693fd0951d71bd7b5444938bc7286

Change-Id: Iaec745dc1c8eb0614cc2fe1d70a94a00d18cc934

Add "$COMMONPROGRAMFILES\Merge Modules" (on current versions of Windows
that probably is "C:\Program Files (x86)\Common Files\Merge Modules") as
fallback, since for example on Windows Server 2012, the registry entry
has not been created when installing Visual Studio Express

Change-Id: I16f58b8a1d453c8628c6eb66c2cea37ab3da913a
Reviewed-on: https://gerrit.libreoffice.org/3680Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>