Description: Maybe we could decrease the number of icons shown in each group before we begin to hide groups. Steps to Reproduce: 1. Open a document in a maximized window 2. Decrease the width of the window Actual Results: Currently, if the window width becomes tighter, then a few groups are hidden but the remaining groups that appear shows always the same number of icons. Expected Results: The number of icons could decrease until the second row of a group has only the textual popup menu title. When each group displays only the textual popup menu title on the second rows, we could continue to spare space by hiding a few groups. A further enhancement of the layout could optimize the below constraints : 1. we could reduce the number of icons before hiding a group ; 2. if we have to hide a group, the spared space could be used to display again additional icons in a few groups in order to maximize the use the window width. Reproducible: Always User Profile Reset: No Additional Info: The layout of the Groupedbar Compact UI is the same in the 7.1.4.2 version.
The Notebook Bar UI structures are somewhat static--the groups can not be dynamically reconfigured, just hidden (and exposed on the '>>' overflow toolbar). Would require major refactoring to achieve and not clear it would have any real functionality. You'd be dynamically hiding controls in each group in response to reduced width--rather than placing groups in the '>>' drop bar as now. IMHO => WF
(In reply to V Stuart Foote from comment #1) > Would require major refactoring ... IMHO => WF Let's keep it for the record. The idea is to not hide the complete (low prioritized) section but its rightmost column. Don't see any example in the GroupedBar (the menu button below the section takes some space) but at the Tabbed variant in the Tools tab, a bunch of icons become hidden on resize.
IMO it would make sense to drop text labels or make big buttons smaller (preferably dynamically). The lables are main source that makes the bars too wide. Having to open the >> all the time on smaller monitors for quite common features is a serious effectivity crusher, especially because of #140557
(In reply to Martin Sourada from comment #3) > IMO it would make sense to drop text labels or make big buttons smaller > (preferably dynamically). The lables are main source that makes the bars too > wide. Having to open the >> all the time on smaller monitors for quite > common features is a serious effectivity crusher, especially because of > #140557 Wait, we already provide the MUFFIN 'Tabbed Compact' NB for this use case. Otherwise, IMHO nothing compelling a revisit of cross platform labeling of 'Tabbed' NB, which already will collapse its tab label widths in response to reduced frame/display width. Removing labels resizing buttons gains little, but would require a lot of design and dev effort to be made dynamic given the limited capability of the NB framework. Just NO. The progressive collapse of button groups here remains a valid request, just beyond scope of current NB framework.
Created attachment 183719 [details] wide labels in tabbed UI (In reply to V Stuart Foote from comment #4) > Wait, we already provide the MUFFIN 'Tabbed Compact' NB for this use case. I believe that’s good for limited vertical space, here the problem is limited horizontal space and I don’t see any advantages for Tabbed Compact here. > Otherwise, IMHO nothing compelling a revisit of cross platform labeling of > 'Tabbed' NB, which already will collapse its tab label widths in response to > reduced frame/display width. I don’t see that anywhere? > Removing labels resizing buttons gains little, but would require a lot of > design and dev effort to be made dynamic given the limited capability of the > NB framework. Just NO. Well, I just made a suggestion based on my experience, see the attachment for example where lables are the worst offenders (the screen is from mac, but it’s the same on linux/gtk and windows)... And hiding all the rest because of couple wide labels is bad for discoverability and IMHO therefore bad UX.
(In reply to Martin Sourada from comment #5) > > Otherwise, IMHO nothing compelling a revisit of cross platform labeling of > > 'Tabbed' NB, which already will collapse its tab label widths in response to > > reduced frame/display width. > I don’t see that anywhere? On macOS 12.6.1 with LO 7.4.2.3 (382eef1f2) on a 1920x1200px display. Resizing Libreoffice frame below 1130px will collapse the padding around the labeling applied to each NB tabs. The Tabs shrink from ~900px with padding --> ~620px with reduced padding. Expect a Retina display would have a different value--but at same ratio of collapse.
(In reply to V Stuart Foote from comment #6) > On macOS 12.6.1 with LO 7.4.2.3 (382eef1f2) on a 1920x1200px display. > Resizing Libreoffice frame below 1130px will collapse the padding around the > labeling applied to each NB tabs. The Tabs shrink from ~900px with padding > --> ~620px with reduced padding. > > Expect a Retina display would have a different value--but at same ratio of > collapse. Ah, that. Thanks for explaining, I didn’t realize you were talking about tab labels. I was thinking/talking about icon labels.