... otherwise the unotools/source/config/configitem.cxx
ConfigItem::impl_packLocalizedProperties() checking for
(getValueTypeName() == "com.sun.star.uno.XInterface") would not
hit and thus not pack the properties, returning just the useless
XWeak pointer as property.
This in ScUnoAddInCollection::ReadConfiguration() lead to English
names not being extracted from configured Add-Ins' DisplayName or
CompatibilityName, nor any CompatibilityName added to the list.
Fallout from
commit bc70f674c2487ad826f8fe04e626de1829f5b40d
CommitDate: Sun Jun 18 08:41:27 2023 +0200
Use getXWeak in configmgr
Change-Id: Ibaab8c08a06113b27ceffe1c45ef548c1d6fa225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172476
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
UNO Services to Access the Configuration Database
Functional Overview
This code parses the settings that are described in the officecfg
directory, and provides a UNO API that code can use to set and get
settings.
Source Overview
configurationprovider.cxx
configurationregistry.cxx
defaultprovider.cxx
services.cxx
UNO service implementations.
access.cxx
childaccess.cxx
rootaccess.cxx
UNO objects passed to clients.
components.cxx
Central singleton that aggregates all data (reads in the XML files, manages modifications and global notifications).
groupnode.cxx
localizedpropertynode.cxx
localizedvaluenode.cxx
node.cxx
propertynode.cxx
setnode.cxx
Internal representations of data nodes.
parsemanager.cxx
parser.hxx
valueparser.cxx
xcdparser.cxx
xcsparser.cxx
xcuparser.cxx
xmldata.cxx
XML file reading.
modifications.cxx
writemodfile.cxx
Modification management.
broadcaster.cxx
Notification management.
additions.hxx
update.cxx
Extension manager interface.
data.cxx
lock.cxx
nodemap.cxx
partial.cxx
path.hxx
type.cxx
Utilities.
Some Implementation Notes
Mandatory Set Members
-
A set member can be marked as "mandatory," meaning that a member of that name must always be present in a set.
-
The above definition implies that calling replaceByName on a mandatory set member is OK.
-
The XCU format can contain
oor:mandatoryattributes on nodes. (The XCS format does not support them. In theregistrymodificationsfile,oor:mandatoryattributes should never be needed, as being mandatory cannot be controlled via the UNO API.) The XCU reading code only evaluates theoor:mandatoryattribute for set members, and ignores it everywhere else. -
Only true sets support mandatory members. A localized property for the "
*" locale, though acting much like a set, does not support mandatory members. -
The LibreOffice Registry Format document claims that group extension properties are implicitly mandatory, but at least the new configmgr code does not treat them like that (i.e., they can be removed again).
-
For simplicity,
setMandatory/getMandatoryare available as virtual functions at the baseNode, even though they can only make sense forGroupNodesand SetNodes that are set members. The defaultgetMandatoryimplementation returnsNO_LAYER, meaningoor:mandatoryis not set to true in any layer. (ReturningNO_LAYERsimplifies the code, e.g.,removeByNamedoes not have to check whethergetMandatoryis called on a member of a true set to decide whether to forbid removal.) -
When committing changes (made through the UNO API), the "mandatory" status of inserted nodes must be updated (in case the insert is due to a
replaceByName, or the "mandatory" flag was added by a concurrent modification of a lower layer). Also, for to-be-removed nodes, removal is ignored for (newly; due to concurrent modification of a lower layer) mandatory nodes (but still recorded inregistrymodifications, so may take effect once the lower layer addition is removed again---whether or not that is a good idea).
XcuParser Modification Recording
-
XcuParserrecords modifications when reading user layer data (valueParser_.getLayer() == Data::NO_LAYER). -
oor:finalized andoor:mandatoryattributes cannot be set via the UNO API, so it is assumed that user layer data does not contain them (for one, they are not written bywriteModFile; for another, the logic to record modifications expects alocprop(modify,fuse)to be followed by one or morevalue(fuse,remove), which would not necessarily be true if thelocprop` were only present in the user layer data to flag it as finalized). -
The logic to record modifications considers the top of the XML element stack. In the following list of all possible cases, items marked with an asterisk are recorded:
... group(modify,fuse) - group(modify,fuse) - ... ... group(modify,fuse) - set(modify,fuse) - ... ... group(modify,fuse) - *prop(modify,fuse,replace) - value(fuse) ... group(modify,fuse) - *prop(remove) ... group(modify,fuse) - locprop(modify,fuse) - *value(fuse) ... group(modify,fuse) - locprop(modify,fuse) - *value(remove) ... group(modify,fuse) - *locprop(replace) ... ... set(modify,fuse,replace) - group(modify/fuse) - ... ... set(modify,fuse,replace) - *group(replace/fuse) - ... ... set(modify,fuse,replace) - *group(remove) ... set(modify,fuse,replace) - set(modify/fuse) - ... ... set(modify,fuse,replace) - *set(replace/fuse) - ... ... set(modify,fuse,replace) - *set(remove) Legend: "...": zero or more further items "- ...": one or more further items "modify,fuse" etc.: any of those operations "modify/fuse": a modify or a fuse on an existing member "replace/fuse": a replace or a fuse on a non-existing member