It looks like the documentation for bExact was just an accidental copy
and paste of the aName param. This changes it to explain what it does
based on looking at the code for the implementation.
Change-Id: Ia767064c66b2125193c75da34273a6d4e6035bd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201453
Reviewed-by: Neil Roberts <bpeeluk@yahoo.co.uk>
Tested-by: Jenkins
A bunch of places in the documentation in the IDL files were starting a
new paragraph with a <p> tag and a line that is more indented than the
previous one. This ends up making a preformatted code section in a
monospace font in the generated HTML docs and the <p> tag is visible.
This patch just moves the lines to the left to have the same indentation
as the previous one. These were found by running the following Python
script on the generated HTML files:
from bs4 import BeautifulSoup
import sys
for filename in sys.argv[1:]:
with open(filename) as fp:
soup = BeautifulSoup(fp, 'html.parser')
for pre in soup.find_all("pre", class_="fragment"):
if pre.string.find("<p>") != -1:
print(f"{filename}:{pre.sourceline}:"
f"{str(pre).split('\n')[0]}")
Change-Id: If351a5be24b21b24a4d7892a9185353e8691feb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201134
Tested-by: Jenkins
Reviewed-by: Neil Roberts <bpeeluk@yahoo.co.uk>
.../master/instdir/sdk/bin/unoidl-read --published \
.../libreoffice-25.8.0.4/instdir/program/types.rdb \
>.../master/udkapi/type_reference/udkapi.idl
* css.lang.XSingleServiceFactory has been un-deprecated with
4f03d1c238 "css.lang.XSingleServiceFactory must
not be @deprecated"
.../master/instdir/sdk/bin/unoidl-read --published \
.../libreoffice-25.8.0.4/instdir/program/types.rdb \
.../libreoffice-25.8.0.4/instdir/program/types/offapi.rdb \
>.../master/offapi/type_reference/offapi.idl
* css.i18n.GROUP_SEPARATOR_IN_NUMBER_3 is marked as "@since LibreOffice 25.2"
but was only brought into libreoffice-25-2 with
055b637ed9bdd02cd857664813a66afde51dfd0a "tdf#158867 offapi,i18npool,starmath:
fix ',' in Math again" after libreoffice-25.2.0.3, for which point the
previous type reference had been generated with
aabf7c44ec "Update the reference rdbs to
libreoffice-25.2.0.3"
Change-Id: I387e20b3bc5955b60b8365f6a64604481f2e0de2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190155
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...which caused cppumaker to emit the corresponding C++ class as
SAL_DEPRECATED_INTERNAL (since 44ea5d1414 "Adding
SAL_DEPRECATED_INTERNAL to an implementation function is pointless"), which
caused compilers to emit warnings upon its legitimate uses in external
!LIBO_INTERNAL_ONLY code
Change-Id: I8043506cd11658164e68f8743702acbc1a8213f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182832
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
As UNO exceptions are not derived from std::exception in C++, the corresponding
JS object's name property is present but has undefined value. And the UNO
Message property is not present at all.
Change-Id: Ibe152377e5970faa8a518c77b5171d9f3c160f38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165885
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...which should be rare enough in practical use that it should be sufficient to
only have toString-functionality for instances mapped from C++ to JS, but no
constructor for new instances on the JS side. (The natural choice for the
latter would be a mapping of the C++
> inline Type( TypeClass eTypeClass, const ::rtl::OUString & rTypeName );
constructor, but which requires a mapping for the css::uno::TypeClass UNOIDL
enum, which is only provided "later" through CustomTarget_static/unoembind, so
would at least conceptually be a bit dirty.)
This Embind mapping treats css::uno::Type as a smart pointer for the underlying
typelib_TypeDescriptionReference, to benefit from the fallback garbage
collection (in more recent Emscripten versions, at least) for smart pointers,
obviating the need to call .delete() on each instance mapped to JS.
Change-Id: Ic113967c264c28641dfd1fe159012c85519f4a9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164140
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
The constants are only reflected directly as JS values in the generated *.js
file. Reflecting them via emscripten::constant in the generated *.cxx did not
work well: Most importantly, emscripten::constant (and its underlying
_embind_register_constant) coerce all values to double, so UNO (unsigned) hyper
would not survive as JS BigInt, which would then cause e.g.
> console.assert(test.isHyper(uno.org.libreoffice.embindtest.Constants.Hyper));
passing such a (JS number, not BigInt) value into the
org.libreoffice.embindtest.XTest::isHyper method (which expects a UNO hyper) to
fail. (Also, constants of UNO boolean type would be represented as numbers 0/1
rather than as false/true.)
Change-Id: I056db0ccce0bf40eb53728fd439cc74964eb6951
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164097
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
80d3f33876 "Library_embindtest should use
comprehensive InternalUnoApi_embindtest" was an attempt at making type
information about that library available at runtime. Which worked for cases
where code directly called one of the types' cppu_detail_getUnoType function.
But it would still fail for cases where code indirectly wants to obtain one of
the types' information by type name---which is what upcoming code will do that
changes the Embind'ing of UNO sequences.
So InternalUnoApi_embindtest would need to become a UnoApi_embindtest whose
instdir/program/types/embindtest.rdb would be available at runtime. But I'm too
dumb to convince gbuild to create that new UnoApi_embindtest. So instead just
tack the embindtest UNOIDL entities onto the existing UnoApi_udkapi for the
EMSCRIPTEN-ENABLE_DBGUTIL case. (Which requires that the single embindtest.idl
is split into individual per-entity files, sigh.)
Change-Id: Ie189b17213ac5b2de7a61ac5f97a143fa097337f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...and revert e1c6f36d8b "Add a to_string()
function to the code generated for UNO IDL constant groups". (But keep the
constants groups the latter had added to cppu/qa/cppumaker/types.idl, and use
them in the newly added CppunitTest_stoc_dump, for better or worse.)
Change-Id: I56e9eaeb1e45b83a72a25eceef13e719dc6f3a1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149281
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins
...which were used by ildc, which is gone since
a8485d558f "[API CHANGE] Remove deprecated idlc
and regmerge from the SDK", and have always been ignored as legacy by its
unoidl-write replacement.
This change has been carried out (making use of GNU sed extensions) with
> for i in $(git ls-files \*.idl); do sed -i -z -E -e 's/\n\n((#[^\n]*\n)+\n)*(#[^\n]*\n)+\n?/\n\n/g' -e 's/\n(#[^\n]*\n)+/\n/g' "$i"; done && git checkout extensions/source/activex/so_activex.idl odk/examples/OLE/activex/so_activex.idl
which apparently happened to do the work. (The final two files are not UNOIDL
source files.)
Change-Id: Ic9369e05d46e8f7e8a304ab01740b171b92335cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and let its implementations just throw a RuntimeException, now that regmerge
has been removed in "[API CHANGE] Remove deprecated idlc and regmerge from the
SDK". Deprecate css.registry.MergeConflictException along with it (though
stoc/source/implementationregistration/ still uses it internally). And remove
the previously unused include/registry/writer.hxx along with the newly unused
include/registry/writer.h, RegistryTypeWriter, and RegistryTypeReader.
Change-Id: I10fd286617975dc0ef9f74460a3a3eab8060939d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123615
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* 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>
SIL has restructured their site, and ISO either moves things
around or doesn't make them available at all. For 3166 use
Wikipedia if ISO doesn't want to be a reference..
Change-Id: I2f906376c081667f57d48fa0386015a90857aae5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126689
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
It had been present ever since at least 88c437c597
"moved from api" from 2000, but was apparently never implemented nor used at
least in OOo/LO itself. It is problematic as it uses reserved identifiers
("getDisplayLanguage_Default" etc.) that contain underscores and start with a
lowercase letter, and a planned change to unoidl-write will no longer tolerate
usage of such reserved identifiers (see the TODO in
unoidl/source/sourceprovider-scanner.l).
Change-Id: I76a3a3da7b7c1f4c109ca7a12c9f07857ca1be1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123544
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
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>
...which obsoleted RFC 2396. Notable changes are that the distinction between
hierarchical and opaque URIs has been dropped, and that the relative URI
resolution specification has been made more rigid.
As a consequence, various features of css.uri entities have changed:
* XUriReference.isHierarchical is obsolete and deprecated.
* The behavior of XUriReference.hasAuthority, XUriReference.getAuthority,
XUriReference.getPath, XUriReference.hasRelativePath,
XUriReference.getPathSegmentCount, XUriReference.getPathSegment,
XUriReference.hasQuery, and XUriReference.getQuery has been made consistent
for all URIs, no matter whether they were considered hierarchical or opaque in
the past.
* The behavior of XUriReferenceFactory.makeAbsolute and
XUriReferenceFactory.makeRelative has been changed to match the RFC 3986
reference resolution specification. The XUriReferenceFactory.makeAbsolulte
parameter processSpecialBaseSegments has been renamed to
processAdditionalSpecialSegments, as per the updated specification it now
controls treatment of special segments in the given uriReference, in addition
to special segments in the given baseUriReference. (Renaming UNOIDL interface
method parameters is technically an incompatible change, but the benefits of
improved clarity presumably outweigh any potential drawbacks in this case.)
The implementation in stoc has been adapted, and various call sites have been
adapted to the deprecated XUriReference.isHierarchical semantics.
Change-Id: Ic6e00fdbce5abef70d75ec2f753d22fefe361457
Reviewed-on: https://gerrit.libreoffice.org/77861
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Andrea Gelmini