https://bugs.freedesktop.org/show_bug.cgi?id=52022
Stephan Bergmann <sberg...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|libreoffice-b...@lists.free |sberg...@redhat.com
|desktop.org |
--- Comment #23 from Stephan Bergmann <sberg...@redhat.com> ---
This is due to an unfortunate chain of things:
1 For LO 3.5, ec4f69493b50c15861b0cdcc290ecedd00efb51d "removed Simple Handles
option" and 6ea8ea456cf5df267284278ecda42aa9b089a682 "Remove Large Handles
option" remove use of some SimpleControlPoints and LargeControlPoints
configuration properties. However, the way those changes are made in
sw/source/ui/config/usrpref.cxx, SwLayoutViewConfig::Commit when called will
write nil values for those properties into user/registrymodifications.xcu.
(Only bbd638350fb83af2cadd85cdac2900de80bf7401 "remove gaps in options and
reduce by two" later fixed that for LO 3.6.)
2 For LO 3.6, e8bb827571f540ac4af2247cb11239bb96876669 "Fixed cppheader.xsl
nillable treatment" changes the nil-ability of many configuration properties
that should never be nil in practice (i.e., their schemas already supply a
non-nil default value) from the poorly chosen default "nil-able" to "not
nil-able," as that makes using the newly introduced autogenerated C++
configuration access code less error-prone.
3 When configmgr reads an xcu file and reads a nil value for a property that
cannot be nil, it abandons reading that file, effectively ignoring the rest of
the file's data.
4 Whether a user/ directory has already been populated with default files is
controlled by configuration property
/org.openoffice.Setup/Office/ooSetupInstCompleted. If that property is not
true, LO will copy files from presets/ to user/, even overwriting already
existing files (and then set the property to true in
user/registrymodifications.xcu; as items are listed lexicographically in
user/registrymodifications.xcu, /org.openoffice.Setup/... comes near the end,
after all the /org.openoffice.Office/... stuff).
5 Now, if (1) has ever caused a LO 3.5 user/registrymodifications.xcu to
contain nil values for those Simple/LargeControlPoints, migration to LO 3.6
will cause LO to stop reading user/registrymodifications.xcu once it sees such
a nil value. This means that LO does not read the value "true" for
ooSetupInstCompleted, thinks the user/ directory has not yet been populated,
and overwrites various existing files in user/ with defaults from presets/.
The quickest fix is to make those Simple/LargeControlPoints properties (which
are no longer used anyway) nil-able again.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
