Hi Stephan and everyone, Thanks for the clarification on the registry split. That cleared up the confusion I had around why `forName()` worked for types but failed for service names like `com.sun.star.frame.Desktop`.
I now understand that: - Components (services, singletons) are handled by the ServiceManager (cppuhelper/source/servicemanager.cxx) - UNOIDL entities (types, structs, enums) are handled by the TypeManager (cppuhelper/source/typemanager.cxx) So for the Object Browser, the data provider will query both systems: the ServiceManager for creatable components, and the TypeManager (via `theCoreReflection`) for types. Appreciate the precise pointers. This helps make the data pipeline design a lot clearer. On Wed, 25 Jun 2025 at 10:48, Stephan Bergmann < stephan.bergm...@allotropia.de> wrote: > On 6/20/25 10:05, Devansh Varshney wrote: > > *I have two question:*1. When .rdbfiles are loaded by LibreOffice > > Runtime, are their contents placed into a single, unified > > in-memory database, or do they maintain separation within that > > memory space? With older binary .rdbfiles, regmergewas used > > to consolidate data from separate .rdbfiles. > > Data about the two different kinds of .rdb files, one for component > (i.e., service and singleton) implementations (i.e., what is codified in > .component files) and one for UNOIDL entities (both types and non-types; > i.e., what is codified in .idl files), are kept distinct, see > cppuhelper/source/servicemanager.cxx for the former and > cppuhelper/source/typemanager.cxx for the latter. > > > 2. How can we programmatically distinguish a "service name" from an > > "interface name"? I know interfaces often start with 'X', but is there > > a more definitive method than just naming conventions? > > The css.reflection.TypeDescriptionManager service provides information > about all kinds of UNOIDL entities, both types and non-types (like > services and singletons). > -- *Regards,* *Devansh*
