Re: Thoughts on combo replacement

[Kristian Rietveld <kris gtk org>]

On Thu, 2002-03-21 at 23:51, Owen Taylor wrote:
> 
> Kristian Rietveld <kris gtk org> writes:
> 
> > On Thu, 2002-03-21 at 05:33, Owen Taylor wrote:
> > > 
> > 
> > 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.

I didn't want to say that that doesn't work or is bad. It just looks
weird IMHO. Imagine doing URL completion in Galeon, and the possible
completions show up in a menu (where I would expect a list). So this is
just a matter of taste, so we're back at the theme option :-).

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

If we do it should be in GtkComboBoxText.

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

Indeed.

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

Okay.

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

Agreed.

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

Indeed.



regards,


	Kris

> 
> Regards,
>                                         Owen