Re: GtkComboBox design -- first draft

[Owen Taylor <otaylor redhat com>]

Jody Goldberg <jody gnome org> writes:

> On Sun, Mar 31, 2002 at 02:47:19PM +0200, Kristian Rietveld wrote:
> > On Sun, 2002-03-31 at 05:15, Jody Goldberg wrote:
> > > 
> > > I'd prefer to see the base class and the dropdown content be kept
> > > distinct.  A treeview based list seems nice for list type combos,
> > > but could we not keep that in a derived class ?
> > 
> > The point is that we want to have both menu-style and list-style in the
> > same widget, with the same API. A style-property determines whether the
> > menu-style or list-style will be used. Because of this we can't put the
> > list-style combo in a derived class.
> 
> IMHO the selection of list vs menu applies to a subset of combo
> boxes.  Which is why I'd like to see it and its api in a derived
> class.

This, of course, brings up the somewhat philosophical question of
"what is a combo". About the only commonality between all the
examples that have been raised so far is that there is a widget of
some type with some type of arrow next to, or on it that, when clicked
on causes some type of popup.

If this all the commonality we want in the base class, well, then
all the base class will be doing is providing a consistent way
of drawing the widget before the popup is shown.

 - It can't do the popup widget, if you want to allow menu
   implementations of the popup.

 - It can't do the event handling, because if you want to
   do click-drag-release handling, you need an intimate 
   knowledge of how the widgets in the popup work.

Myself, I don't consider this a particular useful place to
start, because most types of "combo" actually share a lot
more commonality than this.

The definition that appeals to me is:

 A combo is a widget, usually used to display the current selection,
 paired with a popup allowing selection between a set of
 of possible choices. When a choice is selected, the popup
 pops back down.

A lot of the elaborations that have been discussed fall into
this scheme, even if they may be troublesome to implement
with some ways of drawing the drop-down.

 - Allow the popup to be torn off

 - Put a notebook into the popup to allow multiple pages
   of selections arranged in a hierarchical fashion.

 - Display the selection of item N as the selection
   of items 1-N. (Note however, that I don't really
   consider the "undo combo" a combo, since it's not
   about selecting between alternatives, but about
   immediate actions. It, in other words, is just a menu.)

Some things don't fit into this scheme:

 - The drop down GtkCalender in GnomeDateEdit

 - Popdowns allowing multiple selection, and an explict "OK" 
   to pop back up. (Use a dialog!)

But these things simply aren't going to be able to behave
or appear like the rest, and won't share any significant
API with the rest either; I don't consider handling these
things important, if they are, then we need are hierarchy
to be:

                 GtkComboButton [ Just draws the arrow ]
         /                              \
        /                                \
 GtkComboView [ selection between items ] GtkDateCombo  .....
 

What, we, need to avoid, in any case, is:

 - I don't like menus, so let me set my widget to look
   like a list.

 - I want "combo + 1-N selection" and 1-N selection
   can't be drawn as a menu, so I'll use a list.

 - I want "combo + grid of items" and a grid of items
   can't be drawn as a list, so I'll use a menu.

If it's true that there are so many variants in how the
popup can work that it's impossible to abstract to
the point of hiding the difference between a list and
menu, then we can't offer the choice just for some
types of popup, we have to forget the choice and pick
one for a combo to draw and interact which will work
for the variants that we care about.

But note, that if we do let people just put whatever
they want in the popup and have a "style guide"
as how it should look and behave, details of
of mouse and key navigation are not going to be 
particularly consistent between different "combos"
people create.

Regards,
                                        Owen