Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Idf71c662138c281333a83cc76a9d75cbf086f362
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110236
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7b269fb5bafceba071ebe649a696ef61301c4018
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107366
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I3159bfc21a35fc80aef57c7d809d8ea8c62a732e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108566
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/
Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows-
specific unowinreg.dll in generated jars (so that those jars, when distributed
to a Windows environment, would find a LO installation by inspecting the Windows
registry). That unowinreg.dll was originally built as a 32-bit DLL (though when
building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For
non-Windows LO builds, it could either be built locally with a MinGW toolchain
(--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org.
However, that had various issues:
For one, unowinreg.dll was not necessarily available in a distributed jar as a
64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a
jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have
worked. But practically, those URE jars in turn require native DLLs, which
would then not have been available as 32-bit DLLs for use in the 32-bit JRE.)
For another, at least the unowinreg.dll resulting from --enable-build-unowinreg
on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would
generally not have been available in a target Windows environment.
There appears to be no pure Java way to read the Windows registry, but instead
of using a native code DLL for that, it appears to work just as well to call out
to reg.exe and parse its output.
This removes the --enable-build-unowinreg and --with-mingw-cross-compiler
configuration options. (The sole use of the MinGW toolchain in LO was for
building unowinreg.dll.)
Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I427263ee98206c00cd2b3392fc9f2f55ad1ded5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105692
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
ImageShrink.oxt is created in the org/openoffice/comp/test sub-make, and
CustomTarget_odk/build-examples_java had once failed for me with
> make[2]: *** No rule to make target '~/lo/core/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/bin/ImageShrink.oxt', needed by 'ComponentsThumbsExample'. Stop.
Change-Id: I926d0691e7eee3506d4afe2eda1a2fc873422e18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103502
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia0a24bf32290ecb6b6153ba412d5e282f56d92f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102693
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This is broken since commit 5c39b28a87060f80404079ab77604f664addb063
("tdf#96059 Replaced imageproducer with CommandInfoProvider") but so
far no one complained (maybe because the usefulness of such internal
images from extensions is questionable at least). Given also that
the whole ImageIdentifier feature (even its still working part) is
obsolete since OOo 2.0.3 (according to the OOo dev guide), and that
the availability of a particular image from an internal hardcoded
image list by a particular numerical id is more an implementation
detail, let's just remove the broken code instead of fixing it.
In the meantime, the code was also copied into the newly introduced
notebookbar addon code, so I handled it there too.
There are also the registry schema and a sdk example that mention this
feature, and need to be adjusted. Interesting that the particular
example used there - private:image/3216 is actually broken since 2011
with commit 2559cab126f81375197051fb5b07ba6abb9efc77
("FDO#42454 - EasyHack: remove code associated with unused icons").
Change-Id: I968b4fb8c5b207654476dd92c57d8db0815520ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101529
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: Id1a6b4fc6e156f67550458b4b7e4b1ffe32f812a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101691
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
It passed "make check" on Linux
Change-Id: I255b7a0873170d956c914d76fd363e358f807d7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101596
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8dc0cdcfe6bd90efc596df28e6c6d968b92618b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101098
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
GCC 11 trunk g++ defaults to C++17 now, so that CustomTarget_odk/build-examples
and CustomTarget_odk/build-examples_java would now fail with "error: ISO C++17
does not allow dynamic exception specifications".
550e0e42d9ccef1244299b2d6cbda18549f8af19 "Remove dynamic exception
specifications from cppumaker-generated code" had long since removed the
exception specifications from the underlying (C++ classes representing) UNO
interface types, so just remove them from the SDK example code, too. An
alternative would have been to make sure those CustomTarget use an old C++
compiler standard. However, testing that the examples work against a new
standard has probably similar merit to testing that they keep working against
some obsolete standard.
Change-Id: I8ec9ac2f9ced7bd1b746fb00d9bce94bf6aedda5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99218
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7749951d829eb8aaeacdca0fd66d41cf9d6a1613
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98251
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This moves the classes from juh.jar and ridl.jar to libreoffice.jar
The goal is to have one single jar (and Java module, will be added later)
which developers can include to work with LO.
juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar
on its classpath to keep backwards compatibility.
This is a continuation of ae855bf48163ff64d94cfc34aff8e37abdb5518d
and a preparation to have Java 9 module support.
Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ibfd0e27b0b382fb6e0f71bfd4d9555998b03ded5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92754
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
to complete:
https://gerrit.libreoffice.org/c/core/+/89082
Change-Id: I8363f05f15c8d4ef032ccc8d469dc29231d74ca7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89360
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
jurt.jar and unoil.jar are kept as effectively empty jars, each with a
Class-Path: ridl.jar
in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or
without also loading ridl.jar) will still have access to their content.
Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi)
are not part of the URE, but are now made available by URE's ridl.jar. This
should probably not cause problems in practice.
At least for now, we seal exactly those packages in ridl.jar that were
originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now,
but that would be mildly incompatible, as it would prevent 3rd-party code from
introducing additional UNOIDL entities in the relevant namespaces (even if that
is something we do not want 3rd-party code to do anyway).
However, some JunitTest_jurt_* define classes in those sealed packages. In the
past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt.
Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the
gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes
that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the
UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the
udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests
get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use
gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets
leave that for a follow-up clean up.)
As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/.
Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a
Co-authored-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6fb736591f32907c8977fbac8fbf1dcbaef1bb97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86092
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I5a7bd149554d24276a67437b654f8ffd2610a276
Reviewed-on: https://gerrit.libreoffice.org/85478
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I387f408aefc30132a65088bec05c733346e9d5a4
Reviewed-on: https://gerrit.libreoffice.org/84486
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
On Windows classical "cd" command does not change drive automatically.
So if OO_SDK_OUT folder located on another drive than SDK_HOME we
will receive confusing buid errors.
To avoid this for Windows configuration we should use "cd /d".
Change-Id: I22908d49fc915d3a834972357934349ba82bbec5
Reviewed-on: https://gerrit.libreoffice.org/80827
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Ia34130dbab42d61074a73a2b16e03360b5b123b6
Reviewed-on: https://gerrit.libreoffice.org/81086
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
mostly so that my stringadd loplugin can point out places to improve
Change-Id: I9920ee1c99cdb6b811ba67ff9d8e32aa261884b5
Reviewed-on: https://gerrit.libreoffice.org/80618
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibc1b7393a8e65bf23c78fdb9da78c6b73b544cf3
Reviewed-on: https://gerrit.libreoffice.org/78793
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I926069d6c1f2712e5020d930f7ff6c62fd00e912
Reviewed-on: https://gerrit.libreoffice.org/78667
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
To complete this:
https://gerrit.libreoffice.org/#/c/78312/
This is a massive replace for lines ending with
".." instead of "..."
It passed "make check" on Linux.
Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe
Reviewed-on: https://gerrit.libreoffice.org/78356
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I46650797efa70d6b416356a3e5ed57d26d8e69be
Reviewed-on: https://gerrit.libreoffice.org/78252
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I85766d1ba3598b37e3a776605628402ca5795bc5
Reviewed-on: https://gerrit.libreoffice.org/77809
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
To complete
https://gerrit.libreoffice.org/#/c/77567/
Change-Id: I9f56eb308ff9b23c4259a0abae60ac2f97038393
Reviewed-on: https://gerrit.libreoffice.org/77589
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I0b5182a3cec87ee44b7467d6e8e3d1c21ce93ac2
Reviewed-on: https://gerrit.libreoffice.org/77680
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I5d0776d5f90f44ebbeeb5916cbbf6e87406adcad
Reviewed-on: https://gerrit.libreoffice.org/77609
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I62b669b85e2380df2a6efa05764f21405e7eb2ae
Reviewed-on: https://gerrit.libreoffice.org/77318
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
"an one"
Change-Id: Ic12d139acfdb32aaf0089c60609feaa653fd686b
Reviewed-on: https://gerrit.libreoffice.org/77259
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
"its"
Change-Id: I02c660e46964270376a66210fdb5f1b1985ce5b6
Reviewed-on: https://gerrit.libreoffice.org/77255
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I994f656b0828c9c7ea1463b86cd692f847d01e7e
Reviewed-on: https://gerrit.libreoffice.org/77126
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Partial revert of:
https://gerrit.libreoffice.org/#/c/76028/4
Change-Id: I94173556f1dff21ff47245f8b632411fc8be1ff6
Reviewed-on: https://gerrit.libreoffice.org/76200
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: Ib361243332b7219c0073c787c378c648e44705f2
Reviewed-on: https://gerrit.libreoffice.org/75487
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Extracted from https://gerrit.libreoffice.org/#/c/75487/1
Change-Id: I80f9247c5c961a33c0d2c8354ea0524820b33409
Reviewed-on: https://gerrit.libreoffice.org/76028
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: I538db88f8477dd2d2ad25c372928fec6c11d979d
Reviewed-on: https://gerrit.libreoffice.org/72105
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
not before vowels with a consonant sound so its a url not an url
Change-Id: Ic27ff3bee67469284d460c31ced6f63cb3633db2
Reviewed-on: https://gerrit.libreoffice.org/72062
Reviewed-by: Jens Carl <j.carl43@gmx.de>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If280e1e944c877462cb84b579e19d4fd2ad1900b
Reviewed-on: https://gerrit.libreoffice.org/70813
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change indefinite article "an" to "a" before
the word unique and some variants.
Change-Id: Ia14a6f3b9ec6b257ad8bed3b089faa9b6f07d44f
Reviewed-on: https://gerrit.libreoffice.org/70174
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I0d49ec7db57a0f7d18489dad61e86cbfdf4418cd
|
|
Change-Id: I651b7f202fa52ff5f5357a11aa72c43eb7dc7f95
Reviewed-on: https://gerrit.libreoffice.org/64102
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: Id5489f3e8f1d3ced3d57b56f8d3a7a4818af0fca
Reviewed-on: https://gerrit.libreoffice.org/62377
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
...so, for simplicity, just include whatever generated DocumentView$*.class by
wildcard
Change-Id: I779e2709c8ef2859d68233300302dd62dbe2455f
Reviewed-on: https://gerrit.libreoffice.org/62073
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I01855c37955dcae13dbb3c6f028d4030dc48945a
Reviewed-on: https://gerrit.libreoffice.org/61657
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Just keep the definition of _WIN32_WINNT in windows.mk, which
claims it automatically derivates WINVER in some sdk header.
Change-Id: I0a83e91ffdc9e0fc847433a92a45424fbfcb189c
Reviewed-on: https://gerrit.libreoffice.org/61631
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: If4dc6458d9c5fb3b574c1bb55196a5086aff3365
|
|
It passed "make check" on Linux
Change-Id: Id25a7893e536a579cef58f63e8ec7ce240ad16fb
Reviewed-on: https://gerrit.libreoffice.org/60633
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|