Re: Thoughts on combo replacement

[Jody Goldberg <jody gnome org>]

On Thu, Mar 21, 2002 at 03:30:58PM +0100, Kristian Rietveld wrote:
> 
> I think we always want the menu to be beneath the widget. The optionmenu
> menu always appeared over the widget. We also need to decide whether we
> want a double or single arrow. If the menu or list always appears
> beneath the widget, then we need to go with a single arrow pointing
> downwards IMHO.
Agreed, on both counts.
Can option menus be torn off ?
 
> Having a combobox with entry and history, with the history in a menu
> looks weird IMHO. We definitely need a list there. But we definitely
> need a menu for a color picker combo. I'm not really sure if making
> menus/lists a theme option is a good idea.
A simple pixmap grid can be seen as a menu.
I tend to think the colour combo is more complex.  The gal version
supports
    - a shared history for just the custom colours
    - an optional 'default/auto/clear' button
and will potentially support multiple palettes via a notepad.  This
is more that what comfortably fits in my idea of a menu.
 
> I think different programs want different completion algorithms. So we
> may have to create some API to change the completion function, and
> provide a default one.
Definitely.  Judging by the amount of time Trow and others spent
working on this, I suspect it is non-trivial.
 
> For combo widgets using a menu we can write some code to fill a menu
> with items from the GtkTreeModel. Though we need to add some API or an
> algorithm to set the number of columns/rows for the grid and to do
> row/column spanning.
Rather than trying to manage the structure of the content at the
combo level, I'd prefer to have a single arbitrary child as the
dropdown for the combo (ala gal).  That gives us the flexibility to
use a Table or TreeView as the content if so desired, without having
to dable in GtkMenu.

> >  * Is the idea that "every thing acts like a menu item" sufficient?
Not to me.
 
> I think it is for most cases. Though IMHO using menus in 'browser-style'
> combos is ugly.
Although office style apps may be limited in number I suspect that
the types of combos we're seeing are a reasonable cross section of
what people have come to expect from any document type app.
    - colour pickers	(foreground/background/line)
    - pixmaps pickers	(border style, line style)
    - undo/redo 'stack' lists
    - text lists that allow elements not in the list (zoom, font size ?)
    - text lists that do not allow elements in the list (font name)
For text based lists some degree of control is required for
    - when the selection changes (immediate, on activation)
    - how to massage user input into list items
    - how to walk the list when an alphanumeric key is pressed

> >  * Is row/column spanning for gridded items necessary?
> I don't really see where this can be useful.
My preference of seeing 1 child removes the need to consider this.