RE: ctree/clist row selections

[Lars Hamann <lars gtk org>]

Hi Tim!

On 03-Sep-98 Tim Janik wrote:
> hi lars,
> 
> i need to be able to intercept row/node selections in clists/ctrees.
> currently ::select_row and ::unselect_row are GTK_RUN_FIRST signals
> and can't be intercepted. after browsing some clist code, i figured
> that simply making them GTK_RUN_LAST would actually interfere with
> implicit assumptions the code makes, i.e. it relies on ::unselect_row
> to clear up clist->selection, and probably else stuff.
> since interception is not currently possible with clist, can we
> either provide something like a ::check_select_row signal, or simply
> a possibility to mark certain rows/nodes unselectable?

Mmmh, it's the same in gtklist. So if we change something in clist/ctree,
we have to change list/tree too.
The only serve problem is in GTK_SELECTION_EXTENDED. In this case
the rows are only marked as selected. All needed select/unselect signals
are emitted in resync_selection. It makes no sense to intercept those
signals because the visual state of the rows has already changed...
We made it this way, because we wanted to avoid unnecessary select/unselect
signals. If we use something like a ::check_select_row signal we'll have
the same problem with another signal.
I think there are only two ways. Either switch to GTK_RUN_LAST and rewrite
the GTK_EXTENDED_SELECTION stuff, or use a unselectable flag.

I would prefer GTK_RUN_LAST signals, but that would break source
compatibility for clist, ctree, list and tree....

bye,
  Lars