Description: I noticed that there is a big arrow beside the menu of each group in order to show that a popup textual menu can appear after a click. Why not using a smaller arrow ? For example this arrow could be the same than the arrow of the icon which provides a popup menu. The spared space could be used for an additional icon. Actual Results: A big arrow use a lot of space in a group of the GrouppedBar compact UI. Expected Results: Spare space in order to display one additional icon. Reproducible: Always User Profile Reset: No Additional Info: I noticed in the versions 6.2.8.2 and 7.1.3.2.
Created attachment 173020 [details] a group of the GoupedBar Compact UI You can see : - small arrows on the first line of icons - a big arrow on the second line.
An other possibility would be to use a small character at the end of the title. For example, we could replace "File" by "File…". Note that a single character gather the 3 dots.
Not sure that we have full control of the expander icons.
I would also prefer to have the same arrow size everywhere.
(In reply to andreas_k from comment #4) > I would also prefer to have the same arrow size everywhere. Please resolve NAB/WF as maintainer if your preference for one-sized arrows is strong. If you want more input we can leave the ticket open for a while.
The expander triangle is sized to 75% of the control's text height, see SvxMenuEntriesListBox::CreateDropDown() in cui/source/customize/cfg.cxx, while the toolbar is a bit more complex, see void ImplDrawDropdownArrow() in vcl/source/window/toolbox.cxx (changed recently for bug 122118). We have to deal with different icon sizes where small icons require smaller expander triangles. The only solution I see is to replace the triangle vectors by a pre-drawn bitmaps, which then depends on the icon size (and can be SVGs too, of course). This would solve bug 136757. Caolan, is this a reasonable idea? Making bug 107259 a duplicate of this one. It seems to be the same request though talking also about OS dependency.
*** Bug 107259 has been marked as a duplicate of this bug. ***
IIRC SvxMenuEntriesListBox::CreateDropDown is only for the arrow shown in the tools, customize dialog in the "menu" and "context menus" pages for the arrow preview in the "assigned comments" lists. There is sometimes the use of DecoView::DrawSymbol with SPIN_DOWN to draw these kind of things, I would have guessed ImplDrawDropdownArrow used that, but as you say it does its own special thing there. I wonder if the original screenshot is showing "Fichier" in a button using DecoView::DrawSymbol vs ImplDrawDropdownArrow in the above row. Or if its the same thing used in both places but one bigger because more space allocated for the arrow.
This code sizes the triangles equally but it depends only on the view setting for toolbars. Small icons on Notebookbars don't fit the size of large on toolbars. The toolbox is not aware of the position (NB, TB or sidebar) and we shouldn't make it dependent. - const tools::Long nSize = rDropDownRect.getWidth() - 2 * nMargin; + tools::Long nSize; + switch (officecfg::Office::Common::Misc::SymbolSet::get()) + { + case 0: nSize = 10 - 2 * nMargin; break; //S + case 1: nSize = 13 - 2 * nMargin; break; //L + case 2: nSize = 13 - 2 * nMargin; break; //Auto + case 3: nSize = 16 - 2 * nMargin; break; //XL + } My take: WF resp. size the controls containing icons in NB equally.