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).

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.

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 ? ;-)

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).

Sounds good to me.

And it works for me too. I've tried it in Glom and it fixes my problem.

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.

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.

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.

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).

Review of attachment 172484 [details] [review]:

Seems to work fine.

Ok committed this one, closing (ofcourse the hacky bits will need
revisiting after the initial treeview refactor).