summaryrefslogtreecommitdiff
path: root/odk
AgeCommit message (Collapse)Author
2020-12-03Replace unowinreg.dll with execution of `reg QUERY`Stephan Bergmann
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
2020-11-21tdf#123936 Formatting files in module odk with clang-formatPhilipp Hofer
Change-Id: I427263ee98206c00cd2b3392fc9f2f55ad1ded5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105692 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-10-04odk: fix Windows Arm64 buildJan-Marek Glogowski
I didn't change odk/util/check.pl to handle the currently missing climaker. I hope this problem will eventually be fixed before anybody really considers developing with LO ODK on Arm64... Change-Id: Icc070bde77e73362646d62401410277a85d3d697 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103879 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-27Restrict odk/examples to non-parallel makeStephan Bergmann
At least odk/examples/DevelopersGuide/Spreadsheet/Makefile contains two independent invocations of unopkg (i.e., $(DEPLOYTOOL)) and CustomTarget_odk/build-examples_java had once failed for me with > "~/lo/core/instdir/program/unopkg" add -f "~/lo/core/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/bin/ExampleDataPilotSource.oxt" > ERROR: unopkg cannot be started. The lock file indicates it is already running. If this does not apply, delete the lock file at: > ~/lo/core/workdir/CustomTarget/odk/build-examples_java/user/.lock ~/lo/core/desktop/source/pkgchk/unopkg/unopkg_shared.h:44 > make[2]: *** [Makefile:227: ~/lo/core/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/DevGuideSpreadsheetExamples/devguide_ExampleDataPilotSource_register_component.flag] Error 1 So make sure the `make` invoked from those CustomTarget_odk/build_exmaple* does not inherit any -j flag from the outer `make`. (I had observed this with an explicit `make -j4` and --without-parallelism, but this should also be an issue for the implicit parallelism from the default --with-parallelism.) Change-Id: Iff368dbbcad01d3841d63c2985639ba6a3dec1f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103504 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-27Fix an odk/examples dependencyStephan Bergmann
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>
2020-09-15Fix typosAndrea Gelmini
Change-Id: Ia0a24bf32290ecb6b6153ba412d5e282f56d92f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102693 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-31Remove remains of private:image/ via ImageIdentifier addon propertyMaxim Monastirsky
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>
2020-08-31Remove empty ImageIdentifier properties from sdk examplesMaxim Monastirsky
Change-Id: Id1a6b4fc6e156f67550458b4b7e4b1ffe32f812a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101691 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-08-29Fix typo in codeAndrea Gelmini
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>
2020-08-21Fix typosAndrea Gelmini
Change-Id: I8dc0cdcfe6bd90efc596df28e6c6d968b92618b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101098 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-07-22Remove obsolete dynamic exception specifications from SDK example C++ codeStephan Bergmann
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>
2020-07-07Typo: pargraph->paragraphJulien Nabet
Change-Id: I7749951d829eb8aaeacdca0fd66d41cf9d6a1613 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98251 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-05-06Move all public Java classes to libreoffice.jarSamuel Mehrbrodt
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>
2020-04-23make spinbutton demo wide enough to useCaolán McNamara
Change-Id: Ibfd0e27b0b382fb6e0f71bfd4d9555998b03ded5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92754 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-02-24Fix typoAndrea Gelmini
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>
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-10Cleanup: Move files to ridljarSamuel Mehrbrodt
These files are now part of ridl.jar instead of jurt.jar, so move them accordingly. Follow-up cleanup for ae855bf48163ff64d94cfc34aff8e37abdb5518d Change-Id: I01df60d99f5296b6252b260f52160c3e62f4b8dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88007 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-02-04tdf#117331 Merge jurt and unoil into ridlSamuel Mehrbrodt
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>
2020-01-28Remove misleading commentStephan Bergmann
...that had not been adapted when the corresponding #ifdef had been changed in 2087484c65a3d5e75a9e8ad116d11a4e13366219 "use consistent #define checks for the Windows platform" Change-Id: I5afec630311201269f60b50271f31a36edaf2333 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87593 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-17odk: docs: remove the confusing sentence about "user installation"Michael Stahl
Better not mention an undefined term than to leave people guessing what it means. Change-Id: I589475303e215bd12cdc92e0f858d048052b6da6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86987 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de>
2020-01-06Avoid $(shell $(gb_MKTEMP))Stephan Bergmann
...which, when included in a ifneq ($(MACOSX_SHELL_HACK),) block, appears to be executed every time the surrounding odk_build-examples_test macro is evaluated, even in builds (like a Linux build) where MACOSX_SHELL_HACK is empty. (And which thus caused spurious empty gbuild.* files to be left behind in the tmp dir by such builds.) Change-Id: I8ef0204817f089cd977340a0ce3b6a17a347b209 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86279 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-06Fix MACOSX_SHELL_HACKStephan Bergmann
...so that it is set and actually takes effect when the definition of odk_build-examples_test is expanded Change-Id: I0a4ca22f3b7b17d802dae9195954b030cde9ddac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86251 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-02Bump copyright year to 2020Adolfo Jayme Barrientos
Change-Id: I6fb736591f32907c8977fbac8fbf1dcbaef1bb97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86092 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-12-19sal_Char->char in lotuswordpro..odkNoel Grandin
Change-Id: I5a7bd149554d24276a67437b654f8ffd2610a276 Reviewed-on: https://gerrit.libreoffice.org/85478 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-18Fix typoAndrea Gelmini
Change-Id: Ia721484c9c39d62e939bb3f5628c8dcaa89d5603 Reviewed-on: https://gerrit.libreoffice.org/85417 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-12-18Fix instructions for setting up the SDKStephan Bergmann
(see the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2019-December/084013.html> "Beginner's question about installing Libreoffice SDK") Change-Id: Iea0c394ec052587cdf4ba2a6a7ab38f4214ccbf0 Reviewed-on: https://gerrit.libreoffice.org/85374 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-17Cosmetic documentation fixesStephan Bergmann
consolidate on "Linux", "macOS", "Unix-like systems", "Windows", "Xcode" Change-Id: I448adee41cd557544b9c717ce7663c6fd08a7270 Reviewed-on: https://gerrit.libreoffice.org/85332 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-05Fix typoAndrea Gelmini
Change-Id: I387f408aefc30132a65088bec05c733346e9d5a4 Reviewed-on: https://gerrit.libreoffice.org/84486 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-19loplugin:fakebool (clang-cl)Stephan Bergmann
...plus follow-up loplugin:implicitboolconversion and loplugin:redundantcast Change-Id: I9fc9c5cb46fbb50da87ff80af64cb0dfda3e5f90 Reviewed-on: https://gerrit.libreoffice.org/83207 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-17cid#706181 Use of untrusted string valueCaolán McNamara
use an annotation here and add one to the windows equivalent Change-Id: Ife54949c2e89ae606d7931be82807db4bbb132dc Reviewed-on: https://gerrit.libreoffice.org/83024 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-01odk: fix for change directory in complextoolbarcontrols sampleVasily Melenchuk
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>
2019-10-23ODK: cleanup windows linker debug argsThorsten Behrens
This was a somehow confused & partially commented-out setup Change-Id: Iad5ef6721cda6f85ded3296650ee9a7df9ec59fd Reviewed-on: https://gerrit.libreoffice.org/81333 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-19Fix typo and dotsAndrea Gelmini
Change-Id: Ia34130dbab42d61074a73a2b16e03360b5b123b6 Reviewed-on: https://gerrit.libreoffice.org/81086 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2019-10-12rtl/stringconcat.hxx is not part of the URE interfaceStephan Bergmann
(and #include's of it in include/rtl/*.hxx are already guarded with LIBO_INTERNAL_ONLY) Change-Id: I9224f71a244a69ef69406ea3a5879b66b3cae3a3 Reviewed-on: https://gerrit.libreoffice.org/80666 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-11simplify "a = a +" to "a +="Noel Grandin
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>
2019-10-09Make odk build-examples work on macOS 10.15Stephan Bergmann
...which apparently got even stricter with unsetting DYLD_LIBRARY_PATH when starting a shell, so the old workaround from 9ac2aad4c1cd0f8d513c02a897da90c42f2fa961 "OSX fix ODK example builds with enabled SIP" no longer worked for me (and CustomTarget_odk/build-examples_java failed with > dyld: Library not loaded: @__VIA_LIBRARY_PATH__/libreglo.dylib > Referenced from: /Users/stephan/Software/lo/core/instdir/LibreOffice6.4_SDK/bin/idlc > Reason: image not found ). Building on macOS 10.15 now requires to build a shell from upstream sources and pass it into toplevel make as a SHELL=... command line argument (but which I at least already needed to do anyway, to preserve a global DYLD_LIBRARY_PATH pointing at a nonstandard libc++, when building external/firebird). Change-Id: I00ec0649fafa1842bed3f2a1258e3184d6bcfdd1 Reviewed-on: https://gerrit.libreoffice.org/80532 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-10Fix typosAndrea Gelmini
Change-Id: Ibc1b7393a8e65bf23c78fdb9da78c6b73b544cf3 Reviewed-on: https://gerrit.libreoffice.org/78793 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-09-06Fixing '....' and '..'Andrea Gelmini
Change-Id: I926069d6c1f2712e5020d930f7ff6c62fd00e912 Reviewed-on: https://gerrit.libreoffice.org/78667 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-09-01Fix '..'Andrea Gelmini
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
2019-08-29Fix typoAndrea Gelmini
Change-Id: I46650797efa70d6b416356a3e5ed57d26d8e69be Reviewed-on: https://gerrit.libreoffice.org/78252 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-21odk: fixed typos in generated manifestsVasily Melenchuk
Change-Id: I85766d1ba3598b37e3a776605628402ca5795bc5 Reviewed-on: https://gerrit.libreoffice.org/77809 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-20Fix EXTENSION_PLATFORM for Windows x86_64Stephan Bergmann
Change-Id: I7fbe1963aff666205dbc9405e94d6093fb9a5a48 Reviewed-on: https://gerrit.libreoffice.org/77804 Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-19Fix typosAndrea Gelmini
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>
2019-08-19Fix typosAndrea Gelmini
Change-Id: I0b5182a3cec87ee44b7467d6e8e3d1c21ce93ac2 Reviewed-on: https://gerrit.libreoffice.org/77680 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-16Fix typosAndrea Gelmini
Change-Id: I5d0776d5f90f44ebbeeb5916cbbf6e87406adcad Reviewed-on: https://gerrit.libreoffice.org/77609 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-12Fix typosAndrea Gelmini
Change-Id: I62b669b85e2380df2a6efa05764f21405e7eb2ae Reviewed-on: https://gerrit.libreoffice.org/77318 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-12Fix typoAndrea Gelmini
"an one" Change-Id: Ic12d139acfdb32aaf0089c60609feaa653fd686b Reviewed-on: https://gerrit.libreoffice.org/77259 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-12Fix typosAndrea Gelmini
"its" Change-Id: I02c660e46964270376a66210fdb5f1b1985ce5b6 Reviewed-on: https://gerrit.libreoffice.org/77255 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-11Fixed "OfficeDocument"Matthias Seidel
(cherry picked from commit 856d28801b59d45cf4d32602adc57a08cd618b6d) Change-Id: Ie915588bda5930dc51a1484f20d0bbd9d955ec29 Reviewed-on: https://gerrit.libreoffice.org/77269 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-09Fix typosAndrea Gelmini
Change-Id: I994f656b0828c9c7ea1463b86cd692f847d01e7e Reviewed-on: https://gerrit.libreoffice.org/77126 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
generated by cgit (git 2.34.1) at 2025-01-06 22:18:00 +0000