Change-Id: I504cbe271ef4475963b8277a1ab7dcb09b0dda38

Change-Id: Idd21d7efa2708ab2486cdaf8bf5910af36551687

We need to default to the Aero colors too, in order to this be really
beautiful; but hopefully already in the current state it is an improvement :-)

Change-Id: I 113039b62320fa76916ba74071e1eebff4d3476c

Change-Id: I9a68d585217550c1d229a2bc66d04e506253d747

Change-Id: I71bf94a87f8d7092b472e7a8eb58045a82749c29

[We need to introduce taking colors from theme (instead of system) anyway.]

Change-Id: I75037771f2542e924cbff01accf66cfc851ec255

No idea why the DwmIsCompositionEnabled is recommended ~everywhere where you
search for how to check if the themes are enabled; it is wrong as eg. over
rdesktop, you are still using themes, but for sure not the composition in dwm.

Change-Id: I Ib34f2a17809d03f29ccdf7d4a8b94ee7ad996bf5

Change-Id: Id07fce1f1baf7361e16f16af63f54c98a71791f6

Change-Id: I6f468005c8d8d99d9251a9c4fe4629b98bc4aa5e

C:/lo/core/sw/inc\tblafmt.hxx(311) : error C2487:
'boost::ptr_container_detail::reversible_ptr_container<Config,CloneAllocator>::insert'
: member of dll interface class may not be declared with dll interface

Not really understanding what the problem is here, attempting to fix it
by not deriving SwTableAutoFmtTbl from the container, and trying to get
that to build somehow resulted in this commit.

In some circumstances installation of embedded VC++ runtime
fails with error code 1935. This usually occurs, when there are
many different versions of VC++ runtimes installed on the computer,
including beta versions. We can workaround this Microsoft bug, if we
don't install our VC++ runtime. A new property was introduced. It is
called VC_REDIST, and installation of VC++ runtime depends on its
value. (BTW the solution is general, ComponentCondition can be used
for any merge module, now we have only the VC++ runtime merge module.)
When the user experiences error code 1935, he should try to install
LibreOffice with the following command line:
msiexec /i <msi file name> VC_REDIST=0
The patch fixes another minor issue. 64-bit VC++ runtime will
not be installed on 32-bit systems any more.

Change-Id: I I6c5e066c6e60b011235e6019a8a35c9e953209bc

Apparently Apple GCC 4.0.1 wants to invoke a copy constructor for
SwAuthorityFieldType when it is given as parameter to InsertFldType,
which seems entirely spurious; let's try if this works around the issue.

Change-Id: I3f00ab7149d6d198292d63ed3f16b213b39a3054

Sorry to have to revert this, but it is too broken on Windows.
Even on linux it needed some work to get right. Just stick with
what was there while the author works on a better version.

This reverts commit 21155b87.

Change-Id: Iaa075c2bd4d2fccf4d58052888735bedc83605c7

Change-Id: Ibb86fb64dd8bee950b70890018cd15dffd7484b1

Also adapt dbgutil code for previous commit

I added a GetPos() method because quite a lot of code used that
method and the existing code is quite tied to the precise
return values of that method.

Change-Id: I9af6b923d978abe758b63d835f228495c020455a

::boost::ptr_vector::erase will delete the element, so p points to freed
memory after that line; try to get this to work via the transfer method.

Change-Id: I1c92f9d77723979a9d16e9114282dec8d3566de6

Change-Id: Ifd81de26432d2e7ceed1a643e3c2009e97f8a5b2

Change-Id: I722fda99e8c13785c37fe20a89c1e7b6620b884d

Change-Id: I7f0adc9e2e196652dd938c27630fb2e13f9900e3

Removed the copy constructor because it was dangerous,
it could result in accessing an SwTOXSortKey object after it was released.
Removed the operator= because it was private, and no longer used.

Change-Id: Ifaf21cbbad5f8b9cabddcc3009e4ed776b1fdd71

Change-Id: I10b6043bf43d0b65a982a8c4f0067ac726189c53

Replaced by XkbKeycodeToKeysym
(cf http://nabble.documentfoundation.org/PATCH-Proposed-patch-for-XKeycodeToKeysym-deprecated-td3978158.html)

Change-Id: Ide8331705369d0c38e72bfe693102625e62a87e1

Change-Id: Ifab63273b12963e748c9b937648b2079fcd0c796

...that would otherwise lead to "Bad insert element" failure during live-insertion.

Change-Id: I74f883c9b613f03256abb7be7657f25b418f821d

Method assumed that not much attribution happens below data and started from
the end of attribution, in the case of not much attribution it worked fine.
For the case of many differently formatted areas with a sufficiently large
area of visibly equal attribution near data end it was a bottle neck looping
over unnecessarily many comparisons. Start at data end instead. For the case
of not much attribution it doesn't really matter, and for the case of no
sufficiently large area below data end it doesn't matter at all and compares
the same number of entries. The drawback would be a large area near
attribution end with many small areas between data end and the large area.

Observed with test case of fdo#46160

Change-Id: If0b7234ede1d9f8c59e5df692b45539a508d8921

Or else crash would ensue...

Change-Id: I537523818eae3d558c300705baf7a5d9a8fa6dd9

Change-Id: I1267629da8b66fc21c4ae2e78634c2093274aa61

Change-Id: I3ac70ea343edde406e78845a112aabcbd8ff65b1

Change-Id: I03ab6367a40ddc5748a499c4e2c7f108a3ef8a08

Change-Id: Ia74a76659d97d10299d9ddfe8d2118d5c1c5725e

Change-Id: I73ab08289965a311e36ea5f0187d57f7662208ab

Change-Id: I I4fdd35b2d2c256f7d45022fb837178ace9d678d9

Change-Id: I Id7f647be04245496bb1970b1bcc621d97395c032

Change-Id: I5a097beaaeb30214ed6071bba1297e551291922b

Change-Id: I088e8fef273a42ad3e1d87d249a998867c22b4c6