useful when removing RTL_CONST_STRINGPARAM

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

Once this was fixed it seems to work nicely. Add keywords in
File:Properties and they show up in Finder's Properties, and Spotlight
finds text from the document contents.

Change-Id: I203576a5a7e53ca3485b0a82f0c6d06122f361d1

Change-Id: Idcc2d548363ddab04dd8acaa1dfb854a19ca47ef
Reviewed-on: https://gerrit.libreoffice.org/2200Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>

Change-Id: Ic99a5a11b32d4712b91d58021e1e9ff3bab7890d

The one command running the soffice wrapper that does also
some extra work is the usual and simple case, running soffice.bin
is needed only when launching LO in gdb.

This reverts commit eee2fe2e.

Conflicts:
	Makefile.in

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

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

Cleaned up the call sites.

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

Project: help  a97475f929677fa26b59ecabe30ecbfa7159a521

Change-Id: I7fe4da07852d538216b92b9350903b7022bdc9fa

Change-Id: I54880cd7d404692b8fee16c331c8e7a64508f52b

Change-Id: I06d6dec259f4e1d28d0fb13497097bbfae156b2f

Change-Id: I14bd9c0a4b9b55963da67102468d573f7132fab7

Change-Id: Ibc8178e2dd7209705cb752f9570e414483c319a7

Change-Id: Ib895be66ecb4c95a86696007fdda453d3a3b34e0

Change-Id: I7fdf7fd285d6b8c584d8fe225729f15f3f9798ad

This reverts commit 324d2f94.

Change-Id: I0c1c3412554de2093c9c94de89ff74a89869fa6d

::rtl::OUString was replaced to OUString and all occurences of String was replaced to OUString in dbaccess/source/core/api

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

That's so that heavily related ones stay together:
 PRINTREPEATEDVALUES
 PRINTWHENGROUPCHANGE

Change-Id: I90513da4ae9ce0798dec91e5057b112735c1cdc2

Change-Id: Ia3d8612e3774ee62b6d885cc9ab801361642c3a3

Change-Id: Id14dd289f8803378838725fbe08e327c9b1d233d

Change-Id: Iffd518a36f1418302955b0d85af8700cf8f9f75a

Factorise the "should this element be printed" decision into an
utility function, which is used by
1) AbstractReportElementLayoutController
   (in charge of non-formatted values: string, image, OLE object, ...)
   which already obeyed PrintRepeatedValues.
2) TableCellLayoutController
   (in charge of formatted values: dates, numbers, ...)
   which blissfully ignored PrintRepeatedValues,
   but obeyed the display condition.

Rename the inconsistently named
 PrintWhenGroupChange
 PrintWhenGroupChanges
 print-only-when-group-change
 print-when-group-change
to
 PrintWhenGroupChange / print-when-group-change

Change the meaning of "PrintWhenGroupChange" to "override
PrintRepeatedValues in first occurrence in group". Since this feature
never worked under the old semantics, no loss of feature. Since we
change the XML attribute name, no ascending compatibility problem: it
will be reset to its default value.

Pursuant to the new meaning of PrintWhenGroupChange, change its
default to *true*, which is the sane default.

Change-Id: Idbe8e90565a354f70db222d047b3d51eeddbbb9f

Consider the following situation:

Property Name     Property Order Index
-------------     --------------------
propA4                   4
propB5                   5
propB4                   4

And the loop goes over these properties in this order.
propB4 should be before propB5, but with the old code,
propB4 would be pushed after propB5: it asks for position
4, but as positions 4 and 5 are already occupied, it gets
pushed to position 6.

Remaining difficulty: properties from different
property index ordering series will be interleaved.
This should be solved at object model level;
ideally property order index should be unique,
at least within an object.

Change-Id: Ie235a4b22155df97df139f1dc354247845626620

Change-Id: Id21de98433f52c8659a3432c1c47354e18166f06

Change-Id: I96685f405989fdd3b090b6a482edf8ad65bfd4e9

Reverting this because it breaks a lot of stuff

This reverts commit a2dbcf1e.

Change-Id: I0f64820887919386f266290ae8b7c53f8a0a5458

Change-Id: I65b4ea5bb8beacef79e963e4dd78fa764f3ab697

Project: help  b568e27d3e9627927db41ebe0600f171cddf3708

Change-Id: I381266cbc9eb2a6d95b7bdc5e80a1e486112dbbe

Change-Id: I0660592f233d9f190d11337068f33f2c13ba9251

Change-Id: I7704f46d262888639a17c5219e784559db91b847

Change-Id: I407b2308756b46fbf0920881fc20972b486819b7

Change-Id: I6dbf44bb78f14ab71a48a9cd4e9ebba60bfc97d2

Change-Id: I911863f07b08e771d78a4a98d9a4f82c93a7d55e

- a >12.000 LOC configure.ac is more than enough for everybody
- removing some 100 lines cant hurt
- the SYSTEM_LIBCDR=$SYSTEM_CDR stuff should be removed in a later step,
  by renaming them in the build

Change-Id: I5c065c5c341561258800a124b0fc1f40b3d59211

Allows LibreOffice to start with no bluetooth, and for it to
appear and disappear dynamically at run-time, cleaning up stale
bluetooth sockets, and re-binding successfully each time.

Change-Id: Ifa04c8cc1859c98adca94ac0e57c7ebd85f2f31f

Change-Id: I5e11a0fcfd8db648a40c738cbc8181889cb36136