Re: Thoughts on combo replacement
- From: Havoc Pennington <hp redhat com>
- To: Jody Goldberg <jody gnome org>
- Cc: Owen Taylor <otaylor redhat com>, gtk-devel-list gnome org, kris gtk org, trow ximian com
- Subject: Re: Thoughts on combo replacement
- Date: 23 Mar 2002 10:36:10 -0500
Hi,
Random thoughts and questions -
- if you have a widget like the GAL one, which is just
"set the click widget" and "set the dropdown widget", it's
fully generic but also not all that useful for simple apps.
you always have to implement a bunch of stuff yourself.
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.
In GAL I guess there's a pixmap and a text subclass, etc.,
as Kris was originally working on.
- 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 "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. I don't want to provide
a combo if it forces app developers to decide between two
platform L&F, I want to see option menus on UNIX.
Ideally I suppose GtkOptionMenu would just be opaque enough that we
could do this there, and then GtkNewComboThing could be a separate
widget.
- To me the completion/history stuff is probably a GtkEntry feature.
Like gtk_entry_set_completion_funcs() or something. Or
alternatively we have a GtkCompletionEntry widget. Anyhow it
doesn't seem like part of the combo problem to me.
- You say some combos may only allow choosing from the fixed list,
but still should be editable so you can type instead of popping
up. I don't understand why this would be true of some combos
vs. others; to me the keyboard shortcuts should always be the
same. If we want magic-search-by-text then it should be available
in all combo/optionmenu thingies, right?
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.
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?
(I'm not saying there's not a good reason, I'm just wanting to
understand it. As a user, how would I know which thing to expect?)
- For "how the selection is handled while dragging through the list"
- can you give concrete examples of when you want this to
be different.
- 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.
- 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.
Basically it's just that if you choose one item it happens to also
undo everything up to that item. This isn't really multiple
selection - in fact with the current behavior of GAL combos
multiple selection is impossible, since as soon as you click
anywhere the thing pops down.
- I wonder where Word/Excel XP have gone with this whole thing.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]