Re: Thoughts on combo replacement

[Jody Goldberg <jody gnome org>]

On Wed, Mar 20, 2002 at 11:33:52PM -0500, Owen Taylor wrote:
> 
>     Non-editable combobox
>     Option-Menu
>    The choice between the two styles of display, if we offer it at all, should
>    be a theme preference.
There are 3 differences that come to mind.
    - Support for table style content
    - Supporting searching/jumping to the next item in the selection
      based on a key.
    - It is sometimes useful to select more than 1 item in a combo.

Nothing precludes option menus from supporting them, but it does not
seem like an ideal fit.  The notion of 'non-editable' is also
somewhat flexible.  A standard text combo that limits the selection
to items in its list can still be editable.  eg a font name
selector.  The user may want to type the font name, rather than
scroll through some large list.  On many systems they even go so far
as to display the font names in their respective fonts, resulting in
serious performance degradation (windows & kde).  In those instances
there is definite incentive not to use the list/menu.

Undo/Redo combos are a good example of the multiple-selection case.
The user selects all items from the top to the lowest item they want
to redo.  That presuposes that you can only undo commands
sequentially, I've heard that emacs supports selective undo. which
would complicate things even further.

>  * While the gal combobox code supports arbitrary widgets in the drop down
>    portion, I don't think that is actually useful. The only use of it I've
>    seen is in the color-combo, where you have a bunch of colors and a 
>    GnomeColorPicker for a custom color. But the GnomeColorPicker effectively
>    acts like just another menu item, so I don't see any requirement to have
>    a widget for it.
In that case the contained widget is not the colour picker.  That is
a child of the real content, the ColorPalette.  This is to my mind
one of the key features of the colour picker arrangement in gal.  In
some places we use a colour combo, in others where there is more
room, we can use a full palette.  The same widget is used in both
cases.
 
On a related note, the 'history' associated with the colour-palette
is a colour-group, a collection of just the custom colours selected.
The groups are named and sharable.  Thus the history in the toolbar
is the same as the format dialog.

>    Supporting arbitrary widgets causes problems:
>     - It will compromise the ability to control the exact behavior of navigation
>       (especially keynav) in the drop down portion.
If the implementation supports a single child as content then it
seems like this is a non-issue.  The child is responsible for
implementing keynav.
 
>     - It means you can't make switching between menus and "lists' a theme option.
This seems like a fairly weak feature in comparison to what we'd be
giving up.

>  * On the other hand, supporting grids of items (colors, patterns, tools, symbols)
>    is definitely a necessary feature. 
This is a definite requirement.
 
>    There are two levels of grid support... supporting regular grids, and supporting
>    grids with row/column spanning. (The color combo used by gnumeric uses
>    has the color-picker item span multiple columns.)
There 2 spanning elements in there.
1) The custom colour picker
2) The optional 'auto/default/clear' button.

Obviously there is not absolute requirement that these span, but it
makes things a whole lot clearer to explain what they are.  Trying
to squeeze the word 'Clear' into the same size as a colour swatch
seems rather limiting.

I should mention that I'd like to extend the colour-palette to wrap
it in a notebook with tabs to 1 side, to select different palettes.
This is trivial when the combo has a single child.  We need only
modify the child.

>  * As far as the non-menu part of the combo goes, the possibilities I'm aware
>    of are:
>     1a) Display of the currently selected item in the list, not a separate control.
>     1b) Display of the currently selected item in the list,
>         as a button you can click on that does something other than pop down
>         the menu/list.
Thngs like colour selectors blur this line.  They display a standard
icon to designate what they are, and they display a colour swatch to
show the currently selected colour.
 
>     2a) An independent view-only widget, not a separate control
>     2b) An independent interactive widget.
> 
>    An important special case of 2b) is an entry, which you may want to interact
>    with the items in the drop-down list - possibilities include:
>  
>     - Non-editable entry, selects items from the list in response to input 
>       (quite possibly be keynav features for 1a?)
> 
>     - Allow the user to enter arbitrary text, but then restrict it to an
>       item in the list on focus out. (GtkCombo supports this somewhat
>       dubious functionality.)
The GtkCombo approach to this is unusable.  There is a custom
version in gnumeric that is far more paletable.  Several issues
arise here.

1) how selection is handled while draging through the list.  There
are cases where you want the selection to be made as you drag, and
others where it should not be changed until the user explicitly
activates.

2) It is useful to be able to control how the list is searched for
key movement.  eg while the list is displayed hit 'b' to jump the
1st/next/prev element that start with 'b'.

3) You need to optionally permit selection of an item not in the
list.  With additional control of whether to add the item to the
list or not.

4) Entered text sometimes  needs some degree of massaging.  For the
zoom combo, the user may type '100' but we need to match that
against item '100%', and display '100%' in the entry.

>     - Completion against items in the list (but note that completion is really
>       a separate and more complex issue... both Mozilla and IE make
>       the completion dropdown different from the history dropdown; the completion
>       dropdown displays only current completions, will complete match
>       www.gtk.org against http://www.gtk.org in the history list and so forth.)
I'd recommend against even thinking about completions for now.  Trow
and others spent alot of time working on that for evolution's
address book.  The set of hooks necessary to do it right is a
significant discussion (I've CC trow)
       
> API thoughts
> ============
Before we start on api, I'd like to revisit the decision to make
things into menus.  That seems fundamental.