Change-Id: I369d6755d3de2dd885214115559150256298852d
Reviewed-on: https://gerrit.libreoffice.org/60051
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

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

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

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

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

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

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: I33d3ac3edbda5e2a9958373123565e28210b55c8
Reviewed-on: https://gerrit.libreoffice.org/59956
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I6c71e079f21093d5f8dc4dbca20624e9fc927882
Reviewed-on: https://gerrit.libreoffice.org/60072
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I3e28ef5646ff39b0e3e8ed8962bfacf5b79176a7
Reviewed-on: https://gerrit.libreoffice.org/60069Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins

labelFT_H_DEFINED and labelFT_F_DEFINED are indeed two labels for the same
widget, and only one appears at the same time.

Change-Id: Ie8c29a43408d1ee29f15c686af906359ef3c50b9
Reviewed-on: https://gerrit.libreoffice.org/60046
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

Change-Id: Ibf2780a2eb658f7210cb5e80cf2b8e2e65fe1bda
Reviewed-on: https://gerrit.libreoffice.org/59979
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

Change-Id: I04c31c96538cb7da07e6bf2e43e6150f04f9d247
Reviewed-on: https://gerrit.libreoffice.org/59978
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

This reverts commit a3c8250c.
"Left/Right" is inappropriate for RTL documents. So we better use Before/After in accordance with tdf#119036.

Change-Id: Id9cb721902d246f837c7440c2f0c049c7c1dc4ca
Reviewed-on: https://gerrit.libreoffice.org/60073Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Tested-by: Heiko Tietze <tietze.heiko@gmail.com>

Sort order adjusted

Change-Id: I09109ac4aa21d8fa77da5c5930682dcf7a4f542a
Reviewed-on: https://gerrit.libreoffice.org/60020
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>

Change-Id: I69247498e13331f6ef84afeb242479f8fb1178a8
Reviewed-on: https://gerrit.libreoffice.org/60068
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

and update o3tl::sorted_vector to handle that

Change-Id: I11a9ec3ec09f835cbd7e49ccda133b9f210d761e
Reviewed-on: https://gerrit.libreoffice.org/59931
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Previously, if an earlier column wished for the entire table width,
then none of the other columns could adjust their size, even if
they only wanted one more character. This slight change gives
every column a chance to "wish" for an equal portion, and
still gives the earlier columns a chance to maximize.

So, this should implement very similarly to before, thus workflow
should not be impacted.

Change-Id: I11e8b94ce333735aa92b5388af6319f8eb0ccc51
Reviewed-on: https://gerrit.libreoffice.org/60027
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>

Change-Id: I607891e120688b746c8a4c577018d97147a79217
Reviewed-on: https://gerrit.libreoffice.org/60029
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I74a12381a222fb3b394176db41cb9d6a9091d5a3
Reviewed-on: https://gerrit.libreoffice.org/60052
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ic1350d5bff80d4a88d3949a412ee9bf02ad969ba
Reviewed-on: https://gerrit.libreoffice.org/60050
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I6190098e7e3f4df415d6aef46d152324cbc3dd60
Reviewed-on: https://gerrit.libreoffice.org/60049
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Since 'string::find()' returns the position of the given
character in the string and that was passed as the amount of
characters to delete from the string, 'm_responseBuffer'
would always be a string starting with a newline character
afterwards, when this part of the code was reached.

Subsequent calls to 'Gtk3KDE5FilePickerIpc::readResponseLine'
therefore always returned an empty string and left
'm_responseBuffer' unchanged, resulting in the lambda function
inside 'readResponse' in 'gtk3_kde5_filepicker_ipc.hxx' to
loop infinitely.

While at it, make a little more explicit that 'it' is of type
'size_t' here.

Change-Id: I3b1c209f8307ab71465d9538a82616dff8656415
Reviewed-on: https://gerrit.libreoffice.org/60047
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>

Change-Id: I35b5fc2f18867c386c8c92d1d7a3a0823bd07b78
Reviewed-on: https://gerrit.libreoffice.org/59863
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

m_bControlsInitialized wasn't ever resetted to false

Change-Id: I9f7bd6504ccaa0a41c9cb075c1ba33436f0f97dc
Reviewed-on: https://gerrit.libreoffice.org/60059
Tested-by: Jenkins
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>

You can access ScDocument via ScOrcusFactory. There should be no 
functionality change.

Change-Id: Ia679b6b006cc60bf24ca11432909682fa527b034
Reviewed-on: https://gerrit.libreoffice.org/60063Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>

We used to have this code snippet in the TiledLibreOffice app back in
the days. Then in LibreOfficeLight it was lost and forgotten (?).

Clearly we need to tell ICU abouyt the data that we include as a
separate file in iOS apps, and presumably any iOS app will be a
LibreOffficeKit-based one, so let's do the initialistion here.

Change-Id: Ib08dc9d7386789d10e8c53114e79d0b5beab7232

Change-Id: I4590f5f705dd08c63a1532ce5afa94a3af953f24
Reviewed-on: https://gerrit.libreoffice.org/60042
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

the latter provides (so far) no added value, quite the contrary:
File > Print > $printer > Properties didn't display generic unx/CUPS
dlg but just failed silently

Change-Id: Ide2ad175ffe55b5c9ac5ca3efad4a43b692f9984
Reviewed-on: https://gerrit.libreoffice.org/60040
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I293ede0dbac4b36a1b91b86100bc11593b402d06

(The LibreOfficeLight Xcode project still needs to be adapted
correspondingly.)

Change-Id: I0b17c595fc0d169f6393ab8734a1eecb241f59be

Crash seems to be limited to vertical FixedLine control type. This is
just a band-aid, need to find out what's wrong with drawing this specific
control. Other control don't seem to be affected

Change-Id: Ie04bc04bbdf95920d62d43ac7874e7dba1441a4c
Reviewed-on: https://gerrit.libreoffice.org/60039
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

it causes too many issues: giant tooltips, dialogs can't be smaller
than 640x480 etc. Need to figure out a better solution

Change-Id: I4cc404687a60f2e0a39fd748fcc8cfea7cb7c0ac
Reviewed-on: https://gerrit.libreoffice.org/60038
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: Ifd6da1590323b1e8e7065a35f3b594910866d31a
Reviewed-on: https://gerrit.libreoffice.org/59990
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: I5e1541e87f1eabd1bf564c7a8c6721377b51cffe
Reviewed-on: https://gerrit.libreoffice.org/58911
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I496e439e2f7e24c05f798f1a7ed0081ca0725f5c
Reviewed-on: https://gerrit.libreoffice.org/60037Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins

Number of GenericSalLayout::LayoutText() calls for each & every menu
item till a Writer document is opened: 3 (before) -> 1 (after).

Change-Id: I08a3d174bf15bafbcbce612712f2ab773cd5e085
Reviewed-on: https://gerrit.libreoffice.org/60045Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins

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

Since these don't use soffice they need to be tweaked to use RR variable.

A rr git master build from some weeks ago can record all tests, except
CppunitTest_dbaccess_firebird_test which fails.

smoketest is a bit tricky because it spawns soffice which checks RR
variable again and starts a nested rr, but fortunately there's a
flag to prevent it from aborting in this situation.

For UITests currently only the soffice.bin is recorded, not the python
test process.

The size of all the recording is about 35G per run in a --enable-dbgutil
build.

Change-Id: I2143618fa2181e36b6aaeded43637cb3481f5e47
Reviewed-on: https://gerrit.libreoffice.org/60032Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>

For cl version 19.15.26726 (VS 2017 15.8.1) that would detect
HAVE_CPP_GUARANTEED_COPY_ELISION, but wrongly so as it turns out.  :(

The compiler has C++20's __cpp_guaranteed_copy_elision feature-test macro
defined (and <https://en.cppreference.com/w/cpp/compiler_support> claims that
C++17 "Guaranteed copy elision" is supported in "MSVC 19.13", aka VS 2017 15.6).
But the build then failed at

> [build CXX] sw/source/uibase/app/docsh2.cxx
[...]
> C:/lo/core/sw/source/uibase/app/docsh2.cxx(427): error C2248: 'editeng::SortedAutoCompleteStrings::SortedAutoCompleteStrings': cannot access private member declared in class 'editeng::SortedAutoCompleteStrings'
> C:\lo\core\include\editeng/swafopt.hxx(66): note: see declaration of 'editeng::SortedAutoCompleteStrings::SortedAutoCompleteStrings'
> C:\lo\core\include\editeng/swafopt.hxx(55): note: see declaration of 'editeng::SortedAutoCompleteStrings'

due to enabling the HAVE_CPP_GUARANTEED_COPY_ELISION-conditional code in
include/editeng/swafopt.hxx.

(And while my VS 15.8.1 stopped detecting HAVE_CPP_GUARANTEED_COPY_ELISION then,
<https://ci.libreoffice.org/job/gerrit_windows/14774/>, reportedly done with
15.7.4 aka 15.7.27703.2035, still mis-detected it and then failed at
sw/source/uibase/app/docsh2.cxx(427) as above, so needed a tweak to the check in
configure.ac.)

Change-Id: Ie14d74f3f795d819047deaafdb1e644ed00ee406
Reviewed-on: https://gerrit.libreoffice.org/59835
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: Idb5267c9bc50e8844654c2f2cd0d123fcbb7aa12
Reviewed-on: https://gerrit.libreoffice.org/60026Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins