<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Change user profile folder for 6.0" href="https://bugs.documentfoundation.org/show_bug.cgi?id=113783#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Change user profile folder for 6.0" href="https://bugs.documentfoundation.org/show_bug.cgi?id=113783">bug 113783</a> from <a class="email" href="mailto:philipz85@hotmail.com" title="Yousuf Philips (jay) <philipz85@hotmail.com>"> Yousuf Philips (jay)</a> <pre>(In reply to Thomas Lendo from <a href="show_bug.cgi?id=113783#c8">comment #8</a>) > 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 <a href="show_bug.cgi?id=113783#c9">comment #9</a>) > 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 <a class="bz_bug_link bz_status_NEW " title="NEW - CONFIGURATION: Sidebar customization settings not remembered after reopening" href="show_bug.cgi?id=67770#c37">bug 67770 comment 37</a>, 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. <a href="https://wiki.documentfoundation.org/UserProfile">https://wiki.documentfoundation.org/UserProfile</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>