Re: Thoughts on combo replacement



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]