Now, selecting multiple toolbars to view or hide is an iterative task, with these steps: 1. Select "View." 2. Choose "Toolbars." 3. Tick or untick a toolbar. 4. (Repeat) For multiple toolbars, this task is tedious. The task would become simple if users were shown one "static" menu box allowing them to make multiple choices at once. So: 1. Select "View" 2. Select "Toolbars. . ." 3. Tick or untick desired toolbars. 4. Select "Close" or "OK." 5. (Done) Helpful also to include would be the option "Untick all" (or "Hide all toolbars"). Though generally useful, this option has a particular use case: For Writer a much-requested feature is "split-screen" functionality -- that is, the ability to display and work with the content of one file in two windows, each showing a minimal interface. With Writer as it is now, the best way I know of to achieve this is: 1. Choose the "Sidebar" interface. 2. Hide all toolbars. 3. Choose "Window--> New Window." 4. Manually position the two windows as desired. For this use case, having steps 1, 2, and 3 (and perhaps 4) collapsed into one command would be ideal. But at least having step 2 be close to a one-shot task would help.
Thnak you for your idea. I see some advantages and some disadvantages (if user only wants to add one toolbar, it will be at least one click more), so let's ask design-team. Perhaps there could be a solution within toolbar-tab of customization dialog.
My first idea was that ticking the toolbar configuration is not a frequent task and not worth any additional effort. But indeed I also struggle sometimes to find the right one and have to go back into the (long) menu. Essentially the proposal means to integrate the toolbars list into the "User Interface" dialog. Nice clean-up, IMO.
Having a dialog implies more customization options. Then there is scope of implementing toolbar groups , which the user creates. Like I need a,b,c toolbars for specific types of documents, d,e for other..etc or I need some toolbars forr specific type of text/content.., some for other . Then we might add some functionality to toggle between toolbar groups, that can be mapped to some keyboard shortcut (just brainstorming).
We discussed the topic in the design meeting. The majority wants to keep the menu with the arguments that it is a familiar interaction (user might not be aware of toolbar settings under the menu item User Interface), the access via mnemonics is quick, the envisioned solution of a checkbox list in special tab is probably not appealing. Feel free to reopen as a volunteer who wants to implement this anyway.
Thank you to all for considering and discussing this suggestion. But it seems to me now (I missed it earlier) that my suggestion seems to have been misunderstood, or at least extended beyond what I envisioned. What I had in mind was not to shift anything to the “User Interface” dialogue. (I agree that this would be unfamiliar and problematic.) What I had in mind was to let the “Toolbars” dialogue (in the same place as now) behave differently, so that I could open or close several toolbars at once. But perhaps this *was* considered. In which case, fine. You’re the experts, and I don’t want to be cranky. Sorry I don’t have the skills to implement or mock up anything. Thank you again.
(In reply to j.a.swami from comment #5) > What I had in mind was to let the “Toolbars” dialogue (in the same place as > now) behave differently, so that I could open or close several toolbars at > once. The issue is clean: you want to manage multiple toolbar at once, open for example the Drawing toolbar and closing the Track Changes. You imagine something like a persistent checkboxlist that allows to toggle as many items as you like. This means you need some interaction to finalize and accept or cancel everything. That's not given with menus, and although I've seen hackish solutions it's not good UX and very unfamiliar (users know that menus close on click). The follow-up idea was to have this list of checkbox in some dialog, which also could be the UI chooser, could be an extra tab. This idea was rejected, as reported in comment 4. I'll resolve the ticket again since you asked a question. Typically I keep the reopened ticket open - it's your project, and as commented: if you find volunteers...
Thank you very much, Heiko. You've made the entire thought process clear.