Re: GtkComboBox design issues

[Havoc Pennington <hp redhat com>]

So, summarizing my answers to these, maybe others will disagree though:

Kristian Rietveld <kristian planet nl> writes: 
> 1. The GtkComboBoxText now uses the 'standard' GtkTreeModel. I think this
> isn't the right one, and it should use ListStore or the new TreeModelSort
> instead. But which one? Do we want sorting or not?
> 

If we follow Mozilla, we should maybe use GtkMenu for this.

Even if we use ListStore, I would just use the unsorted one, and let
people get the strings, sort them, and set the strings, if they want
it sorted. That will be faster than the TreeModelSort anyway for the
size of list we're talking about, and use less memory and just be
simpler all around.

> 2. Owen told about the issue of duplicates in his mail of Oct 26. I think
> this problem only applies to the GtkComboBoxText. Having the same
> GtkWidget on the grid of the GtkComboBoxGrid twice isn't possible. But the
> question is: Do we want duplicates or not? Do we want an option to switch
> the allowance of duplicates on/off?

If the widget is designed for autocomplete I would say that duplicates
don't make any sense and the API should use string values not
indexes. I don't think an autocomplete widget in the Mozilla/IE6 mold
is remotely sane as an option menu.

I guess we _could_ have the noneditable mode, where autocomplete never
appeared, but... if we use GtkMenu for the dropdown, it's hard to see
the advantage of this vs. the option menu anyway.

> 3. Which kind of {tab,auto}completion do we want in the
> GtkComboBoxText? It now has tabcompletion when typing and it'll try to
> autocomplete if the user presses enter.

I like the Mozilla style, assuming you can make it do less popping up
and down (keep it popped up while typing instead of constant
flicker). Tab should move focus between widgets by default. We could
have an option to use tab for completion.

Havoc