Re: thoughts about improving GtkTreeView: better selection interaction

[Kristian Rietveld <kris gtk org>]

Hi,

On Sat, Apr 05, 2008 at 12:45:51PM +0200, Christian Neumair wrote:
> This mostly affects rubber band selection, where we cannot selectively
> allow rubber-banding where the(i.e. only for background areas).

Indeed, this is all handled internally for now.  I think that
unselecting all and starting rubber banding are both "bound" to the same
action.  So basically solving this will give us a proper unselect
functionality and better rubber banding support in GtkTreeView.

> That said, we either need a way to simplify further custom application
> hacks, or move complex selection interaction scenarios to the
> GtkTreeView level.

Probably a blend of both, even for implementing the proper selection
interaction scenarios at the GtkTreeView level we will need some code to
simplify this ;)

> 1) All but one column is treated as background area
> 
> Regarding clicks, this can be implemented by applications as of writing,
> by catching button-press-events and treating clicks to other than an the
> column as if no path was clicked.
> 
> However, the rubber banding selection is not aware of this. Also, it may
> be advisable to only highlight the first column for selection.

As far as I can understand now, this is really like the Windows
explorer.

> Issue 1: Who should receive a button-press-event click if cell renderers
> that allow mouse interaction are packed into columns that are used for
> BG interaction?

Then those cell renderers that require interaction would still have to
get these events IMHO.

> Moving keyboard focus to cell renderers in BG columns also does not seem
> to be useful.
> 
> For developers, this may yield a convenient API like
>   gtk_tree_view_set_selection_column()
> which would promote only one column as column for selection interaction.

Such an API might work.  However, I am not yet sure how and if this will
fit in the current "behavioral model" for GtkTreeView.  We would have to
check what has to happen with column reordering, DnD, etc, etc.


> 2) All the padding space of the cell renderers is treated as background
> area
> 
> Implementing this may be a bit more tricky, but it will not have the
> issue of concurring button press event recipients.

This can indeed be tricky, but maybe less tricky than option 1).
Actually this is something that I think needs to happen anyway, there
also is a bug open about it:
http://bugzilla.gnome.org/show_bug.cgi?id=350618

Personally I prefer this option.  As said above, getting this done will
give us both the unselect functionality and better access to rubber
banding in the stock GtkTreeView widget.  It might help here if I
backport my gtk_tree_view_column_cell_process_action() changes from my
local tree view branch to upstream.  This code might greatly simplify
the implementation of this.

I do not have time to directly dive into this, but I will put it high on
my list.


regards,

-kris.