Created attachment 76250 [details] A mockup of the hidden items menu The idea is to have a toolbar flag for showing a menu for showing hidden commands at the end of a toolbar. "Customize..." would be the last entry in the menu. In addition, it'd be great if the icon for this menu was customizable.
Add a separator + 'Customize' icon to the end of the no-space toolbar drop-down, so we can still customize it.
(In reply to comment #1) > Add a separator + 'Customize' icon to the end of the no-space toolbar > drop-down, so we can still customize it. What exactly do you imagine? In the mockup, "Customize..." is already the last item in the dropdown, though I agree it could be more visually separated.
I was just trying to clarify and re-explain the task in words I can understand - your picture didn't help me to see what was new. We already have this toolbar item when you don't have enough toolbar space: you click on the '>>' button in the toolbar and you get that, almost exactly as you show. As such - the only new thing I see here is adding a 'customize' entry to the bottom of that menu [ after a separator ] (right?). Or - do you want to see the items that are not shown in the toolbar as well ? is that the substance of the task ? :-) [ ie. the ones that are un-checked when you right-click on the toolbar and select 'visible buttons' ]. Actually that visible buttons toolbar is mangled, it should show check-boxes next to all those icons - hmm :-)
(In reply to comment #3) > Or - do you want to see the items that are not shown in the toolbar as well > ? is that the substance of the task ? :-) [ ie. the ones that are un-checked > when you right-click on the toolbar and select 'visible buttons' ]. Yes -- that's the task. This would be a per-toolbar setting. > Actually that visible buttons toolbar is mangled, it should show check-boxes > next to all those icons - hmm :-) The entries in the menu should execute the corresponding commands, just like they would in a toolbar. The menu wouldn't be used to toggle the visibility of the commands [1]. The current Visible Buttons menu indicates that a command is shown using pushed-in buttons, not unlike the way the active alignment icons are highlighted. There's no need for additional check-boxes. [1] It could gain this feature, but it should be secondary and rely on e.g. a drag-and-drop gesture.
It is also worth noticing that when menu items like "font color" are pushed out to the menu - that they cease to work ;-) clicking them doesn't give a drop-down to select a color from: fixing that may prove rather problematic - but worth doing no doubt.
(In reply to comment #5) > It is also worth noticing that when menu items like "font color" are pushed > out to the menu - that they cease to work ;-) clicking them doesn't give a > drop-down to select a color from: fixing that may prove rather problematic - > but worth doing no doubt. Definitely.
Making an Easy Hack from this - for the code pointers, please check https://wiki.documentfoundation.org/Development/GSoC/Ideas#Improve_toolbars_in_LibreOffice
Rather than being optional, it'd be better to show the toolbar whenever something is hidden. If the menu bothers the user, he can simply remove the hidden items from the toolbar.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
A polite ping, still working on this issue ?
Unassigning due to lack of work
Is this still a bug ? Needs implementation given the present state of LO.
Re-evaluating the EasyHack in 2022 I think this should be discussed again by the design team to make sure that this change is still relevant after 9 years. The toolbars are different now, and we have different views for them.
(In reply to Hossein from comment #15) > Re-evaluating the EasyHack in 2022 > > I think this should be discussed again by the design team to make sure that > this change is still relevant after 9 years. The toolbars are different now, > and we have different views for them. Customization was introduced and replaces this idea, IMO.
(In reply to Heiko Tietze from comment #16) > (In reply to Hossein from comment #15) > > Re-evaluating the EasyHack in 2022 > > > > I think this should be discussed again by the design team to make sure that > > this change is still relevant after 9 years. The toolbars are different now, > > and we have different views for them. > > Customization was introduced and replaces this idea, IMO. Thanks. Then I close this EasyHack and mark it as invalid.