With users who are upgrading from earlier versions of LO, they may not see various improvements in the UI or behaviour as these settings are stored in the user profile, like * Toolbar reorganization and positioning (LO 4.4) * Menu reorganization (LO 5.1) * Sidebar content panel correct state (LO 5.1) * Sidebar remembering which deck was opened on closing (LO 6.0) (bug 67770) So the suggestion is to change the user profile folder from ~/.config/libreoffice/4/ to ~/.config/libreoffice/6/, so users get a clean slate and arent plagued by user profile issues since we changed from /3/ to /4/ in 2013.
Simple changing the path is not enough. You need at least a migration tool for macros and user colors.
(In reply to Regina Henschel from comment #1) > Simple changing the path is not enough. You need at least a migration tool > for macros and user colors. I dont think we 'need' to have such a tool for this change, though it would be nice if we did, as we dont have such a tool for users moving from OOo/AOO to LO and we didnt create such a tool when we changed the folder from /3/ to /4/.
A change in profile path from "LibreOffice 4" to "LibreOffice 6" or even just to "LibreOffice" is appropriate. On Windows builds we've adjusted the installation folder now to just LibreOffice bug 62303, but had kept the 'UserInstallation' set with " 4" appended to PRODUCTNAME for the user profile, retaining any old sludge. [1] Personally, I've never had qualms about forcing users onto a new profile. Users should be responsible for migrating their customizations. Yes, we could offer script help for that with that on first launch, to include for the bundled shared extensions. But only if they choose so at first launch, otherwise just steer them to new default profiles we know will work. But moving macros is troubling, we could copy them over but beyond that no obligation to fix anything. Other extensions should be reinstalled--no apologies. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/instsetoo_native/CustomTarget_setup.mk#43
(In reply to V Stuart Foote from comment #3) > A change in profile path from "LibreOffice 4" to "LibreOffice 6" or even > just to "LibreOffice" is appropriate. > Umm, make those "LibreOffice/4" and "LibreOffice/6" as it is a directory holding the profile, not the directory name.
User colors are a new problem compared to change from 3 to 4, because now the user colors are in the registrymodifications.xcu. Formerly the colors were in a palette and the user only needs to move the palette.
If you don't wanna rename the profile dir as 'libreoffice', why not rename it to 'libreoffice/LO' or 'libreoffice/libreoffice'. That way you never have to change the name/number again. Else you have the same prob again with LO v7 / v8 / etc...
(In reply to MM from comment #6) > If you don't wanna rename the profile dir as 'libreoffice', why not rename > it to 'libreoffice/LO' or 'libreoffice/libreoffice'. That way you never have > to change the name/number again. Else you have the same prob again with LO > v7 / v8 / etc... Users can have multiple versions of LibreOffice installed, so having them all use the same profile directory would be bad, which is why changing the profile directory per new version (7.x, 8.x, etc) is a good idea.
(In reply to Yousuf Philips (jay) from comment #7) > (In reply to MM from comment #6) > > If you don't wanna rename the profile dir as 'libreoffice', why not rename > > it to 'libreoffice/LO' or 'libreoffice/libreoffice'. That way you never have > > to change the name/number again. Else you have the same prob again with LO > > v7 / v8 / etc... > Users can have multiple versions of LibreOffice installed, so having them > all use the same profile directory would be bad, which is why changing the > profile directory per new version (7.x, 8.x, etc) is a good idea. Is this a realistic use case? People have LibO 4.x and LibO 5.x installed in parallel and want use different profile preferences? Master build uses its own profile directory LibreOfficeDev/number which also could be moved to for example LibreOffice/DevNumber.
Discarding users' customization as they upgrade seems really unfortunate. 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. 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). So - absent some developer to work on this in the next 10 days - this is unlikely to happen for 6.0 I think.
(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
ESC decided to reject this suggestion as there we dont provide a means to migrate user data.
*** Bug 115260 has been marked as a duplicate of this bug. ***
I think any new LO version should avoid breaking the end user platform. As LO is improved, we already work hard to not break the underlying API. To the end user, their API is their entire LO platform, including settings, customization, and history. So with any major version upgrade I think it's quite reasonable for users to expect no less than the following: 1) First, the existing version is left 100% intact. 2) Then the user is asked: How do you want to create the new version's configuration, settings, etc? a) Fresh - abandon prior customizations, e.g. BASIC code, menu reorganizations, configuration settings, etc., and install a fresh LO, OR.. b) Copy & Adjust - Copying the older version's settings, and automatically converting (as much as is possible) into the new version's format. As much as is possible Copy & Adjust should at a minimum include keeping: * Any BASIC code * Any MENU additions and re-organizations * Any option settings * Any customization settings * Any history Finally, and IMPORTANTLY, Where this is not possible, or not completely possible, the user should be provided a written list of what is not possible to carry forward, and what might have to be manually fixed. If #2 above can't be done (or not yet), then I think any new version releases should be held back until this can be properly done. We risk loosing our user base.
*** Bug 122993 has been marked as a duplicate of this bug. ***