Re: GtkComboBox design issues
- From: Havoc Pennington <hp redhat com>
- To: Nils Barth <nils_barth post harvard edu>
- Cc: Calum Benson <calum benson ireland sun com>, GTK Development list <gtk-devel-list gnome org>
- Subject: Re: GtkComboBox design issues
- Date: 18 Nov 2000 02:15:08 -0500
Nils Barth <nils_barth post harvard edu> writes:
> That's kinda unclear; let me explain:
The behavior you explained seems pretty sane to me. I guess this is
pretty much the way Mozilla works also, as far as I can tell. The only
thing that annoys me about Mozilla's completion dropdown is that it's
really flickery and distracting, it keeps popping up and down. I'd
kind of rather it only disappear when there are no autocompletes,
right now it seems to disappear whenever you press a key only to
reappear after a short timeout. How does IE6 do that? Do the
autocompletes disappear on any key press?
There are some somewhat tricky implementation issues here. It adds a
second dropdown - there's the normal combo dropdown, and the
autocompletions dropdown with only the currently-possible completions.
When the autocompletion dropdown is visible, it will probably have the
GTK key focus, but key presses other than arrow keys will need to get
forwarded to the entry.
Possibly the autocomplete dropdown should be a GtkMenu instead of a
TreeView, in Mozilla both the combo dropdown and the completions
dropdown appear to be menus even. I guess that's possibly correct
also.
I would say that Tab should move focus by default, since Ctrl-Tab to
force a focus move is pretty obscure, and we don't want people to get
trapped in the combo widget.
It seems to me that if the widget is designed for autocompletion, it
really shouldn't allow duplicate entries in the dropdown. This
autocomplete widget seems fundamentally different from an option menu;
Qt allows the duplicate entries because its combo can be used as an
option menu. So I'd think the API which works with string values
rather than indices and doesn't allow duplicates is the best one.
Wow, I bet Kristian is really confused at this point. ;-)
> This leaves one question: what happens to the cursor if the user goes
> into the drop-down menu when they're not at the end of the string?
> I'm tempted to say ``Move it to the end of the string (right before
> the selection)'', though this may have problems -- thoughts?
In Mozilla if you move the cursor off the end of the string, the
autocomplete menu goes away.
> (just kidding -- actually, is the form box in a drop-down the same
> text widget that Havoc's been hacking on?)
No, it would be a GtkEntry, which only allows a single line of input
and is quite a bit simpler because of it.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]