summaryrefslogtreecommitdiff
path: root/odk
AgeCommit message (Collapse)Author
2022-01-02Bump copyright year to 2022Adolfo Jayme Barrientos
Change-Id: Icbb000677066127fa67e8c22fb0ab6880acc0169 (cherry picked from commit fb32c4d96141ccc1766fa4e39405130fcf409a6a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127848 Reviewed-by: Martin Srebotnjak <miles@filmsi.net> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-11-15Clean C++ SDK example "counter"Hossein
* Use <iostream> instead of <stdio.h> Change-Id: I5cc70613c0b183c24bfa73b779dac3b382b31c93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123328 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-15Fixing the license statement for the Convertor C++ exampleHossein
Fixing the license statement for the 'Convertor.cxx' and 'Makefile' according to the '/TEMPLATE.SOURCECODE.HEADER' This example was added in 83b529d88388c7c8e0563242a030063bd95c4bed Change-Id: I654d641999aab6951ad21f84fd75e080bb709ec4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125128 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-09Add Convertor C++ exampleHossein
* Add Convertor.cxx * Used Makefile from DocumentLoader with some changes * Updated odk make files * output.pdf is generated from the input odt file Change-Id: I3e46f2895443f75b2f3815280b0f793bca5138e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123736 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-25Cleanup DocumentLoader C++ SDK exampleHossein
* Remove unncessary C-style cast from DocumentLoader.cxx * Remove trailing whitespaces from Makefile Change-Id: I7cff589353d3e40301cf45ce0a76e0c75beddf13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124115 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-09Typo: *adress* -> *address* (except from not translated German parts)Julien Nabet
Change-Id: I62e12aed5bc67119433c39ff333f69b79944dca3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123318 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-05drop 'using namespace std' in o* r* x*Julien Nabet
Change-Id: I15d56d133cf464a3cb6483be785b1259c7f35b43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123120 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-03drop 'using namespace std' hereRoman Kuznetsov
Change-Id: I6ebbd0ece563f0d877b03389fa9a96311cd207cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122867 Tested-by: Jenkins Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
2021-09-20Adapt SetWindowLong call to 64-bit buildStephan Bergmann
This failed with GWL_WNDPROC being undefined in 64-bit builds. See the note at <https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowlongptra>: "To write code that is compatible with both 32-bit and 64-bit versions of Windows, use SetWindowLongPtr." Change-Id: I7abcc681b4daf459eb0c0481266949c75ecf4dda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122341 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-20Fix type of css.drawing.FillProperties FillColor propertyStephan Bergmann
(where css.util.Color is a typedef for UNOIDL LONG). This caused issues on Windows, where in C/C++ sal_Int32 is a typedef for long rather than int. Change-Id: Ic0407674d06a219210d7f0448100005d7135eb79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122340 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-17tdf#143550 - use the term "gluepoints" consistentlyrocso
Change-Id: Id10dc2ef13f54a148a800003cc4bd88ca1a0056f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122233 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2021-09-14Untabify odk/util/check.plStephan Bergmann
(trying to change the actual content of those lines would otherwise trigger our "indent with Tab" git commit hook) Change-Id: I97449056eb7850d3993fa5ac565e342d0bcbf200 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122093 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-10This example doesn't have any idl filesStephan Bergmann
Change-Id: Ia70268084603db3329d276533a9351e6c1eebbca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121894 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-09Fix apparent typosStephan Bergmann
...introduced with aaebbb0e597bfeb8e1c545130a0d17a55b164228 "INTEGRATION: CWS jsc21" (but which never caused an issue as cppumaker generated output for all of $(COMP_RDB) anyway when the undefined $(TYPESLIST) didn't contribute anything to its command line) Change-Id: Ic6792ad9edc159c02d307ca72500605bc3c38077 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121851 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-26Remove spurious odk/examples/java/MinimalComponent/BuildMinimalComponent.xmlStephan Bergmann
It had been added together with odk/examples/java/MinimalComponent/Makefile in ff4c86ff37af5136466d49a9fb394974ee62cb0f "Added an example for a minimal UNO component", and it apparently is an Ant build script that shall do the same as the Makefile. However, it is apparently unused: For one, it does not appear to get referenced from anywhere else in the code or to get mentioned at <https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide>. And for another, it would apparently only work on Windows (using e.g. "${ODKPATH}/windows/bin/idlc.exe"), but would typically fail even there with something like > > ant -f BuildMinimalComponent.xml > Buildfile: C:\lo\core\instdir\sdk\examples\java\MinimalComponent\BuildMinimalComponent.xml > > init: > > unoidl: > > BUILD FAILED > C:\lo\core\instdir\sdk\examples\java\MinimalComponent\BuildMinimalComponent.xml:35: The directory D:\cvs\api\odk\WINexample.out\misc does not exist due to the hardcoded D:/cvs/api/odk paths. Change-Id: Idd020bcf1a2383295704b208d3ac2be047f270ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121050 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-25Fix corrupted odk/examples/java/ConverterServlet/web.xmlStephan Bergmann
Instead of just adding a license header, 2b4fd2c89a38ccac13c72f2e94501a8702e7da4b "re-base on ALv2 code" had apparently erroneously overwritten this file with the content of the completely unrelated odk/examples/java/MinimalComponent/BuildMinimalComponent.xml. Change-Id: Iee6dcb528dbb444a132c27e7183b3957319882c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121037 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-18Fix typosAndrea Gelmini
Change-Id: I0a8ce634944df4af5c9e2000af5f6429b4e40b2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119097 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-16Porting C++/Java DocumentLoader example to PythonHossein
* Using UNO for Python * Opening the file in LibreOffice if it is listeing on port 2083 Change-Id: I14b1a38da5d66dd2ee8c859071c148ce08a080d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118142 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Tested-by: Jenkins
2021-07-14Fix typosAndrea Gelmini
Change-Id: I809231e7e6ceaa93c2d0b523de8a4b93b07b449c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118841 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-07-13Ported Draw example from Java to C++ and done some tweaksHossein
* Created Draw.cxx * Used Makefile from DocumentLoader with some changes * Updated examples.html to reflect the addition * Updated odk make files Change-Id: I37426d63854222ef8bedb5f61edb420baec4d28a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118034 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-07-12Cleaning up DocumentLoader C++ SDK exampleHossein
* Removing calls to C functions * Simplifying string usage Change-Id: Ia8ca329d7ad586d98e309809e430006eaac9eaaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118131 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-07-01Update documentation for uno executableSamuel Mehrbrodt
After -r parameter was removed with 5a1d51139c580dc64578d36dc1b4a31a4e5e0ef8 Change-Id: I1961f35ea375e7fd7426958275de0809c8fc9e2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118087 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2021-06-23Remove unused DOCTYPE from odk/examples xcu fileStephan Bergmann
The declared entities have apparently never been referenced ever since the file's introduction in 9fa09d43d0dc0ec0ac71bad31b85ce7fc302ee90 "INTEGRATION: CWS sdkinspector2". (And at least xmlreader skips and ignores the content of such document type declarations anyway.) Change-Id: I8263200f52bb5f1692090995574619f9c0ec478f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117658 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-03-23Rename LO Windows arm64 ID to aarch64Jan-Marek Glogowski
The Windows platform is called Arm64. But now that the ID for Mac is also going to be renamed from arm64 to aarch64, this get's rid of the arm64 as the UNO identifier and user in gbuild, just like on all other Arm64 platforms. Change-Id: I60a7eafd04b426f17b6e41ad9a09e6405c0d4173 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112973 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-02-01Drop FAR/NEAR from 16-bit WinAPI timesMike Kaganski
Change-Id: Idf71c662138c281333a83cc76a9d75cbf086f362 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110236 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-05tdf#96505 : Get rid of cargo cult long integer literalsumutbayramoglu
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>
2021-01-03Bump copyright year to 2021Adolfo Jayme Barrientos
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>
2020-12-05Silence cid#1470402 FB.DM_DEFAULT_ENCODINGStephan Bergmann
...where the default encoding should be the appropriate one for reading the Runtime.exec output Change-Id: Ib64bfcbcca985f2de506f8628b506e6dc7bfc035 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107255 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
generated by cgit (git 2.34.1) at 2024-06-19 17:56:24 +0000