Re: CList and CTree problems

[Tero Pulkkinen <terop students cc tut fi>]

> > i.e. change the class hierarchy:
> >   container <- clist <- ctree
> >
> > to
> >   container <- common_stuffs_for_clist_and_ctree <- clist
> >
> >   container <- common_stuffs_for_clist_and_ctree <- ctree
> > )

Lars Hamann <lars@gtk.org> writes:
> Some comments on this :
> 
> ctree can't work on row numbers because invisible nodes don't have
> a row number. So if you want to go the "easy way" you must change
> clist to use row pointer in its selection list. 

hmm, okay... guess the easy way isnt perfect either... :(

the hard way breaks everything - since the function names change...

Guess I'll have to do separate objects to represent the selection list
for gtk-- for ctree and clist. => it leaves small hole for the
interface where people can shoot themselves in their foot... (by
implicit cast to Gtk_CList from Gtk_CTree and then accessing
selectionbegin()/selectionend() will get undefined behavior :( )

> A similar ctree loop will sigsegv, because removing a node can
> result in removing (and unselecting) nodes childs. So after
> gtk_clist_remove the list pointer may point to an already destroyed 
> GList struct.
> 
> On the other side : the selection code in clist has grown to a big
> extent when we added SELECTION_EXTENDED support. Since the selection
> is handled differently in both widgets, the selection code can't go in
> the new widget. That would result in much duplicated code. And it
> would break source compatibility either.

well, guess I'll have to do a patch for trying the hard way at some point and
see if it could be made to work properly.. (it does break compability quite
well.. .:)

-- 
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --