Change-Id: I82d5a957b5c38b8aa19e28ceb8d6850c0bf7526e

Change-Id: If433376df24a3646d80f30e1dfa45463653ea72b

Change-Id: I0521f9ead0ee317f4eafefafb9c91f942b977cd1

...so that 16f856a5 "Adapt climaker to
cppu::bootstrap_InitialComponentContext removal" does not fail.  Starting uno
processes from within the build should thus use URE_MORE_SERVICES/TYPES now,
too.

Change-Id: I0a7cfacc804814a2688e54275ebc3e39540d307c

Change-Id: Ic3948384bc1709d648507c41542c34437abea468
Reviewed-on: https://gerrit.libreoffice.org/1422Reviewed-by: Luboš Luňák <l.lunak@suse.cz>
Tested-by: Luboš Luňák <l.lunak@suse.cz>

This is a complement for fdo#39454 bugfix.

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

There are now no callers that need it, and it is alwyas 0 anyway.

Change-Id: Iddee488084e644ac82e9dbf9f251d5ef4bd7c59d

See previous SwUndoInserts commit.

Change-Id: I8d255e85a72bb93be280f87bab096d69f1e9f573

There is a problem here; to see it paste something 3 times, then undo
twice and close the document, there is a SwIndexReg assertion because
the SwPosition in the one SwUndoInserts points to a node in the Undo
nodes array that is removed by the dtor of the other SwUndoInserts.

This is because the Undo objects are destroyed from the outermost Redo
backwards, which is usually a good idea but does not work for
SwUndoInserts, which (as they currently are) must be destroyed in the
other order.

But with the previous change to only store whole paragraphs in
SwUndoSaveCntnt it is possible to replace the SwPosition here with
a SwNodeIndex, which points directly to the SwTxtNode and thus does
not care if the position of that node changes due to whatever order
other SwUndoInserts are removed.

Change-Id: I4f0cf308d26f6b2e5aaa8997951c03ae7b2f0951

If we always create a new text node in MoveToUndoNds, there is no need
for this silly and fragile adding of a "space" at the end, and clients
can rely on having a unique start node for their content.

Change-Id: I60937f33bac8ae2f9732eebfe6e8083b6bb2f210

I checked history of all the questionable ones, and the itrform2.cxx
one was a genuine error.

Change-Id: Ibfcd8732ba4a66a8c038940ae10f8b27fee466c9

Fixed position of insert new sheet button (+) when using a sheet with
a different directionality than that of the interface.

Change-Id: Ifc7020c4eb7a1686c23b4d827c47494b88a236b5
Reviewed-on: https://gerrit.libreoffice.org/1385Tested-by: Lior Kaplan <kaplanlior@gmail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>

Change-Id: I36c6c56d7277b9b3853b846c86c1f4dd47ebdb08
Signed-off-by: Luboš Luňák <l.lunak@suse.cz>

Rather than at the end. There is still some flicker, because
SwEditWin::MouseButtonDown() selects it first too and puts the cursor
at the end, but I've wasted already way too much time and trying
to avoid that or the flicker.

Change-Id: Ib0f00f3f955e64427dba8dd1c6ae7123afc17b34

Change-Id: Ic5076bc7be30e72686840c06f1f9b441b774f3ba

Change-Id: I609c6f3c071d304f222cd2d15a6ad52dc34652c7

Change-Id: If7172ff8b8724d0c915aabd42608594ab0c71042

Use environment variable SAL_LOG_SYSLOG=1

Change-Id: I0c260ca69fbeefb0c2e8cc46ca6955e92791c05b
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I6771f427148f9f46abacaa5f096b98693f3673f9

Change-Id: I538468b606cc29fd56362dbeb99c2698efac0f58

cppu::createSimpleRegistry, cppu::createNestedRegistry, and
cppu::bootstrap_InitialComponentContext for registry-based type/service
information, superseded by cppu::defaultBootstrap_InitialComponentContext.

Aborting stubs for the three functions are left in cppuhelper/source/compat.cxx
to avoid having to incompatibly change cppuhelper/source/gcc3.map.

Change-Id: I8e714c021c246b15a6e6fb7f25d754dceff17c8a

Change-Id: Icd65d8a456cf59b6e4b6b6bfb095c0bff498bcbc

Change-Id: I853927f5057d60962dc858335c4350881768b2b2

Moved much of the field area specific storage from the parent dialog
to its child field area control. It's much cleaner this way.

Change-Id: I603fbebc2d9d62742a3808d6f72ca23357d84046

Change-Id: I10727407c04b46eb80fb7b9b7f5ddcb0c7d628fa
Reviewed-on: https://gerrit.libreoffice.org/1425Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>

This commit just removes some unnecessary using declarations

Change-Id: Ia1c7cc925b2db5b1172fae91dc703883d6539eaa
Signed-off-by: José Guilherme Vanz <guilherme.sft@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/1430Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>

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

Change-Id: Ie4aac09e9aa7232c61cfdcda7b2bffd5002036a7

Change-Id: I04a7a1b119cb6cca4bf0dd0d576e5e051f99cc6f

Change-Id: I750058d7e25de26bf82e76ff09c69257ae09c5ba

Change-Id: I4e18ce06db42e13479809ba8eec70033943271cf

Two cases:
1. The items of PairedList have unique id so it works well
when change order of items. Thus when there is no poentry
for some of the items than use the original strings.
2. The items of other lists have only an order number as id
so when order changes than id changes too, which means
poentries do not match with original items. To avoid
pointless lists fill the whole list with english items.
Actually it is a rare case when only the order change,
at most time it goes hand in hand with changing of count
so use that to decide when use original list. This whole
translation ignorance lasts until next po update.

Plus delete one call of MegreRest() function because
it was called twice for some macro defined strings.

Change-Id: I4b34a1831991608583f53e1885c4eb2aea605493

UseOnPage got changed in commit
fa0f42ba, but SvxPageUsage got
unchanged. Given that right now other applications don't support first
page headers / footers, leave SvxPageUsage unchanged and provide
conversion methods between the two types.

Change-Id: I2ff51793718a26f62157c3847034ac3fae905292

Change-Id: Iee20612a194b563d89c02a286993cd16fd196bbe

Change-Id: I1de82c254438bd3f706caa3c3b3221cfc4de5ff1

Change-Id: I69a0c62ab5b4da036a77bd6c3b2baec0af7c8339

Thanks to Matus for pointers.

Change-Id: Iff2254a3f59ae95c11988a33f322ede5d04b5452