Re: Thoughts on the ComboBox framework

[Havoc Pennington <hp redhat com>]

On Mon, Mar 31, 2003 at 03:49:29PM -0500, Owen Taylor wrote: 
>  GtkOptionBox
> 

I strongly hate GtkOptionBox. ;-) The advantage of using a familiar
term (ComboBox, OptionMenu) easily outweighs the technicality that it
can look like either one.
 
>  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.
 
> The question is how to integrate the grid into the list store
> centric API, including row/column spanning. My current best
> idea is:
>  
>  gtk_option_box_set_wrap_width (option_box, n_wide);
>  gtk_option_box_set_span_columns (option_box, 
>                                   width_column, height_column);
> 
> Where, a value of -1 for width_column or height_column means
> "use 1 for all" and is the default for both.

I can't figure out what the set_span_columns() function does?  To
address a use-case like the button inside the gnumeric color combo,
don't you need to set the colspan per-item, not globally?
 
> I think there should be a convenience constructor for creation
> an EggComboPicker with a single text column -
> 
>  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 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.

Having to stuff data into the GtkListStore seems quite ugly - I mean,
for my web browser I have a *lot* of URLs in my history. Why should
those have to be stuffed into the widget? It's just grotty.

Imagine an entry where I type a function name and the completion is on
15,000 functions in the source tree, or an entry where I type a
command and the completion searches the path. Seem like reasonable use
cases where stuffing into the GtkListStore then linear-searching it on
every keystroke might suck. I mean, we could at least use a history 
representation that can be binary searched...

It can't be *that* complicated.

> I'll stop there to keep this mail manageable. I guess the
> basic question is whether you (and other people) think
> the approach of:
> 
>  GtkOptionBox
>      ||
>      \/
> GtkOptionEntry  HAS-A   GtkEntry
> 

Having the editable "combo" (which isn't even a combo; it's an entry
with a dropdown history) derive from OptionBox makes no sense to me
conceptually, and my intuition is that it's a giant implementation
mess as well.

I don't see how it makes sense to share implementation between the
dropdown list next to an entry and the OptionBox, especially via
inheritance. You're designing your inheritance hierarchy in order to
share the code that detects button 1 press and calls popdown(), that's
all the widgets have in common. what am I missing?

Havoc