Re: combobox 01122001

[Havoc Pennington <hp redhat com>]

Kristian Rietveld <kristian planet nl> writes:
> 
> I updated my CVS gtk+ today, and it broke the GtkComboBox. So I fixed
> those issues and here's a new snapshot. It should now compile properly
> against the current HEAD branch.

Heh, it broke again. ;-)

Some comments anyhow. Sorry to take so long to respond; really
busy. :-(

For these "select" signals:

  void  (*select)        (GtkComboBoxText   *cboxtext,
			  const gchar       *string);

I think it's better to be consistent with OptionMenu and Entry, and
just have "changed" with no arguments. Then people call get_selected()
to get the current text.

What is the autocompleted signal used for? I'm not sure of its
purpose:

  void  (*autocompleted) (GtkComboBoxText   *cboxtext,
			  const gchar       *string);

I feel like we probably already discussed it, but I'm still in the
dark what this function is for:

void       gtk_combo_box_text_remove_matches       (GtkComboBoxText   *cboxtext,
						    const gchar       *pattern);

I have a feeling if I looked in the archives I'd see a rationale. ;-)

It doesn't compile at the moment, so I'm not sure if this is
addressed, but a usability issue Owen brought up: for GtkCombo, you
can click the dropdown arrow and hold down the button, drag into the
dropdown, and release, just as you can for a menu. Maybe it should do
that. Hard to implement though.

Also, chatting around the labs Owen still expressed misgivings about
the right thing to do on the combo box. The issue is basically: should
we have a new widget that is an option menu, but does not expose the
use of GtkMenu, and according to the theme can look like either an
option menu or a Windows-style non-editable combo. If we do have that
new widget, should we still have this combo box.

Some thoughts:

I think we are fine with GtkOptionMenu for now (especially in its new
de-uglified form, not yet merged to CVS, but available as the
"Raleigh" theme). Also the option menu has acquired a "changed" signal
so isn't hell to use like it used to be. So I'm not sure this widget
urgently needs replacing; at least until we really have a lot of
Windows users, making the option menu able to look like a combo isn't
a huge priority. And I've even seen a few option menus in newer
Windows stuff, such as the Visual Studio .NET beta, which may indicate
they are themselves moving away from using combos here.

Since we need an entry-with-autocomplete-and-history widget anyway,
I think regardless of the option-menu-vs-combo debate we should have a
ComboBoxText. This is a pretty useful widget.

Arguably, ComboBoxGrid should be done in an option-menu kind of
framework instead of the combo
framework. i.e. gtk_option_menu_set_grid() or something. This would be
more Mac-like. In that case, it's possible we'd regret the GtkComboBox
base class and ComboBoxGrid. However, they are small widgets and
almost certainly useful, and we aren't going to get this done in the
option menu framework for 2.0.

One issue is that we probably can't implement the autocompletion
feature on GtkEntry by 2.0. It's a pretty complex/tricky UI. Maybe we
could, but it will be tough.  That would render ComboBoxText kind of
lame, with just history and no completion, I would guess.

Perhaps we could do 2.0 autocompletion in a relatively stupid way
instead of the spiffier way newer web browsers are using, and change
it later. e.g. it could just be tab completion for now and become real
autocompletion later, or it could use the cheesy
select-the-autocompleted-part hack.

Anyhow, I think our options are:

 - put your current work in 2.0 very soon, implement very 
   simple autocomplete in GtkEntry, and consider 
   nicer autocomplete plus a GtkOptionMenu replacement in the 
   future

 - Consider stripping ComboBox base class and ComboBoxGrid, 
   then having only ComboBoxText and a snazzed-up option menu 
   with grid layout and ability to look combo-like; probably 
   pushes us into the 2.2 timeframe

 - Postpone decision to 2.2, possibly doing the nicer autocomplete 
   for 2.2 before we put in the new widgets

Just to inform you on 2.2, it isn't fully decided what the plan for
that release will be, but I am personally arguing for a quick release
that just adds widgets/features (icon list, file selector, Unicode
regexes, etc.) while keeping the library source and maybe even binary
compatible. So we could easily move GNOME from 2.0 to 2.2 without a
bunch of hassle and get new widgets we didn't have time to implement
for 2.0.  If we did that the release would be in a 6-12 month
timeframe, one would hope.

There's some disagreement on that plan, so it's not written in stone,
but I'd like to see it.

My personal inclination on this would be to go ahead and get these
combo box widgets in 2.0, because I think they're simple enough that
they should be manageable, and it seems like people would use them.  I
think it's OK if they aren't too snazzy UI-wise for now, e.g. the
click-hold-down-and-drag-to-select behavior and really nice
autocomplete could be implemented for 2.2.

Havoc