GNOME Bugzilla – Bug 656910
ComboBox arrows point only downward (should be both upward and downward)
Last modified: 2017-08-24 12:35:04 UTC
Outside of a menu bar, some menus open completely downward, with all items below the menu button. For example, the Back and Forward menus in Epiphany. This is indicated by a downward arrow at the end of the menubutton. Other menus -- in GTK, the ComboBox and (in GTK2) OptionMenu widgets -- open both upward and downward, with the current selected item over top of the menu button. For example, the Icon/List/Compact menu in Nautilus, or the font menu in Character Map. This is indicated by a pair of upward and downward arrows. Unfortunately, in GTK3, menubuttons for menus that open both upward and downward have arrows pointing only downward. Apparently this bug is theme-independent.
Affecting master too. Also, theming engine should be able to match them. I'd suggest a new style class maybe (as they should be different from normal arrows), instead matching them like GtkCombobox.arrow whatever
As far as I can see, that's just the default behavior of GtkComboBox when it's used with no entry, so theming engines are already able to match it separately in git master with "GtkComboBox .button", as opposed to "GtkComboBox.combobox-entry .button". The problems here are: - the arrow is rendered in GtkComboBox by packing a GtkArrow together with a GtkToggleButton, and the arrow is hardcoded as GTK_ARROW_DOWN in the code - there's no GTK_ARROW_UP_DOWN type - gtk_render_arrow(), in turn, doesn't allow rendering a double-sided arrow anyway Design-wise, I believe we should decide what's the right metaphor to use in the widget there (arrow down vs. two-sided arrow); is that really something up for the theme to decide? Sounds more like a wrong widget behavior to me, but I'm not completely sure. Some of the solutions I can think of: - render two GtkArrows in GtkComboBox instead of one - do the same, but also introduce a new style property of GtkComboBox for themes to decide which of the two styles to use As a temporary workaround, I believe you can special case the "GtkComboBox .button" case in your theming engine's render_arrow implementation and draw the double arrow from there in the meanwhile.
Exactly as I said in my comment, I think the solution 2) is what makes sense for me. Previous gtk+2 theming engines were dealing with a detail "combobox" for those kind of arrows (more precisely, especially for gtkoptionmenu)
Seems reasonable to me. Jakub do you have any specific visual guidance here? The question is, how should we indicate the popups will open with the currently selected value centered over the combobox?
The simple arrow is visually more appealing as it's a simpler shape, despite not being accurate of how the menu behaves (we also expanded 2nd level menus towards the left if the space was insufficient despite the arrow pointing the other direction). I see the main function of the arrow to indicate a list rather than nuance of the behavior of the popup. The double arrow approach doesn't particularly work with the open arrow we use in Adwaita. So rather than doing the filled triangle for the arrow, I would continue styling the expand-up-and-down the same way we style the drop down if we choose to expose the distinction for 3rd party themes.
Nowadays the icon can be overridden as follows, though you'd have to be very clever to do this conditional on where the menu will open... combobox arrow { -gtk-icon-source: -gtk-icontheme('icon-name'); } Is this likely to be revisited, or is it effectively a wontfix at this point?
wontfix