After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 631452 - Allow GtkComboBox drop-down menu to be wider than the combo-box
Allow GtkComboBox drop-down menu to be wider than the combo-box
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkComboBox
unspecified
Other All
: Normal enhancement
: 3.0
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2010-10-05 16:30 UTC by Tristan Van Berkom
Modified: 2010-10-17 05:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch which adds new feature to combobox. (15.67 KB, patch)
2010-10-05 16:30 UTC, Tristan Van Berkom
none Details | Review
A simpler approach with not realignment of the menu (11.09 KB, patch)
2010-10-06 07:39 UTC, Tristan Van Berkom
reviewed Details | Review
New patch that covers list-mode and renames the property (12.85 KB, patch)
2010-10-13 09:06 UTC, Tristan Van Berkom
none Details | Review
Fixed patch to address RTL growing popups in listmode (13.50 KB, patch)
2010-10-16 09:02 UTC, Tristan Van Berkom
accepted-commit_now Details | Review

Description Tristan Van Berkom 2010-10-05 16:30:02 UTC
Created attachment 171782 [details] [review]
Patch which adds new feature to combobox.

This patch adds a "policy" to the combo-box which determines
the width and x position of the menu when dropped down.

When the policy is not GTK_COMBO_MENU_POLICY_NONE, the menu
recieves its full natural width and is aligned with the combo-box
  LEFT: grows the menu out to the left of the combo
  RIGHT: grows the menu out to the right of the combo
  CENTER: grows the menu out in both directions equally

Ofcourse if the screen bounderies are hit, then the menu is
still repositioned to stay on screen.

tests/testcombo updated to show the new feature.
Comment 1 Tristan Van Berkom 2010-10-05 16:36:06 UTC
Some additional comments;

  - I'm not happy with the name of the enum GtkComboMenuGrowPolicy
    but I think the functionality is good

  - Another useful addition to this I think would be to add 'boundaries'
    to how much it can grow.

    I think a good api for this would be:

    gtk_combo_box_set_menu_boundary (GtkComboBox *box, GtkWidget *ancestor);

    Where if the menu is allowed to grow, it will not be allowed to exceed
    the boundaries of another widget in it's ancestry (i.e. limited to be
    inside some parent frame or scrolled window).
Comment 2 Murray Cumming 2010-10-05 18:49:38 UTC
Do we need this many options. Shouldn't the menu just appear where best (when not constrained to the GtkComboBox size), as a regular menu would? 

If that's not obvious, then I vote for just expanding to the right (or the RTL equivalent), until someone asks for something else.
Comment 3 Tristan Van Berkom 2010-10-05 19:24:04 UTC
Originally I wanted them the grow towards the left for the
case of Glade (cell renderer editor). In that case the editor 
can be in a transient treeview editor window where it's natural 
to place the combos to the complete right of the scrolled window 
(on the right hand of the attribute/property descriptions).

I thought it would look unnatural if the menus were to grow towards 
the right... and then grow out of the parenting scrolled window and
right off of the transient window (like the combo box is suddenly
jumping out of its window).

But now that you mention it I'm a little torn, it's also nice
(and arguably more important) that the text leading up to the 
combo-box on the same line is still visible when the menu drops down.

Another thought was the filechooserdialog bug that was recently closed.

When there's unbearably long text in the bottom-right combo-box
currently the combo-box ellipsizes but fills to the natural size 
(making the whole combo-box potentially span the width of the
above file-list even when a short option was selected. I found this 
was a little unnatural to look at).

I thought ideally for the filechooserdialog the combo in the bottom
right corner should:
  - take a limited amount of space as a combo-box
  - menu should grow towards the left (and not flow off of the dialog)
  - furthermore the menu should be limited in how much it can grow towards
    the left... i.e. it should take no more space than the treeview/file list
    above it.

However these were my initial thoughts, I would be fine with dropping 
the grow-left/grow-center options and maybe come back to re-implement
the alignment features if I find they are needed for Glade's editor.

Sleeping on it for now... leaving a polite pause before stripping the
extra alignment features... sure you don't find combo-menus growing
towards the left is an attractive feature ? ;-)
Comment 4 Tristan Van Berkom 2010-10-06 07:39:16 UTC
Created attachment 171807 [details] [review]
A simpler approach with not realignment of the menu

This patch is a simpler approach and adds a "constrain-menu-width" property
to GtkComboBox which defaults to TRUE (expected behavior, backwards compat...).

It does no realignment of the menu so drop-down menus will always
grow out of the combo-box towards the right (unless they hit the screen
limit of course).
Comment 5 Murray Cumming 2010-10-06 09:39:49 UTC
Sounds good to me.
Comment 6 Murray Cumming 2010-10-07 08:15:56 UTC
And it works for me too. I've tried it in Glom and it fixes my problem.
Comment 7 Matthias Clasen 2010-10-12 03:58:36 UTC
Review of attachment 171807 [details] [review]:

The general idea of this property sounds fine. The terminology can use some improvement. The property should mention 'menu' in the name, since the dropdown may not be a menu (list-mode). Several places in the docs refer to it as the 'menu or dropdown list'. That is of course too long for a property name.

The analogous GtkEntryCompletion property is called "popup-set-width". Not sure thats much better.
Comment 8 Tristan Van Berkom 2010-10-13 09:06:26 UTC
Created attachment 172241 [details] [review]
New patch that covers list-mode and renames the property

    Allow GtkComboBox popup to be wider than the combo itself.
    
    This patch adds a GtkComboBox:popup-fixed-width to decide if the
    popup's width should be a fixed width matching the combo's allocated width.
    
    The patch includes a kindof hack to work around treeviews currently
    not supporting height-for-width geometry (for list-mode only), this
    hack can be safely removed once treeviews start reporting natural
    widths properly.

As mentioned in the commit log, the patch does a bit of bad hacking for
listmode, it first remeasures the real natural width of cells by way 
of iterating through the model and asking the GtkCellView (what we do
for menus anyway), then it needs to add a magick value to that width
in order to ensure that the contents fit the scrolled window border around
the list popup.

This portion is a bit ugly and can very easily go away only after
height-for-width geometry management is properly implemented on GtkTreeView.

Currently the new property name is "popup-fixed-width".

To test list-mode, I've just been running ./tests/testcombo with
an added line in gtk_combo_box_check_appearance() to force all combos
to show up in list-mode.
Comment 9 Matthias Clasen 2010-10-14 03:10:54 UTC
One thing to consider is whether we need to make the 'grow direction' follow text direction here, to achieve the desired effect that the text in the popup matches the text in the cellview pretty closely.
Comment 10 Tristan Van Berkom 2010-10-16 09:02:07 UTC
Created attachment 172484 [details] [review]
Fixed patch to address RTL growing popups in listmode

Found that menus already handle RTL mode when allocated greater widths,
fixed list-mode to also handle RTL, tried a better approach to the
height-for-width hack for the treeview (since the treeview does not 
support height-for-width), now the set-size-request is performed on
the treeview directly ensuring enough space for dynamic sizes of 
scrolled window padding/border-width/xthickness etc, but unfortunately
it seems a magic number of 5 pixels is still needed to display the full
natural width of cells in the treeview (this might be to compensate
for some padding that treeview's actually add around their cells).
Comment 11 Matthias Clasen 2010-10-17 00:47:37 UTC
Review of attachment 172484 [details] [review]:

Seems to work fine.
Comment 12 Tristan Van Berkom 2010-10-17 05:08:26 UTC
Ok committed this one, closing (ofcourse the hacky bits will need
revisiting after the initial treeview refactor).