Re: notes on combo boxes

[Tim Janik <timj gtk org>]

On 3 Aug 2000, Havoc Pennington wrote:

> Tim has GtkClueHunter in beast/beast-gtk/bstutils.h. I think this
> looks like a pretty good widget for a text-entry combo box; it is
> reasonably simple, and it has tab completion which is the primary
> feature people request for these boxes (the only other one I can think
> of is putting a pixmap by each item in the popdown, but I doubt that
> feature is important).

it does actually live in beast/beast-gtk/glewidgets.h together with the
wrap boxes.

> Thoughts:
>  - GtkClueHunter is a more complete text-entry combo than 
>    GtkComboText, with tab completion and stuff

"tab completion and stuff" here is actually shell-style tab completion,
featuring wildcards and multiple matches. also the clue hunter offers
history recording if desired and could easily be extended to do auto
completion if not editable (i never needed that myself which is why
it doesn't currently do that).

>  - GtkClueHunter should not be named that ;-) also a couple 
>    of the functions and signals could use better names 
>    IMO

well, i actually asked for an apropriate name for it on #gimp one sunny
day, and ClueHunter from xach was the only name that virtually resembled
it's features, rather than the name inventors humor ;)
i'm not opposed to renaming it if sane suggestions are provided.
as for the signals and API, i'd like to hear detailed comments there,
i certainly provided to name the entry points after their intended
purpose.

>  - GtkComboBox should probably be called something else, 
>    and GtkComboBox should likely be the name of the 
>    text combo 

for a virtual base class, i'd consider GtkComboBox most appropriate,
with the text front-end being either GtkComboText or GtkTextCombo.

>  - I think the PixmapCombo is quite useful. I assume this is used
>    for the color combo in Gnumeric. But you could also use it 
>    for symbols to place on a plot, brushes for a paint program,
>    etc.

right.

>  - In general I think the GtkComboBox abstract base class is 
>    pretty useful, because the popdown window is tricky to 
>    implement yourself

yes, in fact i plan on providing some general purpose functions
beyond combo widgets that position popups properly according
to a given constrainig area. there's lots of different code snippets
for that out there, most of which need serious fixing.

>  - GtkComboBox is currently implemented with GtkList, and 
>    GtkClueHunter uses the CList, both are deprecated, if this 
>    is relevant

well, some kind of list has to be used, and i went with clist so
things like pixmaps could esily be added in another row.
once GtkTLView emerges and is renamed ;) we should probably use
that and have a pluggable model object either feturing a combo
controller interface or have a seperate combo controller object also.

>  - PixmapCombo needs moving to GtkImage instead of GnomePixmap 
>    in order to go in GTK, but this is trivial
>  - PixmapCombo could probably just allow any widgets to go in 
>    the grid to be chosen from.

right.

> It's sort of unclear what the hell a combo box actually is, because it
> blurs with option menu. In fact Qt uses a combo box with an "editable"
> flag, where an ineditable combo is just an option menu. For GTK, if
> someone wants a widget that displays a fixed set of uneditable strings
> to choose from, we want them to use GtkOptionMenu. The PixmapCombo is
> also really an option menu, but because of the way GtkMenu works the
> grid of images is much easier to implement in this combo framework
> than it would be as an option menu.
> 
> On the other hand, if you think about it GtkOptionMenu derives from
> GtkButton, and the "combo" in ComboBox is that it's a combo of a
> button and a list of items to choose from, so maybe we are on crack. ;-)

i think combo is pretty apropriate in resembling the respecting windows
widget. also i'm pretty clear on what a combo widget needs to provide,
for the most part i second federico (base class, model, view, controller
seperation), but for the text combo i definitely want shell style wildcard
support beyond plain tab completeion. also, one important thing about the
clue hunter is that it's attachable to existing entries in an application,
and doesn't provide it's own aggregated input widget.
so the widget actually displaying (entry, label, pixmap, maybe button) and
the widget activating the popdown list (mostly an arrow button) need to
be featured seperatedly. that's especially important for extending existing
user interfaces after the fact once programmers get around to it.

> If that seems like too much or too complicated (I don't think it is,
> these widgets are pretty simple and small), then I'd just go for
> the text combo, GtkClueHunter is probably fine for that.

well, if we replace the current gtk combo (which _is_ basically useless, i
agree) we should go for the right thing and provide MVC seperation in a
base class also prolly two prominent front ends like text and pixmap combos
and base it on jonathans new lists. 
i'm saying _if_ here, because it's really a matter of someone pulling up
the resources to rework the existing ComboBox and provide, a decent controller
interface and do a pixmap combo reference implementation for that. the text
front end i should then be able to base on that implementation reusing clue
hunter code in one or two days.

> 
> Havoc
> 

---
ciaoTJ