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

[Zolnai Tamás]

Hi Stephan,

>> 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.)

Well, If we can't agree at least in that it takes more time to specify
the type explicitly in the Windows registry, than don't, then this
conversation might not lead anywhere. C++ language also has a type
deduction (e.g. auto), in spite of programmers must intimately know
what kind of objects they are using in the code.

>> 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.

I see. You are thinking in generalities. I would say, yes config
manager can't guess type in general, but it does not mean it can't
guess it in some usefull cases.

So to be more specific. We have an extensible group defined in
officecfg/registry/schema/org/openoffice/Office/Jobs.xcs called
"Arguments". Here there are no properties defined.
The actual properties are defined in
extensions/source/update/check/org/openoffice/Office/Jobs.xcu. Here
the properties are defined with a name and a type.
As I see this xcu file is converted to an xcd file placed in instdir
(onlineupdate.xcd). This xcd file is read by the config manager
and this allows to have a type hint. So type manager does not work
only based on the scheme file (which defines an extensible group wich
properties might have any type). Also the user need to know the actual
"implementation" of an extensible group (which is defined empty in the
scheme file).

It's true that scheme file does not specify the type of properties of
this extensible group, but also it does not specify the properties at
all. A property called "AutoDownloadEnabled" is defined only in the
onlineupdate.xcd (or Jobs.xcu) file which also defines the type of it.
So when a user finds this property in the LibreOffice configuration
files it clearly has a type. I don't think the property called
"AutoDownloadEnabled" can be set to a different typed value (e.g. via
registrymodification.xcu) without making LO behave unexpectedly. (code
handles this property as bool: see cui/source/options/optupdt.cxx).

Summary, you must be right in general, that configuration scheme files
does not allow to guess the type of such properties. I still think it
can be usefull for the users when an extensible group's properties are
well defined in an xcd file, but ok I see this kind of XCU files are
invalid (now that I saw the specification). So the problem is that we
are using this temporary xcu file for applying windows registry
settings. I will have a look at this problem.

Best Regards,
Tamás