now that Caolon has fixed the bugs in the auto-correct

Change-Id: I06c31c22974fd23c6e6c14f1b3d0b6411712753f

Change-Id: Ia0cb9fe1eaebdd295fb1742074fe2c48be61c077

I seemed to have missed this in my earlier conversion process.

Change-Id: I9266fac26425d552520ce68bdcce9b8f4cdbe9a6

Change-Id: I593c6c3236172f33b3e58fb44a41e079c3c8b0c4

If anything during binary import fails fall back to compiling from
source. That includes a failure during building the binary file.

Change-Id: I0f021f17c9be061fc9eb9f28ab470257d61f03cb

Change-Id: Id6055194eb225b85a5c66c5cf9fb44ad342df1a7

Change-Id: Id34e7c6dad0587e2a8ea583c6df9bdc145f193bc

Change-Id: I8f195cf6f8f6962d73171fec65b46fbd96f74613

Change-Id: I67bc06f80c284c85d2bb409380ba3a43611ec31c

Change-Id: Ic38f5421da373a68eeee8fe7863450dd5025e312

rLibName -> uri must be an (absolute file) URI, rPath must be empty, and xKey
must be null in loadSharedLibComponentFactory.  While incompatible in theory,
these functions should only be called internally, anyway.

Change-Id: Iab144b199e4e7db62358283efec6877a5da19bab

...that had effectively been in uno.exe since
c460c0cc "initial import," for whatever reason
it was supposed to be good for, but would no longer work anyway at least since
644c33a8 "fdo#67313: Use "lo" suffix for private
URE libs."

Change-Id: I98c038a4d9d963eefc542c91247cf263d7d988bb

Change-Id: I929da9300cc02da114907841ad8805d1227f3f79

...that has neither been intended for external use anyway, nor has it ever been
used internally since its dead-on-arrival inception in
b16ab7a7 "Add invokeStaticComponentFactory() for
statically linked components: Will be used for iOS at least."  Sigh.

Change-Id: I17795b2a1945809688deba0a5492415fbe877400

Change-Id: I30dde10d1c299dbd9c0b2cb2fa025ce432df6cce

Change-Id: Ia5bc8b0dec8cecdec06a71377ac5cd3a52109955

...introduced in 2000 with 38974aee "added
library loading limitation by using env variable CPLD_ACCESSPATH=path1;path2;
etc." and 9be3c618 "#80090# restrict jar file
access to java system property com.sun.star.comp.loader.CPLD_ACCESSPATH" but
already in 2004 considered "a hack [that] seems to be unused nowadays" in
1d3164df "CWS sb20: #i29119# Replaced
sandbox.jar-based class loader with an own one."

Change-Id: I637afd5daeb4ca097edd17f834c81af892dcfc6a

Change-Id: I185befe8aebdc13df601b1151b45c62e7291b5c0

Change-Id: I88a871374ecc8d9d59f9b33b5198c0e6c9a2458d

Change-Id: I633d73ac04ad97bb71e62a93e7d804cd253b2a31

Change-Id: I60bbf6c309130bbf868745b3ba6fc1c0729d850a

Change-Id: I93200c35bf33da16efc6f0dc5dfe2c79d8752250
Reviewed-on: https://gerrit.libreoffice.org/6095Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
Tested-by: Matteo Casalin <matteo.casalin@yahoo.com>

Change-Id: Ia5acd5b6be61364aab2e799088bd2592bd2b4b62

Change-Id: I824e83271997888712f126f4197252d7beefccc1

Currently, the default color shown in Sidebar>Line>Color
is yellow and is not updated until and unless one hovers a
mouse on top of it. This is wrong and the default color of
the line-color should be updated and shown by default.

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

Currently, when the sidebar is taken from right side of
the screen to left side of the screen, the vertical tab
-bar is still attached towards the right side of deck.
Ideally, when the sidebar is attched towards the left
side of the screen, the tab-bar should automatically set
towards the left side of deck.

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

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

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

Change-Id: I8ab1842ef1eb6f2988a547f0837daa81bbaff595

I.e., GNU libstdc++, LLVM libc++, or Microsoft. Also, do the grepping
for "visibility push" only in the libstdc++ case.

Change-Id: Ibf1038e37780774d9595eccfe47894dd88fc5591

Hopefully helps a Gentoo tinderbox.

Change-Id: I2e83b867113ba04a708c9fbb46c728368c4328c0

This reverts commit d4a41ab3.

This test failed once on one windows TB, but seems to run on my
local machine. Reenabling to verify whether all TBs fail or if
this is limited to one machine.

Change-Id: I40c121833eaef091aaa9cc4a80fefb88fde2cc5f

Also move osl/util.c on Unix systems to osl/system.c.

Change-Id: Ifff79d9f4f89ecbb4e0e1652b40ab46b7d569adf
Reviewed-on: https://gerrit.libreoffice.org/6065Tested-by: Arnaud Versini <arnaud.versini@libreoffice.org>
Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>

- method <SwTxtAttr::RstAttr(..)> - correct consideration of parameter
<bInclRefToxMark> used by Undo to fix 121897

(cherry picked from commit 685921ea)

Conflicts:
	sw/source/core/txtnode/txtedt.cxx
	sw/source/core/undo/untblk.cxx

Change-Id: I8c66d535b5d6d51443876f1789e379bcceabfec7

It is a (file:) URL anyway, and LO seems to take care of creating the
directory as neded.

Change-Id: I19dd7b67cfe2f77cea14e882c1142fadde2fbdaa

so that any window derived class, and not just dialogs, can trigger layouting
of their children. Merge together the handful of hacked-up impls of this.

Do that then for the sidebar PanelLayout so that when the label of the custom
animation frame changes that the frame allocates enough space for the new label
to display fully

Change-Id: I9a95f6c3f60cd6cea47656e66cb9ffcc154a3a5a

Change-Id: I97ef9ba6a3082403a76612cf99e46a0d19c9643e

To be used in regression testing and similar scenarios, where the output ODF
is *not* intended to be further manipulated in LibreOffice. An environment
variable LIBO_ONEWAY_STABLE_ODF_EXPORT is used to toggle this behaviour. I am
not 100% sure whether the generated ODF with the hack toggled on is even fully
correct, but correctness is not the purpose of the hack anyway.

Two classes of issues handled: 1) Automatic style names and 2) use of
randomness.

For class 1), when the hack toggle is in effect, we generate the names at
first as strings based on all the properties of the style, and sort them based
on those, and then rename them (for brevity in the output) to the "normal"
form of a short prefix plus a number (like "P12").

Sure, it would have been better to just figure out *why* the automatic style
naming currently is not stable in the first place, but outputs the styles in
different order (with some styles being assigned different numbers) in
separate invokations of LibreOffice), but I was unable to understand that.

Possibly this code could be used in all cases, except that it does break some
unit test (can't recall which right now). I don't know whether that is simply
because the unit test assumes too much knowledge of the internal workings of
the automatic style name generation, or whether the generated ODF is actually
invalid.

For 2), I found a handful of places where randomness was used to generated
various kinds of identifiers in ODF output. I changed those to just use large
(64-bit) non-overlapping integers instead. I assume there *is* a point in the
original code in each case that explains why randomness is needed, so the hack
definitely needs to be optional and used only for the above mentioned
scenarios.

Change-Id: I17b657197e38bcf24abdfe61ad4a277f4339eeae