Re: CTree inheritance from CList

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> > > However, gtk_clist_set_row_data() and
> > > gtk_ctree_set_row_data() have different (and possibly incompatible)
> > > signatures.
> > > 
> > > This happens to work OK for C programs most of the time, but sucks in
> > > languages such as Objective C, where all methods with the same name (in
> > > this specific example, "set_row_data") must have the same signature.
> > 
> > I think that's OK for class funktions, but these funktions only have
> > analog names. I can change the function name a little bit, but that
> > won't make a big difference, except, that people won't see the analogy.
> 
> and certainly get confused about the user data usage in their code.
> the actuall root problem for the existing difficulty elliot approached,
> originates in the inconsistency of widget inheritance vs. data structure
> inheritance (i.e. clist/ctree entries). since clist uses integer values
> to identify it's entries, where ctree uses a structure pointer, there is
> no proper way, to have any inheritance-like relation ship for the two.
> the proper way would have been to use opaque data pointers for clist in
> the first place, then there would have been a chance to derive a structure
> from that.

The real problem is that there is not an ISA relation between the
CList and the CTree. (The CTree is not a CList with additional
features, it is a completely different widget that happens to be
implemented in terms of the CTree). This is why the CTree ends
up with modified equivalents for all the CList API functions,
and signals...

Unfortunately, it would take a major redesign (and be difficult
in the GTK+ object model), to fix this up properly.

[...]

> > > The CTree analogues for the CList routines also breaks expected behaviour.
> > > For example, gtk_ctree_set_row_data() just sets the data directly, without
> > > sending the select_row signal that gtk_clist_set_row_data() does.
> > 
> > Out of gtkclist.c :
> > 
> > /* re-send the selected signal if data is changed/added
> >  * so the application can respond to the new data -- 
> >  * this could be questionable behavior */
> > 
> > I'm not to happy with this selection signal, so I left it out for ctree.
> > We can change that, if that's terribly wrong.
> 
> i *really* think that the clist behaviour in this case is terribly wrong.
> depending on what the application actually intends to display on screen,
> and what it wants its user data to refer to, selection of entries and
> setting of user data will be completly independant actions in most cases.
> also, setting user (object) data for GtkListItems doesn't affect a GtkList
> container in any way, and that's what should hold as a reference
> implementations for those who are in doubt about the whole issue.
> if for some good or even bad reasons, the current bahviour should be
> supported, we should do either of:
> 
> - make that feature configurable with e.g.
>   gtk_clist_emit_selected_on_data_set (, bool) or
> - implement a completely new signal ::data_set  on clist basis, that people
>   could connect to who care about out of order user_data resetting.

IMO, the app knows when it is setting the user data, and doesn't
need a callback from the widget - so I think this should just be
ripped out.

Regards,
                                        Owen