(And not $(LIBO_BIN_FOLDER)/opengl. Note that on Linux and Windows,
LIBO_ETC_FOLDER and LIBO_BIN_FOLDER are the same, "program".)

That's where getShaderFolder() in vcl/source/opengl/OpenGLHelper.cxx
looks for them. Also, as they are data and not executable code, to
conform to strict OS X code signing and sandboxing requirements, they
definitely should not be in $(LIBO_BIN_FOLDER)

Change-Id: I902e08f7a1f142697df827d50e0bda74be918eb4

Change-Id: I09749037deb44c0cd74b28af226dd4b3e34ee0d1

Change-Id: I0cf7586a154ca73ce64a2328ff8df1858e2290ac

Redlines changing formatting of runs and paragraphs are valid for the entire
run/paragraph, not just their existence in the XML. So store them
in the matching contexts, which will care of it, instead of the endtrackchange
stuff.

Change-Id: Ie583e4be14e8df95829852bfbbbe25aa0684f02e

Change-Id: I5ae5ce80fdb453fdf5de54c691de4cd0b88ad7f6

propagateCharacterPropertiesAsSet sends the properties only when ending
a text run (or maybe starting another one, I'm not quite sure), so it breaks
ordering by sending them later then expected (although it worked in many cases).
It's a question if propagateCharacterPropertiesAsSet is to be used by anything
actually, since it seems rather broken to use it in the ooxml frontend.
Using sendPropertiesWithId sends the properties properly at the right time,
as one would expect. I don't know why dmapper can't simply handle this on its
own, as I think it does handle entering and leaving other elements, but
spending more time on it with this overdesigned abomination, oh well.

Change-Id: Ie36c5f933ea3e6d789ea8f9e4ee3b60a5d1c920c

Change-Id: I997dfa3b1fe651db56ad2a6a24ec0cb6d5044550

Reviewed on:
	https://gerrit.libreoffice.org/11773

Change-Id: I5dc63abea660f097a63f7e61fc2b3b4cd48fa949

Change-Id: I86fe850b4b7bc8fc4c44717ca813772114ca70ff

Change-Id: I449b85b00aeaf690644e17be0a6b2b9398a3cd3f

Change-Id: I214884e9ee1d49dcc4db71f8744513468b912691

Change-Id: I68e8e6a564356bae620647b385e16279ff212d32

Change-Id: I203511fcb1e740d7d371821d49a7c13a72e6fc3b

Change-Id: I34a7b79b4a7b5d86c3d39fd995ed3bd998eeeab8

Change-Id: I82113fcd4182f9557ba0e7258498b5d4e798bf03

Change-Id: I19f98152b5bd8c9b2cdfacb560d13fc0c1f8c4be

Change-Id: I591188e0323bb75c55cad9a078eea188f79b3a03

Change-Id: I89f0cfc9049503318955d58dde3f9a3e1197c45d

Change-Id: I0cffc9df6d971393ae874060a8c306e12966370c

Change-Id: I30b61fa17a941b785a4f148e2ce6c912dbd3c645

Change-Id: I662c89e6e3e0917b51e8084bc50a9ea38d6c0838

Change-Id: I809e771e4f052ad64300b09174a1bdbc769e15d3

Change-Id: I7031e7408f5bcd9ae85fc50952253e14d2fb2edf

I don't think this actually matters

Change-Id: Ia7190f436eeb47888b1aace1391cf0b5aef9f9f0

The inner loop which iterates over the characters of
m_pTxtNode->GetTxt() is already bounded to the length of the
string, so there's no need to pay the price of checking its length
for each array position

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

(Spotted while valgrinding an unrelated issue)

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

Change-Id: I3a9e01237d8cade5d99955f02c01c25618ccd9de

Change-Id: I3ac385b8f21409b5083b1224652283fec8bb2fa4

The same pattern as introduced elsewhere recently.

Change-Id: Ie7b4fd1ec26d417f63bee26dd336dfc54f4847dc

Change-Id: I74a61005fa9534b3f96cd392c6e38c54c5fd35e1

to make it's intended purpose clearly distinguishable from AddNextRef

Change-Id: I5da780b48b19fd873667b648031bc394113f953b
Reviewed-on: https://gerrit.libreoffice.org/11763Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I26a1164d44f464a44ed7deb93ac39465feb0541c
Reviewed-on: https://gerrit.libreoffice.org/11768Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

The entire button appears on mouse over.

Change-Id: I27e713f75a30ec4a2b271d813fcbcbe8c91a4180

Change-Id: Ia406baec2867605bf515dac0ba090500e2bbd1ce

Change-Id: I545328a1c126b3bfeee8c1f662c5eb9a471d33ca

You used to have to convert formula cells to static values by copying
them and pasting them as values onto the original place.  Why not just
allow converting them in place?

This is something I've always wanted to implement.

Change-Id: Ie1c80029a762fcf92dc20ffe74260ea54c61da28

Change-Id: I385e756109ab0a47feeeb4407ba4a2a4b68548dd
Reviewed-on: https://gerrit.libreoffice.org/11728Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>

Change-Id: Ie154bfb15a19ae98b2bc4eb6626240a00cf182d4

Change-Id: Ia6186be4ed48fd75d1063eed233a88e09b675bf1
Reviewed-on: https://gerrit.libreoffice.org/11774Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>