https://bugs.freedesktop.org/show_bug.cgi?id=57061
Stephan Bergmann <sberg...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|sberg...@redhat.com |libreoffice-b...@lists.free
| |desktop.org
Summary|No personal data imported |Not all personal data
|(or moved) during install |imported during install
|from /3 User Profile |from /3 User Profile
Version|4.0.0.0.alpha0+ Master |4.0.0.3 rc
--- Comment #27 from Stephan Bergmann <sberg...@redhat.com> ---
In reply to comment 24 and comment 26:
In general, what parts of an old user profile are migrated is controlled by
configuration settings in the /org.openoffice.Setup/Migration tree (see
officecfg/registry/data/org/openoffice/Setup.xcu). The data that is present
there is apparently mostly what had been there for the migration from OOo 2 to
OOo 3 already. The reason why certain parts of a user profile had been
excluded from migration back than are probably lost to history.
Note that this user profile migration code already kicked in on Linux during
the LO 3 timeframe, when
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=9276f7d5740a28b342db2a9bcd8644ff2f4f5742>
"fdo#32263" moved the location of the user profile from ~/.libreoffice/3 to
~/.config/libreoffice/3 and
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b522673373797bbf53d795d53e0ec45175a5d67>
"default config location has changed, look in old config dir when migrating"
enabled LO's migration code to migrate from an existing ~/.libreoffice/3 to a
new ~/.config/libreoffice/3.
Therefore, at least my assumption would have been that that migration worked
acceptably, or else (Linux) users would already have complained when upgrading
from old LO 3 versions (that used ~/.libreoffice/3) to newer LO 3 versions
(that used ~/.config/libreoffice/3) about settings getting lost. However,
re-checking that now, things like the list of recently used documents indeed
were not migrated back then, either. Apparently nobody looked at the migration
machinery in detail, whether it works acceptably for migrating individual
settings to a new LO 4 user profile.
Addressing specific items from the above comments:
* List of recently used documents: This apparently manifests itself in
configuration items (in the user profile's user/registrymodifications.xcu) in
the /org.openoffice.Office.Histories tree, which is not included in the
migrated data. Whether there ever was or still is any good (technical) reason
for that I do not know offhand.
* Window sizes: These apparently manifest themselves in configuration items
(in the user profile's user/registrymodifications.xcu) in the
/org.openofice.Office.Views tree, which is not included in the migrated data.
Again, wheter there ever was or still is any good (technical) reason for that I
do not know offhand, but the odd format in which this data is saved makes it
not unlikely that this was considered too fragile for migration at least in the
past.
* Autotexts: These apparently manifest themselves as files in the
user/autotext/ directory, which explicitly are migrated (cf. ".*/autotext/.*"
listed in
/org.openoffice.Setup/Migration/SupportedVersions['OpenOffice.org3+OpenOffice.org2+StarOffice8+StarSuite8+Libreoffice3']/MigrationSteps['Common']/IncludedFiles
in officecfg/registry/data/org/openoffice/Setup.xcu), and indeed an existing
~/.config/libreoffice/3/user/autotext/mytexts.bau is copied to
~/.config/libreoffice/4/user/autotext/mytexts.bau and works fine in LO 4 at
least when I try that out with my local master build on Linux. So this needs
further verification.
* View - Toolbars - Drawing: This apparently manifests itself in configuration
items (in the user profile's user/registrymodifications.xcu) in the
/org.openoffice.Office.UI.WriterWindowState tree, which is not included in the
migrated data. Again, wheter there ever was or still is any good (technical)
reason for that I do not know offhand, but, again, the format in which this
data is saved makes it not unlikely that this was considered too fragile for
migration at least in the past.
* context menu on toolbar Standard > Visible Buttons > New Document From
Template: This apparently manifests itself in the file
user/config/soffice.cfg/modules/swriter/toolbar/standardbar.xml. The migration
data mentioned above lists
".*/config/soffice.cfg/modules/.*/toolbar/custom.*\.xml", but that apparently
does not match this file, so it is not copied. What's the story there I do not
know.
* Tools > Customize... > Menus: This apparently manifests itself in the file
user/config/soffice.cfg/modules/swriter/menubar/menubar.xml, which is not
included in the migrated data. Again, what's the story there I do not know.
* "Is it not the easiest way just to copy (or rename?) the /3 user profile to a
new /4 profile, if LO does not find a /4 profile at start?" While most of the
old data could indeed be reused, a new major release is generally considered a
good point in time for incompatible changes in user profile data, thus
demanding more sophisticated migration than wholesale copy/rename. There is at
least some changes (like changing bundled extensions into core parts, and
changing the database format for information about installed extensions) that
benefited from this for LO 4.
* "The files 'MIGRATED' or 'MIGRATED4' are just confusing. As I understood they
are necessary for development." No, see
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=995a87e5cf63fe1626245b62fef4aa71fa02dc94>
"disable multiple migrations via MIGRATED stamp file" for the reason the
MIGRATED file got introduced. Having said that, I personally think that design
is flawed, and we best get rid of those flag files again; I have that on my
to-do list.
* "Does someone know if there is a forward compatibility of LO 3.6.x to /4 user
profiles if they are renamed to /3?" There is no guarantee for that to work.
If it works, it works by chance, not by design.
--
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
