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

On 15/12/14 14:18, Noel Grandin wrote:
> Perhaps we need an official, bundled (but off by default) extension
> that performs this job?

An example extension won't be enough.  However, a config builder tool
could do the job.


1.)  Identifying the setting change difficulties:
-does a setting change modify multiple keys?  How do I know if the
change I am making is valid, and isn't missing a dependency?
-comparing before/after XML snapshots is not easy because XML keys can
move around a lot.   xmldiff can't handle big files.  (It was tedious
trying to isolate the settings I needed.)
-if I don't know English, how can I connect my "GUI Interface" setting
change with a change in the XML file?
-many settings may have been written to the user profile, just because I
visited one settings page - even if no changes were made.  That can make
it hard to isolate the relevant setting keys.

2.)  Finding the XML path
-In a huge XML file (like registrymodifications.xcu), it is not easy to
identify each node in the path.  My personal approach is to use firefox
and minimize each subsection as I go up.  Probably there is a better
way... but I don't know of it.
-hopefully most experienced sysadmins have a general knowledge of XML -
but I know that I have rarely needed it, so definitely I am rusty and
uncomfortable dealing with it.  Trying to write code to manage XML is
difficult and confusing for me.  (perl, xmlstarlet).  I know that we
aren't talking about coding here, but this is just to say that dealing
with XML is probably fairly foreign to sysadmins, and now to take chunks
of XML from the settings and altering those chunks to fit into an
extension might not be as easy for a sysadmin as programmers think that
it should be.

3.)  Packaging the extension
-it is a black box that only works if you have everything right.
-even the thought of writing an extension is a blocker.  It sounds like
a big deal - probably sounds bigger than it actually is.
-nothing is "cut and paste".  The root node is different in all three
XML files - system, extension, and user  (at least it is different in
our extension).  That's confusing and dis-orienting.  Extensions seem to
follow SYSTEM xml layout (change group to node) closer than user layout
- and yet we had to use the user's registrymodifications.xcu to identify
the changes.


So you can see there are a million things that could go wrong.  If you
get ONE of them wrong, then your extension simply won't do what you
want, but there is no feedback mechanism to give any hints as to what
that error might be.



SYSADMIN TOOL TO CREATE EXTENSIONS:
-read a registrymodifications.xcu file that the user has created.
-for every setting - checkmark to include in extension.   checkmark to
make mandatory (over-ride user settings).
    -group together at least at the first level to reduce the "noise".
    -search/filter/find
        -filter:  attach a comparison .xcu.  filter out any settings not
different between the two .xcu's
    -builtin list of common things to hide/exclude - like file
history.   Hidden by default, option to show all.
-output extension


This would eliminate a lot of the problems:
1.)  discoverable settings based in real time.  Generic enough to work
across different versions of LO.
2.)  easier to identify specific settings (any way to help non-English
speakers?) (any way to tap into LO rules about related settings?)
3.)  finding XML path / managing XML names will be a moot problem if the
tool takes care of all of that.  (but must be maintained: a place where
you need to take care of forward-compatibility)
4.)  packaging the extension should be easy for a tool (but must be
maintained).
5.)  testing portion would be nice, but I can't think of how that would
be possible in a tool.

Coding this would be WAY beyond me.