GSoC 25: BASIC IDE - Insights from Data Discovery & C++ PoCs [WEEK 4]

[Devansh Varshney]

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.bergmann at 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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20250628/a433680d/attachment.htm>