Change-Id: I83af7c87576c185b4884a2a6ceaea5274efa7c37

Change-Id: I80c119b2287ff0c4f2e467943be6a7682914934a

Change-Id: Ic2cbd96f393a21cf2c6634d3c5e5a4c5a5b486ef

Change-Id: I697aad17986b1cd874311716873ed75358d3cae4

Change-Id: I807d88631cf35e51cd034a62eed1d4230c75d1be

Project: help  866c0eca7cda0f8f3939076e11820ebdaf4870c3

Change-Id: I5520eed20357d493ef198a935486f45dd7181e0a
Reviewed-on: https://gerrit.libreoffice.org/2926Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

to have the complete set. Reported as paper cut on Impress Sprint

Change-Id: I9cc5145976c5b04d2df634106be6ef5eebb5ef56

Change-Id: Ic7b262f4b75e7f2069f88f753cea5ff8f59610b7

Project: help  31516bbabeb16119424c371fb17975a58b74d108

SCNR

Change-Id: I3aaa8d9b37423d44fe11f161cc21c0a77b466353

... because when it is installed, it hides the original template based
reporting UI, which is preferred by some users.

Change-Id: Id758b664d6b06c2c12e32c428b5dbcf7bfaf045d

Change-Id: I34b459c3e8b676b47f9ce0da15bfdea5f749ad20

When auto-detecting the GNU make binary from PATH store its absolute
path in the GNUMAKE variable to ensure to keep using exactly the same
GNU make binary even when the PATH settings change. This is needed
because the gbuild system relies on the GNU make features detected and
reported by the configure script.

Change-Id: I05916f0ad7f2e98e4e908455ed72758ebf396863
Reviewed-on: https://gerrit.libreoffice.org/2924Reviewed-by: Michael Meeks <michael.meeks@suse.com>
Tested-by: Michael Meeks <michael.meeks@suse.com>

Remove unnecessary commented out code, remove comment "spacer" lines,
in general tidy up this code to make it easier to read.

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

Change-Id: I6ce6292a490ef39c111aa7f4c0a5ada0d45c16bc

Change-Id: I1c305c67772b46cede6b4da3e79578f2f1a8ee89

Change-Id: I700f25f16ab77212c1f3fdc4be1eb24f4c614c30

Change-Id: I4c9c383cffa2cfadbee32ec1e19af4b569b13f0c

Change-Id: I447a2cfd0e90e61c4a3015d9ef58a78ae86eb874

It turns out this is not actually a performance problem but an oversight
in implementation (or a bug, if you want .-)

Every manipulation with a table (e.g., move, resize; actually even a
selection of the table) leads to creation of a full copy of the table
(SdrObject::getFullDragClone()). One of the actions the table copy impl.
does is to call sdr::CellProperties::SetStyleSheet() on every cell of
the new table. CellProperties is derived from
sdr::properties::TextProperties and CellProperties::SetStyleSheet() just
passes the call to TextProperties::SetStyleSheet(). This is where the
trouble begins :-)

The SDR representation of a table, SdrTableObj, is derived from
SdrTextObj. Because of that, SdrTextObj needs to be able to contain more
than one SdrText (because a table needs one for every cell). This is
handled correctly by TextProperties. But, because there is no SDR
representation of a single cell, CellProperties uses the SdrTableObj as
the SDR object it works on. Therefore TextProperties::SetStyleSheet()
processes all SdrText objects of the _whole table_, not just a single
cell. And this is repeated for every other cell...

Change-Id: Iab2e2d0e1e8038710645c0bd24666e6032b0a003

Change-Id: I819539b372d33cc8982a01d7bb72093cedb6461f

Change-Id: I68004a90cbfdf6bf6c5b09998406a5479e5c50d6

Change-Id: Iacf5e9cc509e29aaf5dd1321407c0de9db7677f3

Change-Id: Ie15482e9953d14927b4f918c43537100a8332689
Reviewed-on: https://gerrit.libreoffice.org/2923Reviewed-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
Tested-by: Ahmad Harthi <aalharthi@kacst.edu.sa>

Impress is also affected by fdo#62050.
In RTL UI, comment window is RTL and editbox’s (editeng) default
writing direction is LTR.
I suspect, bug is result of this RTL & LTR mix-up.

Change-Id: I188ce05350f721081378509915158d4ec4e5f8cf
Reviewed-on: https://gerrit.libreoffice.org/2922Reviewed-by: Ahmad Harthi <aalharthi@kacst.edu.sa>
Tested-by: Ahmad Harthi <aalharthi@kacst.edu.sa>

Change-Id: Id4abf40d4965c015baf7a4213cd6dde8871a2474

Blind fix attempt for the Android-X86 tinderbox.

Change-Id: Ib7ae0d077aad149d27c19f1b0137bb87062d0f60

Change-Id: I4633df8ffafe10397bf80d9b0f5c20aa0ed36416

Change-Id: I2e56c580b30435731b3b8dc716abae19c8673acf
Reviewed-on: https://gerrit.libreoffice.org/2920Reviewed-by: Kohei Yoshida <kohei.yoshida@gmail.com>
Tested-by: Kohei Yoshida <kohei.yoshida@gmail.com>

Change-Id: Ibb79f153799ac98d29bd2391c8903b00bb153956

Change-Id: I965e023d00306334f2b1aa7d3d92c90d44769b76

Change-Id: I5023a57f3a089f1af7cd7fe53f57f82c60eb2b65

Change-Id: Ic59376eea086802f173e590faf2693b646db3feb

ScCellValue copies the cell value. Let's not use it in ScCellIterator.

Change-Id: Id478b607c702077751878f557b8779c98b68db28

Change-Id: I7b80e8418e8f5ea4ea64f4f05c3709aaf8606bad

Change-Id: I666886c737b118b30faff6c3763d40c1c4b7fca7

Change-Id: I8b39adaaff3874e26709579530fb74b2bf0543be

Change-Id: I7b9b221c3536c94fbf56c9b5230e62927efe6e1f

But of course such migration has to be done in gradual steps.  For now,
ScCellIterator supports both methods.

Change-Id: I40cd8969b05598fe20916e43a5537217e824d418