Re: notes on combo boxes

[Federico Mena Quintero <federico helixcode com>]

Havoc Pennington <hp@redhat.com> writes:

> I'm not sure if it's a GTK+ 2.0 item or a 2.2 item.

It should be 2.0.  GtkCombo is pretty much useless and combo boxes are
a common enough UI element to make them worth putting in the next
version.

> GtkComboBox is an abstract base that handles the details of dropping
> down a selection widget underneath another widget. Subclasses define
> what the button widget contains (entry, button, etc.) and what the
> drop down contains (grid of color buttons, list of strings).
> GtkComboBox isn't _that_ abstract, conceivably you could even
> instantiate it and create a "subclass" just by packing in some widgets
> and connecting to a couple signals.

Having a generic combo thing is the right thing to do, as Gnumeric
shows.  Then we can define other requirements for text combo boxes or
whatever.

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

GtkComboBase and GtkTextCombo, perhaps?

GtkComboBongo?

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

As far as GTK+ is concerned, if it wants to provide a text combo box
it should use Jonathan's model/view tree-table thingy:

	- It should get UI behavior right.

	- It is model/view, which is a Good Thing.

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

Umm, not really.  IMNSHO option menus are butt-ugly.  They are also
inconsistent with what users are used to, i.e. Windows-like read-only
text combo boxes.

And they don't scroll.

And even if they did, they would ordinarily not have the nicety of
letting you press a letter to move to the first/next element that
starts with that letter.

So, I think a read-only text combo box is the right thing to use.

> I also looked at QComboBox. QComboBox as I said doubles as an option
> menu. It can't contain arbitrary widgets; like CList, it contains
> text, pixmap, or pixmap with text. 
> 
> One useful feature it has is:
> 
>  enum Policy { NoInsertion, AtTop, AtCurrent, AtBottom, AfterCurrent, BeforeCurrent }
>  virtual void setInsertionPolicy ( Policy policy );
> 
> So you can set where new items appear (presumably if the user enters a
> string, this controls where the string ends up in the history).

This is useless, since it does not apply to a model/view scheme.  It
is up to the controller and the model to decide where new entries go
in the list.

> It also has these which look useful:
> 
>      // like the Internet Explorer location bar I assume
>      virtual void setAutoCompletion ( bool ) 
>      bool autoCompletion () const

Up to the particular type of combo box.

>      // allow duplicate strings in the list
>      void setDuplicatesEnabled ( bool enable ) 
>      bool duplicatesEnabled () const

Up to the model.

>      // put a max size on the history
>      virtual void setMaxCount ( int ) 
>      int maxCount () const

Up to the model and the controller.

> Some reworking of the existing code is likely good before a GTK merge,
> I guess my current sense is that an abstract base similar to
> GtkComboBox is useful, and that the two subclasses in GTK itself
> should be an editable text combo with auto and/or tab completion, and
> a select-from-a-grid-of-widgets combo where a grid of GtkImage will be
> the most common use and we might have convenience functions for that.

We can probably use Chris's EReflow stuff for this.  It is pretty
nice.

  Federico