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

Hi Stephan,

So I think this conversation is heading somewhere. So two things I
have in my minds.

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)
Is there any specification of these configuration file formats in the meantime?
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.

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
work (specifying the type of a property), which can be handled by the
software itself (my change is about this). As I know software
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.

Best Regards,
Tamás

2017-03-07 10:30 GMT+01:00 Stephan Bergmann <sbergman@redhat.com>:
> On 03/07/2017 10:00 AM, Zolnai Tamás wrote:
> > > So coming back to <https://gerrit.libreoffice.org/#/c/34933/>, I'm not
> > > too
> > > excited about that hack.  It's a quick-fix to work around one specific
> > > shortcoming of the naive Windows registry mapping, but in a way that
> > > would
> > > require that hack to stay for backwards-compatibility reasons even
> > > when/if a
> > > more principled fix for that mapping is done.
> >
> >
> > What do you mean by that "would require that hack to stay for
> > backwards-compatibility reasons"? Why? Do you mean that if now we
>
>
> What I meant is:
>
> Encoding an extension prop in the Windows registry is not possible today
> (because the encoding lacks type information).  So a Windows registry
> instance containing an extension prop (necessarily lacking type information)
> is invalid input to LO.
>
> Gerrit 34933 makes valid certain such invalid inputs.  Users will rely on
> this by providing such inputs.
>
> And users will expect that such inputs remain valid in the future.  (Or
> would you be fine with incompatibly forbidding such inputs again in the
> future?)  Which implies that we'll need to keep the code from Gerrit 34933
> around.
>
> > handle a property without an explicit type (inside an extensible
> > group), than this will be required in the future too? As I see config
>
>
> Yes.  If we now give meaning to certain so-far invalid inputs, we'll
> probably need to continue to do so, see above.
>
> > manager works on the same way for other properties which are not
> > member of an extensible group. It's also an invalid thing, right? And
>
>
> I don't understand this part.
>
> > also the temporary xcu file is generated by LibreOffice, so I hope
> > nobody uses this temporarily generated xcu file as a template or
> > something like that.
>
>
> I'm not sure what the temporary xcu files have to do with this.
>
> > Also I think that principle fix you mentioned is not something which
> > would be allowed to push to a bugix branch, so I think it's better to
> > make it work, if users use it. Of course you are right on that this
> > windos registry handling can be improved.
>
>
> What's wrong with the approach of adding a "Type" key?  For its legal values
> use strings, either the "canonically namespace-prefixed" values (cf.
> officecfg/registry/component-update.dtd)
>
>   "oor:any", "xs:boolean", "xs:short", "xs:int", "xs:long", "xs:double",
> "xs:string", "xs:hexBinary", "oor:boolean-list", "oor:short-list",
> "oor:int-list", "oor:long-list", "oor:double-list", "oor:string-list",
> "oor:hexBinary-list"
>
> or the raw
>
>   "any", "boolean", "short", "int", "long", "double", "string", "hexBinary",
> "boolean-list", "short-list", "int-list", "long-list", "double-list",
> "string-list", "hexBinary-list"
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice