proposed patch: Bug 69609 - registrymodification.xcu in presets folder not implemented in newly created profiles.
sbergman at redhat.com
Tue Dec 16 06:17:35 PST 2014
On 12/15/2014 02:15 PM, Justin Luth wrote:
> Debugging: How can you tell what your extension is doing? Nothing
> warns you if you have a spelling mistake, invalid XML. There is zero
> feedback anywhere - either you have it all right, or nothing happens.
The tragedy there is that the code reading configuration data
deliberately is very forgiving about malformed input. There was way too
much data out there in the wild with "irrelevant," malformed parts that
were skipped by the original configuration-reading code that the
rewritten-from-scratch configuration-reading code in the end needed to
painfully mimic that bad behavior.
What can help somewhat is to run a debug version of LO that prints
warnings to stderr.
> Inconsistent: layout of XML for /usr/lib/libreoffice/share/registry is
> very different from registrymodifications.xcu.
There are effectively three XML formats involved:
* The original .xcs/.xcu file format, to be used by extensions and
* The .xcd file format that simply packs multiple .xcs/.xcu files into
one large file, internally used by LO (for performance reasons).
* The alternative <items> scheme, internally used in LO's
registrymodifications.xcu (compared to the normal <component-data>
scheme for .xcu). It was invented to make programmatically writing
registrymodifications.xcu easier. It is an undocumented feature that
that format happens to work also in extensions' .xcu files, and if
there's demand it could be promoted to an official feature. (It is not
working within .xcd files due to trivial shortcomings, IIRC.)
> I'm not sure you can document well enough for this task. You almost
> need to build a customizing tool to create extensions if you want to
> limit yourselves to the extension approach, especially if you need to
> add support on how to "enforce" extension settings
> (?oor:finalized="true"?) overtop of user settings.
But the approach you propose does not address that problem, either.
Even worse, as your approach merges the "administrator settings" into
the user layer, you cannot enforce that those "administrator settings"
cannot be changed by the user. Even if you add oor:finalized="true",
that is effectively useless, as it only affects higher layers (of which
there are none), not the current layer itself.
More information about the LibreOffice