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