So, what have we learned?
There's a few gotchas when integrating a config dialog. Notably the lack of examples and spotty documentation made this somewhat tedious to figure out. Hence a few notes to the existing xml data and code in this project.
Some references / archive links:
- https://web.archive.org/web/20160101020749/https://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Saving_and_Reading_Data_for_the_Options_Page → the .xcs must be noted in the manifest.xml too
- https://forum.openoffice.org/en/forum/viewtopic.php?t=96509 - (Solved) OptionsDialog not showing up for Python Extension
- https://forum.openoffice.org/en/forum/viewtopic.php?p=92278 - (Solved) My addon's option dialog doesn't show up
→ Pretty much the baseline version of what we're using here. Only the
__init__(,args)parameter was invalid
The .xcu registers the dialog within one of the Configuration leaves.
Both the leaf
Idproperty can be arbitrary.
<node oor:name="pkg.vnd-name.OptionsPageTranslate.leaf" oor:op="fuse">
It doesn't even have to be identical, but perhaps should show some resemblence to the package name still:
The .xdl reference in
<prop OptionsPage>should use
%origin%and perhaps be relative to the .xcu:
<prop oor:name="OptionsPage"> <value>%origin%/OptionsDialog.xdl</value> </prop>
EventHandlerService registers a callback, which is meant to populate the dialog widgets or save data changes.
<prop oor:name="EventHandlerService"> <value>pkg.vnd-name.OptionsHandlerImplId</value> </prop>
The implementation identifier here can be arbitrary again, doesn't have to be
service:pyunoURL, nor strictly match
or the node leaf. Although it's for the best to use the same ID for all three. For Apache OpenOffice compatibility, the leaf name must match the handler ID however.
The EventServiceHandler string is used for the UNO handler registration:
g_ImplementationHelper.addImplementation( class, "pkg.vnd-name.OptionsHandlerImplId", () )
The service name
()list is likely redundant, because of the absurd number of stubs like
For testing, you can define this property to be empty at first:
<prop oor:name="EventHandlerService"> <value /> </prop>
So the dialog will at least show up in the configuration section, without actually doing anything.
The .xdl can be edited using LibreOffice > Tools > Manage Macros > Edit Dialogs..
<windowproperty for titlebars must be disabled however:
<dlg:window … dlg:withtitlebar="false">
(Not sure if that can be done in the Dialog editor.)
dlg:id="OptionsPageTranslate"is arbitrary again. (It probably doesn't need to match any of the .xcu identifiers: leaf/id/handler.)
Note that AOO might hiccup if the dialog is too large (>= 200x180px).
The component-scheme .xcs prepares entries and defaults for the Openoffice registry. It's somewhat redundant in declaring both names and storage types for a single registry tree. (The approach probably made sense for extensions that had multiple "leaves".)
$nodepath to access the registry later on would be a combination of
oor:package=, the schema
Leaves, and the
<group oor:name=…, e.g.
oor:name= group name ↓ ↓ /pkg.vnd-name.packageidentifier/OptionsSchema/Leaves/Settings ↑ ↑ package id "Leaves"
Must list both the dialog .xcu and the registry schema .xcs:
<manifest:file-entry manifest:media-type="application/vnd.sun.star.configuration-data" manifest:full-path="./OptionsDialog.xcu"/> <manifest:file-entry manifest:media-type="application/vnd.sun.star.configuration-schema" manifest:full-path="./OptionsSchema.xcs" />