As noted in <https://gerrit.libreoffice.org/c/core/+/142454/3#message-18fe8bb36fc24d317ad16dd25e236ed51c88a910>, introducing a dedicated css.text.ContentControls service is actually not needed and client code should be fine with just an "anonymous" object returned by getContentControls() + implementing XIndexAccess. Remove it before somebody starts to depend on it. Let's rather have a bit of inconsistency (e.g. SwXFootnotes implements XServiceInfo, while SwXContentControls not) than an XServiceInfo implementation that we'll have to support from now on, without a user. Change-Id: Ifde4fb6bcafdffabb189447415b89b01c9675296 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142511 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
LibreOffice API IDL Files Except UDK API
Contains all of the IDL files except those in udkapi.
i.e. the interfaces that are specific to the LibreOffice application. An artificial (?) separation.
The reference offapi/type_reference/offapi.idl and
udkapi/type_reference/udkapi.idl (formerly combined into a single
offapi/type_reference/types.rdb) are used to detect inadvertent incompatible
changes. They are plain-text .idl files (not strictly lexicographically sorted,
though, so they satisfy the .idl file requirements for no forward dependencies),
so in cases where we deliberately /do/ become incompatible they can be modified
manually.
Old such cases of deliberately becoming incompatible are listed in
offapi/type_reference/typelibrary_history.txt, newer such cases are recorded in
the git logs of (now superseded) offapi/type_reference/types.rdb,
offapi/type_reference/offapi.rdb, and udkapi/type_reference/udkapi.rdb, new such
cases are recorded in the git logs of offapi/type_reference/offapi.idl and
udkapi/type_reference/udkapi.idl.