Documentation for XStyleSettings supporting Getters?

[techsquirrel]

The following method works just fine to get a FontDescriptor for a Writer document’s ApplicationFont. However, I can find no documentation that supports getting the ApplicationFont using a getter, i.e. by calling xStyleSettings.getApplicationFont(). The XStyleSettings Interface Reference says nothing about such a method. The only indication that this is legit, aside from it working, is that the Eclipse IDE automatically displays a popup menu when typing the period following xStyleSettings that includes it as an option for selection in a long list of getters and setters.

protected FontDescriptor getAppFontDescriptor (XModel xDoc) {
    XStyleSettingsSupplier xStyleSettingsSupplier = UnoRuntime.queryInterface(XStyleSettingsSupplier.class, xDoc.getCurrentController().getFrame().getContainerWindow());
    XStyleSettings xStyleSettings = xStyleSettingsSupplier.getStyleSettings();
    return xStyleSettings.getApplicationFont();
}

This method is something I added three years ago to an extension I’ve recently started working on again. Unfortunately, I can’t remember where I got the method, whether I adapted it from some other code or blundered my way into getting it working on my own with the help of Eclipse. Since I’d like to avoid relying on an undocumented API feature, I’m forced to ask… Can anyone point me to some documentation to support the use of getters with XStyleSettings?

[techsquirrel]

OMG! I think I found documentation!

A search of (openoffice libreoffice) interface attribute getter setter on DDG turned up an item stating that each attribute of an UNO objects “is actually a pair of a getter method and a setter method (if the attribute is writable) or a getter method (if the attribute is read-only).” The page including the noted item cited the OOo Developer’s Guide as a reference.

Throughly reviewing attributes in the PDF version of the Developer’s Guide finds the following line on page 308 referring to UNOIDL interface specification: “During code generation in Java and C++, the attribute declaration leads to pairs of get and set methods.”

Soooo, by definition getters and setters are automagically generated for all attributes, and since ApplicationFont is an attribute provided by XStyleSettings, ApplicationFont must have a getter and a setter. Doesn’t exactly clear up the mystery of how I found it in the first place; but as long as it’s documented, I’m happy.

There’s an important cavaet to this, though. The LibreOffice API documentation refers to attributes ambiguously. So, to find out what’s really an attribute and what’s in fact a property (which, if I’m understanding correctly, require methods from an interface such as XPropertySet to access), it’s necessary to check the associated .idl file.

For example, documentation for the XStyleSettings interface and the Character Properties Service both claim to provide “Public Attributes”. Examining the .idl files finds that they’re not the same. XStyleSettings.idl indicates that they are really attributes. But CharacterProperties.idl shows that the “Public Attributes” are really properties, not attributes.

I have a feeling I’ll be examining more .idl files in the future.

[jimk]

The ApplicationFont attribute is shown at LibreOffice: XStyleSettings Interface Reference.

Not sure how specifically the get/set methods are implemented, but often when there’s an attribute in the UNO API, there are corresponding get/set methods, which seems to be the case here. There is an implementation for methods of that name in stylesettings.cxx in the source code, so maybe that is where it comes from.

When in doubt as to whether a get/set method is available, I rely on a code introspection tool such as MRI. The information that Eclipse is giving you seems reliable in this case.

[techsquirrel]

Ah yes… MRI. I was using MRI a lot at that time, so that’s most likely where I found it. Haven’t used it in a long while. Thanks for jogging my memory!

Incidentally, MRI has always been really unstable in my experience, often crashing and requiring LibreOffice restart. Is that a common experience?

[techsquirrel]

Unfortunately, after digging around in MRI and finding the XStyleSettings interface, I couldn’t find any indication that XStyleSettings provides a getApplicationFont() method.

[jimk]

@techsquirrel

MRI has always been really unstable

As with any extension, try resetting your LibreOffice user profile and see if that helps. Or you could try XrayTool.

@techsquirrel

I couldn’t find any indication that XStyleSettings provides a getApplicationFont() method.

You’re right, it doesn’t show up. It seems like the API isn’t fully declared, such as through an IDL file. However the documented behavior still works, so I’m not sure this would constitute a bug.

To be on the safe side, it may be better to access the property directly rather than using these hidden get/set methods.

[jimk]

In case you’re interested, here is the implementation from core/toolkit/source/awt/stylesettings.cxx:

FontDescriptor SAL_CALL WindowStyleSettings::getApplicationFont()
{
    StyleMethodGuard aGuard( *m_pData );
    return lcl_getStyleFont( *m_pData, &StyleSettings::GetAppFont );
}


void SAL_CALL WindowStyleSettings::setApplicationFont( const FontDescriptor& _applicationfont )
{
    StyleMethodGuard aGuard( *m_pData );
    lcl_setStyleFont( *m_pData, &StyleSettings::SetAppFont, &StyleSettings::GetAppFont, _applicationfont );
}

[jmux]

@techsquirrel

MRI has always been really unstable

FYI: LO gained a build-in XRay in 7.2, which should be more stable: https://wiki.documentfoundation.org/ReleaseNotes/7.2#Core_.2F_General

Didn’t test it yet.

[techsquirrel]

I’m only on 7.1.6 right now, but I’ll definitely look into it when 7.2 hits the Fedora Linux repo. Thanks!

[jimk]

Okay, I’m adding another answer after more research. This works in Python.

app = oStyleSettings.ApplicationFont

However, this code raises an AttributeError.

app = oStyleSettings.getApplicationFont()

There is a readme file at core/toolkit that states the following:

“Abstract” windowing thing, UNO implementations of windowing stuff so that it
can be used from Basic or Java.

It sounds like the hidden get/set methods are not part of the main UNO API.

getApplicationFont() doesn’t work from Basic either, so it seems that only Java is able to find the implementation.

Personally I would stick with the documented interface unless there is a reason not to do so.

[jmux]

In UNO interfaces / services can have attributes (or properties) and functions, like in LibreOffice: com/sun/star/awt/XStyleSettings.idl Source File. Depending on the target language bindings, these attributes either need explicit get/set functions or can be directly manipulated via introspection.

The Java IDL compiler generates function from the IDL file for attributes, while Python works with introspection to manipulate attributes, probably via the C++ equivalent of _dict_. For Python this results in the problem, that there is (or was?) no auto-completion in IDEs, because the is no Python code for an IDE to parse. And a C++ library must be build for each Python version, which is the reason LO ships it’s own Python, because the Python C API changes for minor version, so isn’t stable for a single library. For Java you need extra tooling and it generates larger libraries.

So the UNO API is the same, just the implementation is different.

[techsquirrel]

@jimk Seems consistent with the bit of documentation I dug up in the Dev Guide, which only indicates that getters and setters are generated in Java and C++. Good to know the diff in using Python. Thanks!