Revert "tdf#106283: Registry settings are not read properly on Windows"

[Stephan Bergmann]

On 03/07/2017 02:36 PM, Zolnai Tamás wrote:
> 1. From the users perspective (XCU user).
> What I see is that user can specify a property in an XCU file without
> a type if this proprty is not a member of an extensible group. This
> bug I'm trying to fix affects only that rare case when this property
> is a member of an extensible group. So my first question is that is
> this validity concern is only related to that corner case when a
> property is a member of an extensible group? Are other kind of
> properties OK if they are used without a type in an XCU file? (I'm
> speaking such xcu files which are merged with other LO configuration
> files (e.g. registrymodification.xcu) and so type is known)

Yes, for xcu prop elements the oor:type attribute is implied.  It 
normally is implied to be the same as the oor:type attribute defined for 
the corresponding schema (xcs) prop element.  Only if the prop is 
defined to be of type oor:any (which is in particular the case for such 
extension props) it must provide an oor:type attribute in xcu.

> Is there any specification of these configuration file formats in the meantime?

See the original OOo specification at 
<http://web.archive.org/web/20101103025920/http://util.openoffice.org/common/configuration/oor-document-format.html> 
that I mentioned earlier, and see the officecfg/registry/*.dtd files.

> Other question is that from the user perspective what the difference
> between these two kind of properties? (member of an extensible group
> or not a member of an extensible group). As a user should I handle
> these two kind of properties on a different way? Actually as a user I
> would focus on the information that both are properties, both can be
> set via Windows registry and I would not care about the
> implementation. So I think if allowing this "invalid input" makes
> users' every day life easier then I think we should step on this
> direction and make this invalid input a valid input.

When you provide such configuration data via the Windows registry, you 
apparently need to intimately know the corresponding xcs schema, just as 
if you provide such configuration data via an .xcu file (via an .oxt 
extension that you wrote, say).  And yes, users who provide such 
configuration data are apparently expected to know what information they 
need to provide for an extension prop.  (Typical end users are not the 
target audience for manually constructed configuration data anyway. 
"Tools - Options... - LibreOffice - Advanced - Open Expert 
Configuration" is the most they're supposed to be exposed to.)

And, in general, there is no way to make invalid input of an extension 
prop value lacking a type valid.  Only if that prop happens to already 
be set by a lower layer could you guess that this instance shall have 
the same type (or not) as the previous one.

> 2. About your idea how to fix it in windows registry handler code.
> I hope I understand your words well. So you suggest to have a third
> entry for Windows registry keys which specifies the type. For the
> first thought it was a good idea, as you sad it would be easy to
> implement. However on the second thought, It was not. LO config
> manager knows the type of a configuration property, it can search the
> type of a property in LO configuration files. I think this type
> deduction or type detection is a function of config manager and not a
> bug or a hack. Your suggestion means that we add the users some extra

No, there's no extra work we burden on the user.  A prop of type oor:any 
(which extension props implicitly are) can take on values of different 
types at different times.  Whenever you specify the value of such a 
prop, you also need to specify the type.

(Claiming that this is adding extra burden on the user is a bit like 
claiming that it is extra burden that e.g. for a boolean prop you need 
to specify the value "false" explicitly, instead of guessing that if no 
value is specified then "false" should be implied.)

> work (specifying the type of a property), which can be handled by the
> software itself (my change is about this). As I know software

No, again, the software cannot guess the missing type in general.  See 
above.

> development used to work on the oposite direction with the aim of
> making users life easier, make them get the same result with less
> effort, right? So that's why I don't think it's a good idea what you
> suggest.