Re: Thoughts on the ComboBox framework

[Kristian Rietveld <kris gtk org>]

On Tue, 2003-04-01 at 00: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. ;-)
> 
> 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.

My current feeling is that the best idea is to merge the picker and grid
into one widget and call it GtkComboBox. And have a GtkHistoryEntry
which would be a text combo with completion and history and maybe the
ability to switch the arrow and drop down list on/off.

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

Currently the completion code uses a TreeModelFilter (yay :) to filter
out matches, so matches appear incrementally. Because the
TreeModelFilter is just a generic GtkTreeModel wrapper, you can use any
model you want as "backend model".

So I think the only things we would need in the history/completion
interface, are things like add_item, remove oldest, etc.

Disadvantage is that the Filter can't do binary searches ... 

> > 
> 
> That makes sense to me.
> 
> > 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 was also thinking that selecting an item would just put it in the
entry/sample. And I think that's about all we need.

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

Yes, my proposal has support for that (see the screenshot). Basically
people can get the column displayed in the dropdown from the TextCombo
and add renderers to it.


So, as things stand now, I prefer Havoc's GtkComboBox and
GtkHistoryEntry approach.



	-Kris

> than putting the text in the entry, but I'm sure people can think of
> something. ;-) 
> 
> Havoc
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list