Re: Thoughts on combo replacement

[Owen Taylor <otaylor redhat com>]

Kristian Rietveld <kris gtk org> writes:

> On Thu, 2002-03-21 at 05:33, Owen Taylor wrote:
> > 
> > 
> >  * The same choice of menu or drop down list should also exist if you
> >    are implementing a history for an editable entry. That is, if you
> >    have option menus, the history on an entry should appear as something like:
> > 
> > 
> >     +-------------------------+----+
> >     |                         | /\ |
> >     |                         | == |
> >     |                         | \/ |
> >     +-------------------------+----+
> > 
> >   With the option-menu double arrow, and clicking on it should give you a 
> >   drop down menu. I believe the Macintosh equivalent of a combobox
> >   works this way.
> 
> I think we always want the menu to be beneath the widget. The optionmenu
> menu always appeared over the widget. We also need to decide whether we
> want a double or single arrow. If the menu or list always appears
> beneath the widget, then we need to go with a single arrow pointing
> downwards IMHO.

You may be right on this. The idea of the option menu is that the current
item appears under the pointer; this clearly doesn't make sense if there
isn't a "current item".

> >  * While the gal combobox code supports arbitrary widgets in the drop down
> >    portion, I don't think that is actually useful. The only use of it I've
> >    seen is in the color-combo, where you have a bunch of colors and a 
> >    GnomeColorPicker for a custom color. But the GnomeColorPicker effectively
> >    acts like just another menu item, so I don't see any requirement to have
> >    a widget for it.
> > 
> >    Supporting arbitrary widgets causes problems:
> > 
> >     - It will compromise the ability to control the exact behavior of navigation
> >       (especially keynav) in the drop down portion.
> > 
> >     - It means you can't make switching between menus and "lists' a theme option.
> 
> Having a combobox with entry and history, with the history in a menu
> looks weird IMHO. We definitely need a list there. But we definitely
> need a menu for a color picker combo. I'm not really sure if making
> menus/lists a theme option is a good idea.

I don't really understand why having the history be a menu doesn't
work.  And why having a "list" style color combo (selection with the
selection color, base/text colors, etc) is bad.

[...]

> >     - Completion against items in the list (but note that completion is really
> >       a separate and more complex issue... both Mozilla and IE make
> >       the completion dropdown different from the history dropdown; the completion
> >       dropdown displays only current completions, will complete match
> >       www.gtk.org against http://www.gtk.org in the history list and so forth.)
> 
> I think different programs want different completion algorithms. So we
> may have to create some API to change the completion function, and
> provide a default one.

The base question here is whether completion in entries should be at all
integrated with the "combo" API, or should be completely separate. 
I think if you have a history dropdown, it shouldn't drop down with
a different sort of list when completing, which argues for separation
of the two functions.

> > API thoughts
> > ============
> > 
> >  * There is a temptation to use cell renderers to represent the contents of the
> >    list; advantages of this:
> >  
> >     - API reuse.
> >     - Some code reuse. (Though you'd have to duplicate most of GtkTreeViewColumn)
> >     - Quite flexible.
> >  
> >    To handle the menu part, you would create a menu item that used GtkCellRenderers
> >    to render its contents ... there is nothing in GtkCellRenderer
> >    that I know of that is particularly tied to renderering in text/base
> >    contexts rather than in a fg/bg context.
> > 
> >    And (as long as you didn't want to support row-spanning) you could just use
> >    a GtkTreeView to display the contents when in list mode.
> > 
> >    The API would presumably consist of something like:
> > 
> >     void gtk_combo_view_set_model      (GtkComboView     *combo_view,
> >                                         GtkTreeModel     *model);
> >     void gtk_combo_view_pack_start     (GtkComboView     *combo_view,
> >                                         GtkCellRenderer  *renderer,
> >                                         gboolean          expand);
> >     void gtk_combo_view_set_attributes (GtkComboView     *combo_view,
> >                                         GtkCellRenderer  *renderer,
> >                                         ...);
> 
> 
> >     void gtk_combo_view_set_n_cols     (GtkComboView     *combo_view,
> >                                         gint              n_cols);
> 
> I don't understand what this function is supposed to do.

The idea is that for a grid, the simplest API is for the caller to say
how many columns they want, and to lay things out with that many columns
and as many rows as are necessary.

> >    This API is not really amenable to row/column spanning, though you
> >    could imagine making one of the columns of the model be the number
> >    of columns for the item to allow for the simplest cases.
> 
> For combo widgets using a menu we can write some code to fill a menu
> with items from the GtkTreeModel. Though we need to add some API or an
> algorithm to set the number of columns/rows for the grid and to do
> row/column spanning.

The reason I'd consider it not friendly to row/column spanning is that
you really want to put your data into the model and let the widget
do the layout, and if every individual cell needs layout parameters
specified that doesn't work too well.

> >  * The main alternative to using cell renderers would be a simple clist-like
> >    text, image, or image-and-combo design. A straw man API might be:
> > 
> >     GtkComboItem *gtk_combo_item_new        (void);
> >     void          gtk_combo_item_set_text   (GtkComboItem *item, const char *text);
> >     void          gtk_combo_item_set_markup (GtkComboItem *item, const char *markup);
> >     void          gtk_combo_item_set_image  (GtkComboItem *item, GdkPixbuf *image);
> > 
> >     void gtk_combo_box_append (GtkComboBox     *combo_box,
> > 			       GtkComboItem    *item);
> >     void gtk_combo_box_attach (GtkComboBox     *combo_box,
> > 			       GtkComboItem    *item,
> > 			       guint		left_attach,
> > 			       guint		right_attach,
> > 			       guint		top_attach,
> > 			       guint		bottom_attach,
> > 			       GtkAttachOptions xoptions,
> > 			       GtkAttachOptions yoptions);
> >     void gtk_combo_box_remove (GtkComboBox     *combo_box, 
> >                                GtkComboItem    *item);
> 
> If we use this, we use a GtkTable. Do we need gridding support in
> GtkMenu at all then?

If row/column spanning items are useful, then we'd probably want to add
table-like packing options to GtkMenu. Trying to to reimplement GtkMenu
with a table sounds like a bad idea. (Though admittedly, most of the
complexity of GtkMenu is submenus, and GnomeDateEdit aside, they are
probably a poor idea for combo-boxes/option menus.)

Regards,
                                        Owen