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

When my co-worker wrote the extension on Feb 4, he said:  " I think it
now meets the "standards" for writing an extension.  But it was a long
hard path to get there: like stabbing in the dark."  "After much pain
and scant documentation, and a lot of trial and error (MOSTLY error) I
think it is working."  (I can't find the "by luck" statement anymore -
basically it means he didn't understand what he did to finally get it
working, and he couldn't offer me any advice when I failed later on.)

Prior to the extension, I had already identified the XML paths, and
wrote DOS and Linux scripts using xmlstarlet to adjust the system
setting files in /usr/lib/libreoffice/share/registry, so we already had
done a lot of the legwork to identify the XML stuff. XMLStarlet worked
fine for Windows, where we manually installed updates, and so could
re-run our script after each install when the system registry config was
replaced by the installer, but that approach doesn't work under Linux,
so we were forced to get extensions working.  So, our extension
struggles came after all of the config/XML basics were already
understood.  All we needed to do was simply repackage our knowledge into
an extension.

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.
How do you even find the setting name and the XML path?  What happens if
you don't know English, and you only know the setting name from your own
language's interface?  "July 14: tried to add “onlineupdate.xcu” to the
extension to disable automatic updates for windows computers. Failed
miserably. I hate LibreOffice's useless, inconsistent deployment
configuration and lack of documentation."   Quite honestly, I'm not sure
what my problem was on July 14 - perhaps the setting was already in my
own .xcu and so wasn't over-written by an extension.  Otherwise it was
simply an error in my thinking or coding. When I tried again on Nov 22,
it just worked immediately.

Inconsistent:  layout of XML for /usr/lib/libreoffice/share/registry is
very different from registrymodifications.xcu.
lack of documentation:  I had reviewed what documentation I could,
including Thorsten's LibreOffice configuration management.odp (which I
didn't really understand), and even tried his ooconfig - which didn't
work at all for me.

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.  I like to pretend
I'm a pretty good sysadmin, but the kind of effort required to dive into
the guts of LO just to do basic, automated user profile management is
way too much, and most sysadmins will bail out early like I did.  That's
why I'm really pushing this issue - especially since with very little
coding I think can show that it can be so much simpler and elegant.  All
the pieces were already in place - it only needed to be tied together.

Configuration extensions are fine for governments, and big corporation's
who can have a LO expert learn it all, but for the hundred's of small
sysadmins who have to do everything on their own, something else is needed.



On 15/12/14 14:18, Noel Grandin wrote:
> On 2014-12-15 12:37 PM, Stephan Bergmann wrote:
> > An alternative would be to make it easier for the target audience to
> > achieve their goals with extensions.  That could
> > include better documentation and examples.  What were the problems
> > you encountered when trying it (what was your
> > co-workers "by luck" thing, and what was the problem adding an
> > additional change to the existing extension)?
>
> Perhaps we need an official, bundled (but off by default) extension
> that performs this job?