combo rant

[control H <control h gmail com>]

I'll start with apologies for upcoming rant. In general I like Gtk:
I'm programming with it for a couple of years now and it's easy to
learn, reasonably fast, has many bindings, runs on windows, and is
highly themable. However, an ever returning frustration for me is the
lack of a decent combobox. With every release of Gtk I hoped for a
better combo, but to be fair, GtkCombo is in some ways still a better
option than GtkComboBox.

I notice several problems, that don't seem to be solved soon, if at
all. Since I don't understand the inner workings of Gtk and I also
don't have time for that, I'll write to this list with the hope that
something will change, or at least that I know _why_ it is the way it
is.

1. Could someone please explain to me why we don't have a gtkcombobox
   widget that's comparable with the Windows one or QT's combo? Please
   give me at least a good reason! I'll address some specific things
   now:

2. Popup behaviour. Lots about this is already in this thread:
   http://mail.gnome.org/archives/gtk-devel-list/2005-March/msg00149.html
   I can only agree. For me, the most important things are the
   direction of the popup, and the size. Because of screenspace menus
   are sometimes poped up above the widget, sometimes below, therefore
   covering information you just filled in those widgets. A function
   where you can specify the popup behaviour would be nice, eg
   gtk_combo_box_set_popup_direction(DOWN) or
   gtk_combo_box_set_popup_direction(SELECTED) for current behaviour.

   When I make a multi column combo it already behaves much more the
   way I'd like to.

3. Default mode (so no "apears-as-list" mode) pops up the menu with
   the current selected item at the location (height) of the widget
   itself. If an item from somewhere of the midle was chosen, the menu
   appears both above and below the widget. If you don't know what I
   mean, start gimp and save something. The filetype (extension)
   selection shows this problem. Also, when the active item was near
   the beginning, you already see the full height of menu list, with
   some "scrollbar-like" thing on top and bottom. Not only does that
   look bad, it's also quite useless, because you'll almost by
   definition want to scroll down, therefore "filling" the menu; it
   could have shown all items imediately. When the menu is filled with
   all options, these scroll things disappear. If you have so many
   options that they can't fit on the screen, these scroll things
   remain.

   Since these scroll things are not a scrollbar, you can't quickly
   drag the bar and go quickly to the item you're iterested in. So,
   why not make
   A) a scrollbar like in treeview, or
   B) make long items branch like in windows

4. In "apears-as-list" mode, again te popup direction and size are a
   problem. This time we have a scrollbar however, so a function where
   you can specify the maximum number of items before forcing a
   scrollbar would be nice. Just like in html. I think this really
   should be possible. Others want this as well:
   http://mail.gnome.org/archives/gtk-app-devel-list/2004-June/msg00342.html
   Unfortunately, nobody gave a reaction to this. I really hope at
   least someone will share his thaughts about this.

   I know I know, the Gnome Human Interface Guidelines say that with
   many items a treeview selection may be a better solution, but I
   disagree. There are just too many situations where you want a
   single row widget where you can select from, instead of a space
   consuming treeview. Even the big Gtk examples are suffering from
   this problem: I already mentioned Gimp, but also Dia (realy
   obvious), Gnumeric (has its own combo, eg the font selector) and
   gftp (still uses the deprecated GtkCombo).

   On with the problems:

   A When you click in the textbox (and not the arrow), you have to
     keep mouse button pressed
   B When you click the double arrow and just start typing for
     completion you have te type enter twice. In my opinion one time
     should be enough, even in the situation where there's no match
     (just return currect selection)
   C The width is not optimal. When showing the list it should use the
     width of the biggest item, or provide a horizontal scrollbar if
     necesary as well

OK, this is a lot of text for maybe not-so-important details. But
these details are annoying. And I suspect I'm not the only one. Please
give some reaction and possible solutions.

Thanks a lot.