thoughts about improving GtkTreeView: better selection interaction

[Christian Neumair <cneumair gnome org>]

Dear GTK+ development list,

as Nautilus developers we have been struggling some time with selection limitations of the current GtkTreeView implementation.

There is no simple way to unselect the entire selection in a crowded list view.



In a file manager, you sometimes want to interact with a directory, and not with the files in it. If there are just a few files in the folder, the bottom of the GtkTreeView is not covered by rows. By catching clicks to it, and modifying the view's selection it can be used to unselect the entire selection.

However, as the container becomes more and more crowded, and no blank space is remaining at the bottom, you cannot click the background anymore.

Therefore, it would be nice if there was some way to interact with the background. By clicking the background area,

* all selection is cleared
* range selections can be started
* no selection interaction (drag & drop) is possible

While we have a quite complex "button-press-event" handler for doing most of the selection interaction, we can not control tree view internals.
This mostly affects rubber band selection, where we cannot selectively allow rubber-banding where the(i.e. only for background areas).

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


I see two ways of solving our very specific issue:



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.

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?

[for Nautilus, this is a non-issue, only text cell renderers are used]

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.


2) All the padding space of the cell renderers is treated as background area

Currently, no API is exposed for determining whether a pixel hits a cell renderer (i.e. it is inside where the renderer draws something), or whether we hit a surrounding padding. The gtk_tree_view_column_cell_process_action() handles the requisition/allocation, so it knows the background areas. Some of its code could be pulled into a new function.

Implementing this may be a bit more tricky, but it will not have the issue of concurring button press event recipients.


Summary:

* current selection interaction is limited / not suitable for Nautilus

* two development approaches
** expose more signals to control the precise interaction
** expose API, and handle this inside GtkTreeView

* two behavioral approaches
** treat entire columns as background
** treat inter-cell renderer space as background


My own preference would be
** expose API, and handle this inside GtkTreeView
** treat entire columns as background


Do you have any similar ideas, or other approaches, or comments at what level this issue should be solved?


best regards,
 Christian Neumair

--
Christian Neumair <cneumair gnome org>