Add an HTML_EXTRA_STYLESHEET setting to the Doxyfile of idl
and remove HTML_TIMESTAMP = NO while at it (it is disabled by default
since Doxygen 1.8.9).
The hacky CSS rule is extra long due to the need to exclude
*.idl File Reference pages from it.
Change-Id: I848f6c216b68875fd032044f04ca72f5a5e2ed1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186595
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
* Client code must replace uses of idlc and regmerge with uses of unoidl-write,
see the changes to odk/examples/ and ure/source/uretext/ in
40f2aee658 "Provide unoidl-write also for the
SDK" for examples.
* The new types.rdb format is not compatible with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
* For compatibility with old extensions, reading the legacy types.rdb format is
still supported.
* The SDK no longer ships an idl/ sub-directory containing the udkap and offapi
.idl files (as, unlike idlc, unoidl-write does not need them).
odk/config/cfgWin.js had to be adapted to look (somewhat arbitrarily) for an
examples/ sub-directory instead of idl/ when checking for "an sdk folder".
gb_UnoApi_package_idlfiles became unused and has been removed.
* The idlc and regmerge executables have been removed. Module idlc has been
removed except for idlc/test/parser/, which is also used by
CustomTarget_unoidl/unoidl-write_test, and which may eventually be moved into
module unoidl. Module external/ucpp and the corresponding configure options
have also been removed.
Change-Id: I42a0231699b863b5ebe2bee63bc32c8f79278cc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that had been added with 26db47abd0
"CWS-TOOLING: integrate CWS jsc312", probably due to a mis-merge. (The first
occurrences had been updated over time, and the second ones not, but lets keep
the second ones, properly updated, as that matches the order in which the tools'
full descriptions appear further down below.)
Change-Id: I725105e926a5761c210c5901e00179ea9a1b6b5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132812
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...after the new types.rdb format that unoidl-write generates has been used
internally since LibreOffice 4.1 in 2013; following up on
6db34b6b33 "Directly build UNOIDL .rdb files from
.idl files" and its "The legacy tools idlc, regcompare, regmerge, and regview
are still contained in the URE or SDK for now."
The tools idlc and regmerge are deprecated but still shipped in the SDK for now.
The plan is to drop them completely for LO 7.5.
odk/examples/ and ure/source/uretest/ are adapted to use unoidl-write instead of
idlc and regmerge:
* unoidl-write does not use a C preprocessor and the # directives in .idl files,
it supports reading a single .idl file (containing an arbitrary number of
declarations) or a directory tree where each directory corresponds to a UNOIDL
module of the same name and each .idl file contains the declaration of the
(non-module) UNOIDL entity of the same name. For some of the odk/examples/,
that required moving individual .idl files into sub-directories named after
the respective modules. In odk/settings/std.mk, definitinos of IDL and
REGMERGE have been replaced with a new UNOIDLWRITE.
* unoidl-write always enforces reserved UNOIDL identifier restrictions (see
04af4e4f55 "[API CHANGE] Fix all bad UNOIDL
identifiers across offapi" and 6201792406
"Enforce the UNOIDL identifier scheme") (which idlc only enforced optionally
with -cid -we). That required renaming "my_module" in
odk/examples/DevelopersGuide/Components/CppComponent/.
* The new types.rdb format is not compatibly with LibreOffice < 4.1. Clients
generating extensions containing such files are advised to use appropriate
LibreOffice-minimal-version elements.
Change-Id: I1a248fd96e86ecbf407f829bc100d44bfe7f4e7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130533
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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 ae855bf481
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>
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>
Interfaces and services that are marked as "optional" in IDL are
deliberately tagged as "Protected" by doxygen, while everything else is
"Public", so that in the inheritance diagrams dashed lines are drawn
for "optional" bases and solid lines for non-optional bases.
Unfortunately this also causes doxygen to produce the text "Protected
Members", which appears hard to change, so just document it for now.
Change-Id: Ice878981bac5bbb7a8a33a10f2b5f68c394e4340
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
Xisco Fauli