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.
@Heiko, some comment on your approach in GUI to supplement or to replace legacy menu interaction for toolbar? /me not opposed to additional dialog based control, but not a fan of changing current menu based ineraction--other than allowing multi-toolbar toogle from the menu. https://gerrit.libreoffice.org/c/core/+/185253
Wouldn't mind to remove the Toolbars menu (.uno:AvailableToolbars) but probably not all the code behind and don't plan to do so myself. The patch adds a tab to the UI picker dialog which lists the toolbars similarly to the Toolbars menu. Users can modify multiple toolbars at once in the tab, yet with limited accessibility ie. no mnemonics (which could be an argument for the main menu list).
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4ab26f4ea0c627844531144a6a903c357a604a5e Resolves tdf#158880 - Let users select multiple toolbars at once It will be available in 25.8.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.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/043b186d10fca4a613ce62c1e0d04f86ec63799c Related tdf#158880 - [API CHANGE] Rename ToolbarModeDialog to UIPicker It will be available in 25.8.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.
Many thanks to the devs for implementing this feature. So expertly done! When we select a toolbar, we see it before we finally decide to go with it--that's a neat advantage I hadn't expected. If I may offer three suggestions: First: This "Toolbars" dialogue offers multiple choices at once, but that may not be readily evident. I was looking for where the new feature is, and for quite a while I didn't recognize it. Had I downloaded the wrong build? (Yes, I'm slow--but I suppose I'm not the only one.) So perhaps the "Toolbars" button could be labeled "Toolbars (multiple choice)". (There's space for the extra text.) An alternative way to handle this (though not as good, I think) would be to put an instruction within the toolbar dialogue itself: Here you can select or unselect multiple toolbars. ☐ 3D Settings [no hyphen, by the way] ☐ Align Objects ☐ [Etc.] Of course, one could do both: rename the button and add the instruction. Second: I would guess that users who've never used this feature, or who use it only now and then, might not remember that it's under "User interface." Their natural starting place, I'd suppose, would be "View --> Toolbars -->." So perhaps the first choice offered under "View--> Toolbars-->" could be "☐ Choose multiple toolbars". Which would bring the user to the new "Toolbar" dialogue. Third: On the "User interface" dialogue we now see two buttons: "Apply to all" and "Apply." But I find myself asking, "Apply to all what?" ("Well, surely not 'All options.' But then?") I think we were better off before, when the buttons said "Apply to All" and (e.g.) "Apply to Writer." That makes matters perfectly clear. Again, many thanks. I'm grateful to all involved. (PS: I don't know the protocols. I hope it's all right that I've changed the status to "reopened.")
(In reply to j.a.swami from comment #12) > So perhaps the "Toolbars" button could be labeled "Toolbars (multiple > choice)" ... put an instruction within the toolbar dialogue itself I disagree. Please refer to the documentation (the Help button was added back right now for bug 167111). > Second: I'd suppose, would be "View --> Toolbars -->." Same here. We should avoid to split options across the menu and this place suits well the functionality. > Third: On the "User interface" dialogue we now see two buttons: "Apply to > all" and "Apply." Which are hidden on the Toolbars tab. You can apply a UI mode to either the current module or all. If you still believe there are issues around the dialog please open a new ticket. This request to allow selecting multiple toolbars at once has been done.