Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I1b6fb6b47439c448ac31983702772e2115c70d56
|
|
Change-Id: I727e7f2a7527c60bb45f0ba5d0e88a66c5ccdd6f
|
|
Change-Id: I92045fe661e4d1d667c860dfd47559d2303ca531
Reviewed-on: https://gerrit.libreoffice.org/13301
Reviewed-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/12963
Reviewed-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/13308
Reviewed-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/13307
Reviewed-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
|
|
Change-Id: Ia8516da556b3736f34b366e2eb89ad8bbd7bafc1
|
|
DirectBufferAllocator is responsible to allocate buffer. We used
Fennec JNI based allocation (and freeing) because of overallocation
bug in some Android versions. With this the VM based allocator
implementation is added and used by default because of bugs that
happen in newer Android versions (specifically when ART is used
as the Android VM).
Change-Id: I07eb364fd1647b3a09d1568d4fef82398a02dfeb
|
|
Change-Id: Ied2687d334f7d1ff9ff2f3cb6664848d50814b7c
|
|
Change-Id: Ie172f60a7134173462ff9711a40dc74c94ad8206
|
|
Change-Id: If85c6a86434c0aa32d188a0f128f6b6cd613bbb5
|
|
Change-Id: I1b1891f0d7d7b8aa407e7da346ff5f8e3cbe8657
|
|
It apparently contains color schemes and stuff that the code wants access to
here and there.
Change-Id: Ie3f0de5e3846df99a02a2693156679cc6c010d10
|
|
Change-Id: I9e5bff735b0035c147e10ae066da3a4873d66749
|
|
We are experimenting with a pruned configuration database in the desktop case,
and letting the exception propagate here killed the document loading.
Change-Id: I59e5d016617c17c2bc36de2fd69c6691bfa6b135
|
|
Change-Id: Ib9cf1a47eb20bd28d954ddcded89f67cf6865f1c
|
|
Change-Id: I379601099bda928b9eeeaeb29030bc009e3cbbf2
|