Re: Thoughts on the ComboBox framework

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-03-31 at 17:28, Havoc Pennington wrote:
> On Mon, Mar 31, 2003 at 05:10:20PM -0500, Owen Taylor wrote: 
> > 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?
> 
> That problem is just a technicality IMO, people are used to the name
> combo for this widget from other APIs (they have trouble finding
> OptionMenu), so if it's called Combo they'll find it. Most of us don't
> actually *know* why it's called a combo anyhow. ;-)

Hmmm, yeah, Swing, Qt, WinForms all do use *ComboBox for such
a widget. Though in each case, the very same class also allows
editing.

(Actually, in WinForms, the entry-plus-list-below widget used
for the font selector is also that very same class, interestingly
enough.)

> Plus if you have the HistoryEntry as a subclass and allow
> set_sample_widget() then GtkComboBox *is* accurate, so there 
> isn't even a technicality to worry about.

OK, I'll withdraw my objection to GtkComboBox. As long as it
isn't GtkComboBoxPicker ... that's just too long.

> > 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".
> 
> Ah, if you want to allow custom random stuff in the entry dropdown
> that's true. I was thinking that the entry dropdown had to display
> strings and nothing else, and that the only possible action on "an
> item was selected" would be to put said item in the entry.
> 
> I guess I can imagine putting pixmaps in the entry dropdown, such as
> favicons for URLs. Not sure I can imagine an action on select other
> than putting the text in the entry, but I'm sure people can think of
> something. ;-) 

For one reason or the other, notification on selection from a
GtkCombo's list is a common question on gtk-list, though they may 
just be using GtkCombo where they should be using GtkOptionMenu
and not thinking of connecting to ::changed.

I think this is an area where a bit of flexibility is good.
My feeling is that if we need to come up with a semi-complicated
API to handle the non-editable case, if we can reuse that 
same API for the editable case, that's a win.

Regards,
                                           Owen