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>
...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>
...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>
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>
...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>
Translates leftovers found using a custom regex.
Additionally:
- A few spelling fixes
Change-Id: I3772e1b914acc487d80ab14efb815cb178ca3dcb
Reviewed-on: https://gerrit.libreoffice.org/41831
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
* 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
Andrea Gelmini