RE: CList and CTree problems

[Lars Hamann <lars gtk org>]

On Thu, Nov 12, 1998 at 02:00:36AM +0200, Tero Pulkkinen wrote:

> I think we have some problems with GtkCTree's and GtkCList's interface
> conserning about selections.
[...]
> Now, GtkCTree is derived GtkCList. Do you now start to see the
> problem?  Inheritance "promises" users that same algorithms that you
> use for a base class object can be used for the derived class object
> too, still we're getting a runtime casting error(clist selection gives
> out integers, ctree gives out GtkCTreeItem*'s) if we try handle list
> of selections with same algorithm(originally made for clist) for both
> clist and ctree.
>
> The right thing to do would probably be to fix both clist and ctree use the
> same kind of items inside the selection -GList... (==easy solution)
>
> What do you think?
>
> (alternative (==harder solution) would be to
> not derive CTree from CList at all but from some other non-concrete widget
> and implement selections separately for clist/ctree...
> -- it might be better to do the same for ctree/clist that was done in editable
,
> 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
> )

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. That would break
clist's source compatibility again. Although it would make a few other
problems much easier. But anyway those changes would not guarantee
that you can use the same code for both widgets. Best example is
"remove selection" in the ctree example. For clist I would use
something like:

list = cist->selection;
while (list)
  {
     row = GPOINTER_TO_INT (list->data);
     list = list->next;
     gtk_clist_remove (clist, row);
  }

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.

bye,
  Lars