Re: Thoughts on the ComboBox framework

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-03-31 at 16:17, Havoc Pennington wrote:
> 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.

I was *not* thinking of it as a portmanteau-combination of 
GtkOptionMenu and GtkComboBox; but rather just as GtkOptionThingy.
The problem with GtkComboBox is that the typical use case
is not clearly a "combination" of anything. GtkChoice?

> >  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 way it works is that if you call this function, you get

 [ sample widget ] [\/]

What you get when you hit the arrow would depend on the mode--
maybe a menu, maybe a list. But the single button giving
a menu is the sample-widget == NULL case.

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

The problem here is the same one as GtkTreeVIew, the overloading
of the term column. "column" here is "model column". 

I was trying hard in the above to avoid making the two parameters
"columns_column" "rows_columns".

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

It's confusing to have the generic name not be the most generic
case; gtk_image_new_empty() wasn't much of a name.

While most uses will be text, I don't think it's a case where
people won't want even to consider other possibilities; 
variations like grid-of-colors or text-plus-icons will be
close to the surface of people's minds.

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

The problem here is the same as GtkTreeView - when there
are incremental changes involved, if the only interface is
"here is a complete new list of choices". then it's very
hard to avoid flicker as you change that list of choices
(and when there is selection very hard to keep the currently 
selected item selected.)

So, your interface really needs to look a lot like GtkTreeModel:
with incremental notification of additions, deletions
and changes to current rows. You could do the whole thing
as:
 
 gtk_entry_set_completions_tree_model ()
 
And leave the updating of that on ::changed up to the app.
That would work if you don't want GTK+ doing the searching.
But "give me the completion" definitely doesn't work 
since we need a list and "give me the completions" (plus
a "completions changed, ask me again") is, in my guess,
going to be slower and more flickery than stuffing everything
into a tree.

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

Actually, for the combo, people will definitely want have items
that do things other than make the selected item the current one.
E.g., "select custom color".

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

What the widgets have in common is not the _implementation_ of
the popdown button, but the quite complicated _interface_ of the
what gets displayed in the dropdown list / menu, and somewhat less
importantly, the _interface_ of "an item in the drop down list was
selected".

Regards,
                                           Owen