[Libreoffice-bugs] [Bug 113783] Change user profile folder for 6.0

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=113783

--- Comment #10 from Yousuf Philips (jay) <philipz85 at hotmail.com> ---
(In reply to Thomas Lendo from comment #8)
> Is this a realistic use case? People have LibO 4.x and LibO 5.x installed in
> parallel and want use different profile preferences?

With the way LO behaves and how the user profile can constantly get corrupted,
i could easily see careful individuals who would want to evaluate a new version
before upgrading and still have their old preferences intact, would definitely
want separate user profiles, even between point releases like 5.1.x and 5.2.x.

> Master build uses its own profile directory LibreOfficeDev/number which also
> could be moved to for example LibreOffice/DevNumber.

Yes development builds have a separate directory, but even development builds
of 5.3, 5.4 and 6.0 will use the same profile directory.

(In reply to Michael Meeks from comment #9)
> Discarding users' customization as they upgrade seems really unfortunate.

Wouldnt call it discarding, as that sounds more like it was removed, it isnt
being migrated during the upgrade.

> The ESC discussed this last week, and are unconvinced by a number change
> here - we deliberately didn't do this in the past to avoid issues here.
> Ultimately if a user has not configured some part of the UI, or eg.
> table-styles in general they should not have a hard-coded configuration for
> that in their config directory - so, they should see the new changes eg.
> toolbar re-org. Those who did take the time to configure things as they want
> them will not be disrupted.

Table Style: when a new user profile is created, it copies the autoformat table
styles file to ~/.config/libreoffice/4/user/config/autotbl.fmt and once it is
there, upgrading to a build which has the new table styles introduced in bug
101349 will not be seen by the user. Even deleting the autotbl.fmt will not
cause the new version to be placed in its place.

Toolbar: some users do alot of customization to the toolbar and some to basic
stuff like disable/enable/add a single command, and for such users who did so
in versions before 4.4 with a profile imported from an older version would see
none of the improvements made to that particular toolbar. In Impress we also
changed the entire layout of the toolbars and changed some toolbars from
contextual to not contextual and when coming from an older version before 5.0,
they wont see this new layout, and someone did file a bug about this issue, not
that they couldnt see the new layout, but that the behaviour had messed up for
their old layout, and our solution, wait for it - reset your profile.

Sidebar: the user didnt customize anything here other than using the sidebar
and its behaviour has been riddled with settings that are being saved into the
user profile since 5.1 or so that are causing the sidebar to misbehavior even
when a fix is done, and as bubli said in bug 67770 comment 37, the only remedy
for users is to reset the user interface modifications to the user profile.

> There are a load of potential ways to fix and improve this code, and/or to
> detect a one-off upgrade and allow the user to choose to use the 'new' stuff
> for whatever areas they configured - but they all involve real coding work,
> and rather unpleasant testing (AFAIR our unit tests for migration code
> are/were very poor indeed).

Unfortunately this was the same response from the ESC when i suggested the same
thing when we moved from 4.4 to 5.0 in mid 2015 and nothing has changed and
users are still being harmed by these UI issue and other corruptions in the
user profile. We can provide users who want to use their old user profile
simple steps on how to use their old profile, just like we provide simple steps
for users to reset their profile.

https://wiki.documentfoundation.org/UserProfile

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20171115/6f0c90a4/attachment-0001.html>