When we right-click a toolbar, in any LO module, we get a context menu. Some of the context menu controls what buttons are visible on that toolbar. I claim that it is at least as useful, and in fact more so, to be able to control which toolbars are visible, from within that context menu. Reasons: 1. It is at least as likely if not more that a person would want to enable a toolbar than to modify one. The former happens very often (especially since toolbars can get auto-hidden), and the latter rarely. 2. If you have your mouse already on a toolbar searching for something, and you can't find it, an "obvious" choice is to right-click - as opposed to "giving up" on the toolbar for now and going "elsewhere" - into the menus. (3. I think some other apps have this behavior.)
I close as a duplicate of existing close but better request. *** This bug has been marked as a duplicate of bug 78525 ***
(In reply to Timur from comment #1) > I close as a duplicate of existing close but better request. If it's "better", it's probably not a dupe. More specifically - that request regards the empty space outside of toolbars, this one regards toolbars themselves. The requests are related, but are in fact complementary. It's often the case that you have no extra empty space, or you have a bit of it, but it's "far away" to navigate to when you're looking for stuff on the existing toolbars. It would be convenient to have the toolbar choice to be more immediately available.
This one is WontFix, so it was really better to consider it a duplicate. But I advise you to search more before submitting. Do *not* change status set by a member of QA team. You may call someone else from the QA or UX in CC if you disagree.
(In reply to Timur from comment #3) > This one is WontFix, so it was really better to consider it a duplicate. Was this possibility discussed? Or is it your personal belief that it should not be fixed? > But I advise you to search more before submitting. I did search... although, you know, if I had better access to the set of component meta bugs, I would have gone through the blockers of "Toolbars-Context-Menu", and would have found the other bug. Still, it's not a dupe, so... > Do *not* change status set by a member of QA team. Sure I will. This was a perfect example: This bug is not a dupe of the other one. Of course, I don't get to decide whether it's WONTFIX or not, so I'm not changing that, but I'll definitely correct wrong marking of dupes - like I have for years. As for you - please refrain from closing bugs submitted in good faith, by a responsive QA contributor, without allowing for objections first, or alternatively making it clear that you are ok with the reporter reopening if necessary. > You may call someone else from the QA or UX in CC if you disagree. Don't try to boss people around. LO is a community project and you don't own it.
(In reply to Timur from comment #3) > This one is WontFix, so it was really better to consider it a duplicate. Asking again - who decided this is WONTFIX?