Change-Id: Ia01528460e2f4b610d123e29cad66520abc6a965

Change-Id: I1b6fb6b47439c448ac31983702772e2115c70d56

Change-Id: I727e7f2a7527c60bb45f0ba5d0e88a66c5ccdd6f

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

It compiles on Windows and Linux, here, with flags:
   --with-help --with-java --with-lang="it"
Made with the ignorant brute force of removing each include
one by one.
The tree with each commit (used to bisect) it's here:
https://github.com/Gelma/core/commits/gr_push_brute_force_slot_2

Conflicts:
	basctl/source/basicide/bastype2.cxx

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

Change-Id: Ibe4613e2fd77eec8e6e6d1c5e880b596e103a7b8

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

Change-Id: I5dd7cf6ede401b0271296d4f76df266ec4680f74

Change-Id: Iffdb3d72b24b44cb895f1729aadbbae1802e80bc

Change-Id: Ibd0cc43ff210ffaae291f4f4467ba8ebe265c446

Change-Id: I73850d2b2ea6ff4376e25e0be39c65c35328a9a6

Change-Id: I533f1177ff7de2409cdca90f35788d057a5fc3e5

Change-Id: If2758fa42b484a5afbe0d358a3d4533c68189697

Change-Id: I8cf382e7f5f5ed9c797be9ec2b42f0d7f9f0b0ce

Change-Id: I0177a0f50ba65553773f43a28e8790f7e1f8de9b

Change-Id: Iaadb8aef9e10b378fca844fa323e0a1ae369d31c

Change-Id: Iff55c88a365859400e87f3333735e54ba59811b6

Again, the motivation is that dumper for something in editeng should be
in that module as well, before home-grown dumpers are invented and
duplicated e.g. in all sw/sc/sd.

Change-Id: Icfeed9549efbd80226ff04e9070766188cc8646e

...looks like loplugin:saloverride has problems detecting missing overrides in
case of covariant return types

Change-Id: I08f2f67a33cd1cfaf9308cd87d7a5f92203980ed

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

Change-Id: I747d3e9d86f1a50b8e951c0feb351072d432cda0

Change-Id: I33b639b3505d5db2ea8b708d80e68e576ec53308

Change-Id: Ie370161e51ff83cb605bc57d317ff945404e5611

Also hide copy ctor and assignment operator of all derived classes, to
ensure that Clone() is the only method to make copies of them.

Change-Id: Icb3b50c63b086abe8c9add32e3041fe19692d20b

Change-Id: I87e63008fe7c6db62c18bf461dc4dcda733393ac

Change-Id: I510e0d601e293ed8e013a0273d5ae0f9be078d8a

Change-Id: I00f3ed059bd633e662e5bee09703ca505bf3b9a5

Change-Id: I277fbf522b16d9b479260df8372a5ee160adcc37

Change-Id: I924a212210703b0f6136ddefacd77d98dc89f42d

Change-Id: I6b4a7f8053adea6d86ee625201eeead188bbadcc

Change-Id: I6a6e702e243b389f1c487b6b5390f28a4292cc74

Change-Id: Ic020d9604814213e13c339b07b6e74de77a9f400

Change-Id: I2f7967ee20ad71b58e2b0dc7f182769499910373

Change-Id: Ia2ed94dbbb43d2e768da5af5ca7a51f5cda5bae0

Using direct ByteBuffer is much nicer option to store or send
pointers between C(++) code and Java via JNI as it handles endiness
and pointer size for us. Using "long" type can have unexpected
results in 32-bit architectures (mostly Android). This was causing
grief especially when Android introduced support for 64-bit
architectures starting with SDK 19.

Change-Id: Ie92d0f913b668e1724e846d70d1820445d9cb086

Change-Id: I7688968e92ae4b3d6fef19c4544ae91bdcd8b1b9

Change-Id: Ib003da5c7fec7fc3783f01a33a63deb384c7e770

Change-Id: Ifc7b18e173b0c91c24a53fad9c35ac3a34a4b33e

Change-Id: Id90680d3b207973b55927add1c91111268bb2a48

Change-Id: Iefab77e543606cfad937a79743fb3b9a68a0f2a2