Re: GtkTreeView discussion

[Kristian Rietveld <kris gtk org>]

On Fri, 2003-03-14 at 23:24, Jonathan Blandford wrote:
> [ 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. ]

Sorry for my totally late reply.

> 
> 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.

Agreed.

> 
> 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.

We might need to block the user from overloading actions, for example
choosing double click for activation and double click for expansion. Or
maybe we shouldn't care and just blame the user.

> 
>  * 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.

Maybe we also want to distinguish single and multiple item DnD.

> 
>  * 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.

I already volunteered for implementing both rubberbanding and hover
selection. I don't know if having click-and-drag selection is useful
when we have rubberbanding already.

> 
>  * 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.

We need a set of different editing behaviours, dependent on the
situation. I think we need to make a table with possible use cases and
figure out which kind of behaviours we need. An example is the
keybindings configuration dialog.

> 
>  * 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.

I am not sure whether this should be a mode. I think this should just be
a feature which you can turn on/off in the API.

> 
> 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.

I am not really happy with any of those.

> 
> 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).

Yes, I think having the "view" being a bitmask of "modes" is nice. So
you can either select a view or OR a few "modes" together (a user
defined view).

> 
> 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.

Users misusing the modes API can be pretty dangerous. We can build in
some protection, but not much. It might be nice to have a section in the
HIG about using TreeView modes or something like that, so we can
maintain consistency among the TreeViews used inside of GNOME.

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

Indeed, the modes API is really needed for some the of other TreeView
features which we want to add.


thanks,


	-Kris

> 
> Thanks,
> -Jonathan
> 
> [1] I'm personally terrified of this.
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list