D 2020-05-24T11:05:03.561 L OptionsDialog N text/x-markdown P 03bd79e5b4815acf448c94f65e5a3a20505bfbcb U mario W 5840 ### 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://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Checklist_for_Writing_Extensions](https://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Checklist_for_Writing_Extensions) * [https://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Options_Dialog](https://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Options_Dialog]) * [https://web.archive.org/web/20160101020749/https://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Saving_and_Reading_Data_for_the_Options_Page](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://github.com/vmiklos/lo-sdk-examples/tree/master/java/OptionsPageDemo](https://github.com/vmiklos/lo-sdk-examples/tree/master/java/OptionsPageDemo) * [https://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Adding_a_Leaf_to_an_Existing_Node](https://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Adding\_a\_Leaf\_to\_an\_Existing\_Node) * [https://github.com/kelsa-pi/unodit](https://github.com/kelsa-pi/unodit) * [https://github.com/p--q/OptionsDialog/tree/master/OptionsDialog/src](https://github.com/p--q/OptionsDialog/tree/master/OptionsDialog/src) * […/src/pythonpath/optionsdialog/component.py](https://github.com/p--q/OptionsDialog/blob/master/OptionsDialog/src/pythonpath/optionsdialog/component.py) * [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?t=96509) * [https://forum.openoffice.org/en/forum/viewtopic.php?p=92278 - (Solved) My addon's option dialog doesn't show up](https://forum.openoffice.org/en/forum/viewtopic.php?p=92278) → Pretty much the baseline version of what we're using here. Only the `__init__(,args)` parameter was invalid * [https://web.archive.org/web/20130801024954/http://wiki.openoffice.org/wiki/Documentation/DevGuide/Text/Editing_Text](https://web.archive.org/web/20130801024954/http://wiki.openoffice.org/wiki/Documentation/DevGuide/Text/Editing_Text) ### OptionsDialog.xcu The .xcu registers the dialog within one of the Configuration leaves. * Both the leaf `name=` and the `Id` property can be arbitrary. * It doesn't even have to be identical, but perhaps should show some resemblence to the package name still: pkg.vnd-name.OptionsPageTranslate * The .xdl reference in `` should use `%origin%` and perhaps be relative to the .xcu: %origin%/OptionsDialog.xdl * EventHandlerService registers a callback, which is meant to populate the dialog widgets or save data changes. pkg.vnd-name.OptionsHandlerImplId * The implementation identifier here can be arbitrary again, doesn't have to be `service:pyuno` URL, nor strictly match `Id` or the node leaf `name=` either. **Although it's perfectly fine to use the same ID for all three.** * It's 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 `getServiceNames()` etc. * **For testing**, you can define this property to be empty at first: ` ` So the dialog will at least show up in the configuration section, without actually doing anything. ### OptionsDialog.xdl The .xdl can be edited using LibreOffice > Tools > Manage Macros > Edit Dialogs.. * The ` (Not sure if that can be done in the Dialog editor.) * The `dlg:id="OptionsPageTranslate"` is arbitrary again. ### OptionsScheme.xcs 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".) Anyway, the `$nodepath` to access the registry later on would be a combination of `oor:package=`, the schema `oor:name=`, `Leaves`, and the ` Z 2c11c47c08f85b5525276c3146d580b5