Re: Thoughts on the ComboBox framework

[Owen Taylor <otaylor redhat com>]

OK, I've taken some time to read through the proposal, and
have various thoughts.

As an advance disclaimer, what I say below may sound a bit
like a lot of big changes, but I think that's mostly 
cosmetic structure ... in terms of the set of capabilities,
the way they appear in the API, and the general strategy for
implementing them, I think you've just about nailed the 
issues.


Big picture organization
========================

Like Havoc, and I think you as well, I have concerns about
the GtkComboBox base class. I don't think it really represents
what this set of widgets is "about" - it's an implementation
detail and one that you say doesn't even work very well
for all it's descendants.

The basic functionality to me seems to be the idea of
selecting from a list of choices:

interface GtkOptionSet 
{
  int get_current ();
  set_current (int index);  

  signal gboolean activate (int index);
  signal void changed ();
};


Where the default action of activate is to set_current();
and it's the standard boolean-handled accumulator.

This fits your EggComboBoxPicker and EggComboBoxGrid
perfectly, and if you allowed set_current (-1) to
mean no selected item, I think also works for
EggComboBoxText.

But, the above is perhaps more abstract than we need. 
I think it is really feasible to make a base class with meaty
functionality with sufficient scope; my feeling is that
it should be possible to take your EggComboBoxPicker class,
merge in the grid functionality, and call it, say:

 GtkOptionBox

This would have all the EggComboBoxPicker functionality
for manipulating the list of choices, and a simple API
for the current item as above.

 void gtk_option_box_set_sample_widget (GtkOptionBox *box,
                                        GtkWidget    *sample);

would allow flexibility for what is displayed next to the
dropdown arrow. A value of NULL would mean to autopreview
the currently selected item.

Then make EggComboBoxText a GtkOptionBox that has a 
GtkEntry.

(In the rest of this writeup, please read EggComboBoxPicker
for GtkOptionBox if you prefer.. I wanted to save typing
in the API examples.)


Grids
=====

I don't really think there should be the big EggComboBoxPicker
EggComboBoxGrid distinction that you have in the API ...
As you have it, if you want a grid of items, you get an API
that is very much like GtkOptionMenu, if you want one a single
column, you have a completely different API. Yes, perhaps
the windows-style pop-down list can't be done for a grid,
but in that case, we can just make it appear as a menu without
regard to the theme setting.

EggComboBoxPicker is nicely abstract; we shouldn't get rid
of that abstraction just because we have less use of it
for a grid.

The question is how to integrate the grid into the list store
centric API, including row/column spanning. My current best
idea is:
 
 gtk_option_box_set_wrap_width (option_box, n_wide);
 gtk_option_box_set_span_columns (option_box, 
                                  width_column, height_column);

Where, a value of -1 for width_column or height_column means
"use 1 for all" and is the default for both.

Then a simple "topmost/leftmost space where it fits" method
is used to lay things out.

So, that allows you to do:

 gtk_option_box_append (option_box,
                        TEXT_COLUMN, "Spanned",
                        WIDTH_COLUMN, 2,
                        -1);


Convenience constructor for single-text-column
==============================================

I think there should be a convenience constructor for creation
an EggComboPicker with a single text column -

 GtkWidget *gtk_option_box_new_text (void);
 
Then perhaps to avoid having to write:
gtk_option_box_append (option_box, 0, "Foo", -1);

You would have:

 gtk_option_box_append_text (option_box, "Foo");


GtkCellView
===========

I'm not sure GtkCellView should be public at all, but if it 
is, I suspect it should only have the dynamic pull-from-treeview
functionality.

Using cell renderers as a replacement for GtkLabel/GtkImage
just doesn't make a lot of sense to me.

What I'd do for the background color part is simply
have gtk_cell_view_set_use_base() to switch it between
bg/fg and base/text. (I'm guessing this is the use case.)


EggEntry
========

I tend to think that the history features should just be
in GtkEntry. But unlike Havoc, the idea of making the dropdown
arrow and explicit history list part of GtkEntry doesn't
sound right to me. A "has a" GtkEntry relationship feels more
natural for that. (And I could see reasons to make the 
two lists separate ... the dropdown might contain only a 
manageable subset of the entire completion list.)

I'm pretty comfortable with the simple completion model
you have now. The one part that doesn't really feel quite
quite right to me is the way history works. What I might
imagine doing for history is having a single convenience
function:

 gtk_entry_append_history_text (GtkEntry    *entry, 
                                const gchar *text,
                                gint         max_items);

Which, if the completion tree model is a GtkListStore with a
single column, appends the item, and removes the first
if necessary to maintain max_items. In fact, we could
even make this do all the setup for a liststore with
a single column if there was nothing already to make
that brain-dead simple.

But other than that, just leave history maintenance completely
up to the user.

I don't really see how the idea of the idea of a completion
interface is going to work without a lot more complexity 
than what Havoc sketched out.


I'll stop there to keep this mail manageable. I guess the
basic question is whether you (and other people) think
the approach of:

 GtkOptionBox
     ||
     \/
GtkOptionEntry  HAS-A   GtkEntry

Is a reasonable one.

Regards,
                                       Owen