Re: GtkTreeView discussion

Hi Jonathan,

I have some comments to make, although I don't know GtkTreeView much so
bear with me.  :-)

> 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

I don't know what "activation" means in the GtkTreeView world.  Does it
just mean selecting a row, moving the keyboard focus to a row, clicking
on a row, or all these things at once?  (I looked at the documentation,
and I couldn't find a clear explanation.)

In any case, I don't understand why you would want this to be

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

I think this is also a bad idea, since it introduces more
inconsistencies between applications.  Expansion should only happen when
the arrow is clicked; that's a standard GUI behavior that should not be
overridden on a per-app basis.

>  * Drag: Drag selected rows.  

I am not sure what this means exactly, but I think a drag operation
should *always* drag all the selected rows -- that's just the way a
tree/list widget is expected to work.

> Drag only certain columns.

What is this about?  I can't think of an example of when you would want
to use this.

>    current interface is model based, and possibly needs fixing.  Campd
>    made a compelling argument for doing this view based.

This one I fully agree with.

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

This sounds like a must have...

>  * Selection: Current behavior, rubberband selection, click-and-drag
>    selection (like the clist used to have in BROWSE).

This also sounds like an added inconsistency that is not worth the
time.  Selection should work predictably across all the apps.

If you want click-drag selection to work, then it should *maybe* happen
only automagically when drag and drop is not enabled for the widget and
the widget is in multi-select mode.  Surely it should not be left to the
app to decide.

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

AFAIK, in Cocoa if you mark a cell as "editable" double-click on the
cell edits it, or at least that's the default behavior.  In those apps
where double-clicks opens the item (like the Finder), slow double click
triggers editing.  (I don't know what the current GtkTreeView is.)

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

This sounds to me like a sign that neither (mis)feature should be
implemented.  :-)

> 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 agree they both sound messy.

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

This would sound slightly better, but I still don't see a compelling
case for customizing the behavior of the widget besides the basic
allow-single-selection/allow-multiple-selection choice (which, I assume,
is already there?).

-- Ettore

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]