GtkTreeView discussion

[Jonathan Blandford <jrb redhat com>]

[ As some background, Dave and I met for lunch yesterday and had a long
  discussion over what we want to do w/ the TreeView.  Here are some
  notes from that meeting. ]

GTKTREEVIEW MODES:
==================

1. Rationale.

Throughout the history of the TreeView, we've kept running into trouble
specifying the behavior of the widget.  By limiting ourself to one
behavior set, we don't work wonderfully in a large number of use cases.
As a result, applications have been doing evil things w/ events to get
the behavior they want (eg. nautilus, or as threatened by evolution).
And, while bending over backward to provide all kinds of behaviors is
wrong, the one-size-fits-all[1] approach we currently have is also
wrong.  Indeed, by describing it this way we ignore the fact that
applications do have some latitude over DnD and selection.

2. Feature requests:

Here's a list of possible behaviors that people have requested over
time.  It's a little muddled -- hopefully further descriptions below
will clear it out

 * Activation: activate on single click, double click, or not at all

 * Expansion: Expand on selection, expand on double click, or expand
   only when the arrow is clicked.

 * Drag: Drag selected rows.  Drag only certain columns.  Also, the
   current interface is model based, and possibly needs fixing.  Campd
   made a compelling argument for doing this view based.

 * Drop: Have a distinction between dropping on the name and the blank
   area, and on the actual row.

 * Selection: Current behavior, rubberband selection, click-and-drag
   selection (like the clist used to have in BROWSE).  Also, need a way
   to possibly do hover selection, both instantaneosly for the Combo,
   and delayed, for things like nautilus.

 * editing: Currently, the behavior for editing confuses users.  I'm not
   100% sure how we should fix it, but we should at least see how other
   toolkits do it.

 * ruled rows: Already exists.

 * tooltips: I'd like to add support for custom tooltips of rows.  Also,
   I'd like a way to complete the current renderer if it doesn't fully
   fit.  Haven't thought this one fully through.

3. Setting the tree.

So what's the question here?  It's largely one of API.  I can see us
adding these features as time permits over the next couple GTK+
iterations, without any large plan.  This is dangerous, as the features
interact in unexpected way.  For example, as described above, I might
add a call like:

 gtk_tree_view_set_activations_style (GtkTreeView *tree_view, GtkTreeViewActivationStyle style);

which would let me set double_click to activate the row.  How that
interacts with setting double_click to expand a row is unclear.

A possible alternate API is to focus on the events themselves.  Ie, have
an API like:

 gtk_tree_view_set_double_click_action (GtkTreeView *tree_view, GtkTreeViewDoubleClickAction action);

This is nice in that it deals with possible conflicts of settings by
tying only one behavior per user action.  It however, is messy, as not
all actions are well defined.  I'm not really happy with the thought of
adding a call like:

 gtk_tree_view_set_click_and_drag_when_on_certain_column_contents_action();

To handle the drag-only-items case that nautilus wants.

4. A possible third way

As an alternative, we could lump all the behaviors into one
uber-mode and set that.  Possible behavior sets I see are:

 * Selection view: Used for selecting a subset of items from a given
   set.  An action is then performed on them.  Example: Windows toolbar
   editor, Nautilus list-view

 * Control view: Used to control another thing.  Example: The old
   control-center list, Mozilla preferences dialog.
 
 * Activation view: Used to activate an item.  Example: the gaim
   buddy-list dialog.

 * Editing view: Used to edit a set of data.  This is possibly a case
   for a GtkTable widget.  Example: Mr. Project main view.

 * Data display view: Used to display a set of data.  Selection is only
   used to highlight a particular row.  Example: I vaguelly recall
   gnumeric had something like this.

There are prolly other possibilities.  Setting the mode to be one of
these would be equivalent to setting a preset number of options (ie,
data display view would turn on rules hint, turn off any special DnD
handling, prolly not bother w/ activation, etc).

It is tempting to implement it like this, without providing a public API
for the other features (with the exception of the current, existing
ones).  This would help prevent the explosion of possible treeviews that
end users might run into, and also limit weird interactions we'd have to
look out for[1].  Still, I'm a little concerned about limiting ourselves
to unpopular modes, and not letting people do what they want.

I'd appreciate any thoughts on the matter, as I'd like to add some of
these features early in the 2.4 cycle.

Thanks,
-Jonathan

[1] I'm personally terrified of this.