Re: proposed patch: Bug 69609 - registrymodification.xcu in presets folder not implemented in newly created profiles.

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 
documented in 
<https://wiki.openoffice.org/wiki/Documentation/DevGuide/Config/Customizing_Configuration_Data>.

* 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.