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? _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
