Description: Toolbar ‘Locked’ status is not being read from user/registrymodifications.xcu at startup. Steps to Reproduce: 1. Delete user profile: %APPDATA%\libreoffice\4\user folder does not exist 2. Open Writer (not on an existing document) 3. Close Writer 4. Rename new user\registrymodifications.xcu to registrymodifications_base.xcu 5. Open Writer (not on an existing document) 6. Right-click Standard Toolbar, and un-check ‘Lock Toolbar Position’ 7. Close Writer 8. Compare registrymodifications_base.xcu and registrymodifications.xcu. The only meaningful difference is that the ‘Locked’ status for the writer standard toolbar has changed from ‘True’ to ‘False’. 9. Open Writer (not on an existing document) Actual Results: The standard toolbar will start as locked, even though the registrymodifications.xcu has the locked status as False. Expected Results: Standard toolbar will be unlocked at startup. Reproducible: Always User Profile Reset: Yes Additional Info: The same behaviour occurs in Calc, Draw and Impress, and for all of various toolbars I have tested.
Confirmed that opening Writer sets back the Locked flag to True even though it was unlocked in the previous session. This started in 7.2. I can reproduced in: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Not in: Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded This started with the fix 086fa727cabf46eacfec1a0fd4f6dfe916aa2f04 for bug 131817. (checked with the linux-64-7.2 bibisect repo) In the release notes: https://wiki.documentfoundation.org/ReleaseNotes/7.2#General Heiko, shouldn't unlocked toolbar persist between sessions?
(In reply to Stéphane Guillou (stragu) from comment #1) > Heiko, shouldn't unlocked toolbar persist between sessions? Yes, it should. My patch changed the global locked state, which obviously overrules the individual. It has been questioned a lot- and I wouldn't object if the patch is reverted (needs to be done manually). OTOH, why do we have a global state at all? It sounds like the better solution to me to fix the issue by evaluating both options.
Just to confirm that the issue is still present and locked toolbars get reset to unlocked upon LO startup.
When I initially reported the bug, I didn't realise there *was* a global toolbar-lock switch. What I reported was that an individual toolbar was not responding to its own lock setting, when what was actually happening was that the global switch (at that time, =false) was overriding the individual toolbar settings. I do see the point of something global - I prefer all my toolbars locked, and the easy way to do that is currently the global switch. On the other hand if I unlock a particular toolbar, I want it to stay that way between sessions - the global switch is perhaps too heavy-handed in overriding individual toolbar settings. A not-thought-through suggestion: make available a *process* that sets locked status for all toolbars to true (or false, as user requests), ie: sets all the individual toolbar settings. Any response to the global switch is dropped. If the setting for a single toolbar is changed, that gets preserved between sessions.
Toolbar handling in the UI dialog as discussed in bug 158880 comment 2 could include an "[ ] All" option that toggles the visible and the locked flags on/off.
What I was thinking of was just two menu items at the bottom of the Toolbars sub-menu, (1) Set All Toolbars Locked, (2) Set All Toolbars Unlocked. In both cases this changes the locked status for all the individual toolbars. If some toolbar has it's locked status manually changed later, that is preserved at startup. The global locked state is just ignored.