RE: Thoughts on the ComboBox framework

[martyn 2 russell bt com]

IMO, I believe that the Combobox should be a wrapper for the widgets already
available (namely GtkTextView and GtkEntry).
Commonly, the combo box top (which is always shown with the drop down
arrow), has two uses. 

- First is to have an entry which can not be modified and must be an item in
the drop down list.  
- The second is to have an entry which can be changed and which can also be
selected from the combo drop down list. 

When the drop down button is clicked, the GtkTreeView should be shown.  For
searching and add entries, etc, the GtkEntry should be used. As far as the
columns and how the data is shown in the GtkTreeView is concerned, shouldnt
this be left to the user to configure, perhaps with a API call to get the
store/model and be able to modify the data in that way?

I may be way ofcourse on this, but I believe we already have the widgets to
do the basics of what we want, your thoughts?

> I strongly hate GtkOptionBox. ;-) The advantage of using a familiar
> term (ComboBox, OptionMenu) easily outweighs the technicality that it
> can look like either one.

I would have to agree, developers using GTK will associate a combo box with
a GtkCombo, not a GtkOptionBox.  This may confuse first time developers
because there is already a GtkOptionMenu.

>  
> >  void gtk_option_box_set_sample_widget (GtkOptionBox *box,
> >                                         GtkWidget    *sample);
> 
> My main problem with this is I just don't see how the implementation
> will work or make sense, really. In option menu mode, there isn't even
> an idea of a sample widget vs. the dropdown widget.

I quite like the idea of this.  IMO, there should be two method of doing
this.  Probably the most common will be that a developer would want a few
items and the text at the top being a representation of what the list
categorises (e.g. SpeedDial - meaning a list of numbers to speed dial, and
the list being the numbers).

In the second case, users will probably want a custom widget (as the
GtkTreeViewColumn allows custom widgets to be used as the headers for
columns). I am thinking along the lines of a GtkLabel and GtkImage
combination:

	[ <image><label> v ]
	[ 1. ... ]
	[ 2. ... ]
	.
	.
	.

> >  GtkWidget *gtk_option_box_new_text (void);
> 
> I wouldn't even have _text() here - it would be better perhaps if
> plain gtk_option_box_new() simply defaulted to a list of text items.
> That is the 95% case and I shouldn't have to think about the text
> issue.

I think if there is going to be a distinction between a text option box and
another type of text option box, the API should reflect this.  It is more
aware to users.

>  
> > I don't really see how the idea of the idea of a completion
> > interface is going to work without a lot more complexity 
> > than what Havoc sketched out.
> 

My view on this is that completion should be COMPLETELY optional.  In most
cases, Combos are used for a small number of options, not huge lists.
However, Havoc has a point, the browser url combo can have a large list to
cater for.

Regards,
Martyn