Re: Thoughts on combo replacement

[Jody Goldberg <jody gnome org>]

On Sat, Mar 23, 2002 at 10:36:10AM -0500, Havoc Pennington wrote:
> 
>    at least that's my feeling. So while we could have that 
>    widget involved, we need some subclasses of it that 
>    do more for you (and are correspondingly less generic), 
>    and we need to talk about what those would be.
Agreed.  We definitely need to implement some of the common use
cases.  In GAL we have pixmap, colour palette, and text stack (for
undo/redo).  In gnumeic a nicer version of text selection.

>  - the combo should really allow the click, hold down, and drag
>    selection method; instead of the click, popup, choose option
>    method. Gnumeric 2's combos don't seem to allow this.
The versions in gnumeric could certainly do more.
 
>  - The "make option menu look like a combo on Windows" functionality
>    is really very important.  Otherwise it's impossible to write apps
>    with native L&F on both platforms.
Ahh, that clarifies things.  I'd been reading the thread from the
combo perspective, not the option menu.  If the main goal is to
allow option menus to be combos then your notion of an opaque option
menu seems better than forcing combos to be menus.
> 
>  - To me the completion/history stuff is probably a GtkEntry feature.
...
>    doesn't seem like part of the combo problem to me.
agreed.

>  - You say some combos may only allow choosing from the fixed list, 
..
>    same. If we want magic-search-by-text then it should be available 
>    in all combo/optionmenu thingies, right?
It is only feasible in some cases.  Colour combos, stack combos, and
pixmap combos are obviously not gong to get the magic text
completion.

>    Also, this feature involves the combo widget knowing about the
>    strings, which conflicts with the idea of having just a generic
>    "you can insert a widget" kind of API.
Not really, it just requires a bit more interface between the combo
and the popup window.  Control is also required for massaging the
input string and accepting/declining the edit.  Note: these features
are specific to text combos.

>    Re: controlling how the list is searched - why would pressing 'b'
>    go to the first 'b' in one combo and the next or prev 'b' in
>    another combo, as in your example?
My example was not optimal.  I can't think of a reason the key
searching would be different in different text combos.  What I
remembered was having to implement :
	typedef enum {		/* begin the search from : */
		GNM_COMBO_TEXT_FROM_TOP,	/* the top of the list */
		GNM_COMBO_TEXT_CURRENT,		/* the current selection */
		GNM_COMBO_TEXT_NEXT		/* the next element after current */
	} GnmComboTextSearch;

In the gnumeric text combo.   This seems related not to key
navigation, rather it is used to handle a user entering a string in
the entry.  In the case where there are duplicates in a list (eg the
user is allowed to name 2 plots the same thing) it becomes important
how things are searched.

>  - For "how the selection is handled while dragging through the list"
>    - can you give concrete examples of when you want this to 
>    be different.
Again using gnumeric as an example near and dear to my heart.
    Zoom combo
vs
    Format -> Cell -> Number -> Dates

When dragging the selection in the zoom combo you definitely do not
want the zoom to change until you release.  That is too expensive an
operation to perform in real time.  On the other hand (although it
does not do it now) dragging through the set of canned date formats
should reformat the sample.
 
>  - you say "optionally permit selection of an item not in the list" 
>    - are there applications of this which are not either an 
>    entry with completion or an entry with history.
I'm not sure exactly what you mean by history and competion.  An
example would be a text combo for zooming.  I suppose it could be
considered to have a history, but the most common usage I've seen is
to have a set of canned sizes (eg 200,100,75,50) with the option
for the user to enter something in the range 10-500.  Its not quite
a history in that the list should always be ordered.

>  - In the Gnumeric undo combo, there isn't any feedback that you've
>    chosen or can choose multiple items, except you can see it for a
>    split second as you click just before the thing pops down.
?
You should see all elements from the top down to your lowest
selection in the list (see the supplied screenshot).  Warning! that
combo needs work, there are 2 major open bugs in it right now that
I've got to look into.

>    multiple selection is impossible, since as soon as you click
>    anywhere the thing pops down.
The closest we come to wanting multiple selection is the text stack
combo.  When implementing the undo/redo framework I did some
research and was surprised to find emacs's selective undo
capabilities.  Implementing that would be more difficult than adding
multiple selection to the combos.  I only mention it as a possible
future use case.  I have no idea how to have a user do that without
making combos uncomfortable to use.
 
>  - I wonder where Word/Excel XP have gone with this whole thing.
Good question, I've not seen any changes in XL95, 97 or 2k.  XP may
be interesting.

Another pet peeve that I have with the gal combo is that it does not
pop down until the combo arrow is released.  This is a distinctly
different 'finger feel' from all other systems where the drop down
appears immediately and you can drag you pointer into it.