combo rant
- From: control H <control h gmail com>
- To: gtk-list gnome org
- Subject: combo rant
- Date: Sat, 19 Nov 2005 23:17:07 +0100
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]