Description: UI: Make the option for ability unlock & re position toolbars more obvious. Follow-up on bug 131441 and the discussions in bug 92484. Small change, lot's of impact. The current implementation of the locked toolbar isn't great (unintuitive), IMHO. First thought, what the heck, are the toolbars changed to fixed position. Regina pointed me to bug 131770. Some suggestions/ comments. 1. Show the handle/drag indicator (dotted 'line') at the left, even when the toolbar is locked. This makes people aware that the toolbar can be dragged in theory. Yes, I'm aware, it this could be confusing to (drag indicator) without ability to drag, but people would at least 'search' for a solution, I guess. I did really think that someone made the toolbars fixed for some reason... 2. Add a right click context menu to the drag indicator (containing lock/unlock & undock toolbar). The toolbar Right click context menu is already way to long for netbooks etc. And the lock/unlock toolbar item is easily overlooked. At least I overlooked it. I stopped looking after first 10 items or so... Btw, I also nearly never use the Right Click context menu for the toolbar at all 3. Add a menu entry lock/unlock toolbars to the View -> Toolbars menu 4. Make the lock/unlock setting a 'global' setting. The ability to lock/unlock toolbars individually is annoying. Example: Draw sidebar unlock is separated from draw toolbar unlock. At least I don't see the need for individual locked positions. 5. If we are already at the point of locking things to fixed place, please do the same for the sidebar. Why? A: This would make things consistent B: I made the sidebar floating unintentionally numerous of times Steps to Reproduce: 1. Open Writer 2. Try to drag a toolbar Actual Results: The ability to re-order or making toolbars float is totally hidden. Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: 4501a0ba623ad61c5a4e0b807da2e96f0e4ce82c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Any opinion on this?
An option to globally set toolbar locking at tools > options > view makes sense. As this would be a UNO command you may customize it into the menu (against this by default).
Summary needs work, it already is obvious now that the toolbars are locked (by default for bug 92484)--the vertical ellipsis dots are not shown, clean and simple. However, as noted in bug 131441 the ability to toggle from all locked to all unlocked, and back, would be a good addition to current ability to do so with each individual toolbars by its context menu. The visual indicator of all unlocked toolbar state would be visibility of the vertical ellipsis dots. Otherwise, for Toolbars, several options to consider: -- order of the toolbar context menu buttons -- pin the show/hide, and lock/unlock -- set the default action to toggle the lock. -- etc. As to the Sidebar deck behavior--leave it alone. Completely different UI and controls.
So let's do it.
I just spent a couple hours searching for a solution to this problem and filing another bug report on it here: https://bugs.documentfoundation.org/show_bug.cgi?id=141702 (Text duplicated below for convenience.) Telesto is correct: it's very unintuitive. Undocking toolbars was never a problem; locking them by default and making it so difficult to unlock & undock that one must repeatedly search for support assistance is. While the suggestions are good, they are only there to fix a problem caused by "fixing" something that was not broken to begin with. Just undo the lock by default and stop making things more complicated. Whatever is done, PLEASE, do not do #5! Locking the toolbars by default is already an unnecessary problem. Please do not add to the problems. Again, the movable and dock-able toolbars, especially when combined with the sidebar, are some of LO's great innovative features. Please do not hide these features by making them inaccessible to new users. **** PLEASE undo this! I am trying to be civil, so apologies in advance if this seems harsh. A Solution in Search of a Problem. I've used LO for several years and never had an issue with accidental undocking of toolbars. Yes, I undocked several when I first started using LO, but that only made me curious to explore the program. The accidental undockings were easy to replace when I needed to continue working. But, when I wasn't pressed for time, I played with the feature and learned that I could dock toolbars anywhere I wanted! By locking them, that natural learning is prohibited. Also, as I'll discuss below, the unintuitive method of unlocking the toolbars makes it unlikely that a new user would ever find it without searching for online help. But, then again, the new user would not even know to search out how to unlock & undock the toolbars because this is a feature unique to LO. This effectively hides one of LO's most useful and innovative features. (I only know of a couple web browsers that even make use of the sides of the screen for interface commands, and they are nowhere near as useful or versatile as LO's interface.) A Solution Creating Problems. I have had to search how to unlock the toolbars 3 different times now. When I right-click on a toolbar, I do not get the pop-up menu unless I right-click twice. This is very unintuitive and makes me think I am not doing it right, which is why I have had to look up how to unlock the toolbars 3 times now. But then the problems go further. It is not just the unintuitive double-right-clicking, but one must double-right-click EACH toolbar separately in order to unlock them. Why? That compiles annoyance on top of annoyance. How much annoyance is justified to prevent the perceived problem? Double-right-clicking each toolbar is annoying. Hopefully, I won't forget this oddity in a month or so when I need a toolbar I haven't used in this install yet and forget how to unlock them. I just reinstalled LO, so I will find out if I must also unlock each separate toolbar on every program, but, honestly, this is a time wasting annoyance. Hiding LO's Utility under an Antiquated Interface. Without the ability to undock a toolbar, the toolbar interface looks like the old out-of-date MS Office interface. The buttons are either present or absent, which is no different than the MS pre-Ribbon interface. For the new user who is unaware of LO's toolbar versatility, this essentially hides the feature. The ability to move LO toolbars around is wonderful. Combined with the Sidebar, they allow the user to dedicate more screen space to the document by placing toolbars to the side. (To clarify with a contrast, if the toolbars were placed only on top, they would eat into the vertical space and force the user to shrink the zoom on the document in order to see it in its entirety.) I find this more efficient space use to be a great feature of LO. Even better, LO allows intuitive toolbar placement. In Draw, for example, I maintain the toolbars common to Writer at the top and can place the more Draw related toolbars on the bottom and side. This makes it much easier to find the needed functions. I came to LO after using Ribbon in MS Office. I thought the notebook/grouped bar interface was great when it came out. (It's still great, btw, and you folks at LO did a really cool thing by making the different interfaces that people can choose from.) Then I decided to update my skills and went through some LO trainings online. The LO trainings introduced me to the Sidebar and really showed me the utility of the toolbars. I now vastly prefer the standard toolbar interface to the grouped bar because of its versatility and utility. If the toolbars were locked by default when I first began using LO, I'm not sure I ever would have discovered this feature, and LO would have just looked like an Antiquated MS copy instead of the unique and innovative office suite that it is. In summary, this change does little to nothing to fix any perceived problem. It does however, create annoyances and problems for users while hiding one of LO's most intuitive and versatile features. Please, please, please, change it back.
*** Bug 141702 has been marked as a duplicate of this bug. ***
Maxim, was locking into this and wonder if this should be done in the toolbarlayoutmanager similar to dockAllToolbars(). But I don't see how to access this class from optgdlg. Any tip/code pointer?
The biggest irritation is that the locking/unlocking is property of individual toolbars. Instead, it should be the property of the entire space. Here's the use case scenario: In the following scene, "right-click" means anywhere in the toobar area (over any toolbar or empty space). 1. Right-click and select "unlock". All the toolbars are unlocked at once. 2. Drag and drop the toolbars. 3. Right-click and select "lock".
Patch at https://gerrit.libreoffice.org/c/core/+/115797
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/086fa727cabf46eacfec1a0fd4f6dfe916aa2f04 Resolves tdf#131817 - Option to globally switch toolbar locking on/off It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The new option comes at last in the Toolbars sub menu at View. You get asked to restart; I believe that individual toolbar settings like Table is unlocked is kept but haven't tested this. Please check carefully.
Is there a way to isolate the file for testing? A link to an FAQ that answers would be fine or please tell me the correct keywords to search. Am I looking for a sandboxing environment? (Running Widows 10) I would like to help and test it, but I have very limited time now. I really don't want to have to go through the setup process twice and spend a couple hours scrolling through extensions to return my LO back to where it was. My apologies. Bug testing is a new area of tech for me. I appreciate any suggestions. Thank you.
verified as fixed in: Version: 7.2.0.2 / LibreOffice Community Build ID: 614be4f5c67816389257027dc5e56c801a547089 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded