RE: ctree/clist row selections

[Tim Janik <timj gtk org>]

On Thu, 3 Sep 1998, Lars Hamann wrote:

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

the difference with GtkList is that you can set the listitems
to insensitive.

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

i guess an unselectable (correlating to insensitive list items) flag
would be the better (and evenm easier to implement) solution then.

> 
> bye,
>   Lars
> 
> 

---
ciaoTJ