Re: Thoughts on combo replacement

[Kristian Rietveld <kris gtk org>]

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.

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

> 
>    So, if we can avoid this (and I think we can) we should.
> 

> 
>    To support the menu style of display with gridded items, we'll have to add
>    gridding support to GtkMenu, which won't be particularly fun. (Nothing with
>    GtkMenu* is.) But is potentially useful in general.

Heh.

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

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

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

> 
>    Row/column spanning is more natural here, but would still pose problems
>    for using a GtkTreeView to implement the list mode.
> 
>  * With either possibility there would be a ::item-selected signal when the
>    user chose an item from the combo, it would presumably take a GtkTreePath
>    for the tree-view API and a GtkComboItem * for the second API.
> 
>  * The base combo widget should support probably support all of the 1a), 1b), 2a), 2b) 
>    possibilities for the non-menu widget. 
> 
>    If we want text-combo or color-combo widgets, it would make sense for them
>    to be subclasses of the base widget, as in the gal API.
> 
> Questions
> =========
> 
>  * Is the idea that "every thing acts like a menu item" sufficient?
> 

I think it is for most cases. Though IMHO using menus in 'browser-style'
combos is ugly.

>  * Is row/column spanning for gridded items necessary?

I don't really see where this can be useful.

> 
>  * What are the relevant widgets in the competing toolkits (WinForms, Swing, Qt)?
>    what do they support?


regards,


	Kris