Re: Gtk{Tree,List} replacement proposal

[Owen Taylor <otaylor redhat com>]

Jonathan Blandford <jrb@redhat.com> writes:

> > why is all the view's stuff private? that disables derivation,
> > pretty unaccaptable for a widget as often used and tweaked as
> > list/tree views.
> 
> To much time talking to federico, I guess.  I can move the priv struct
> out, as it is a little weird with regards to the rest of GTK+

I tend to agree with Havoc/Jonathan that the priv structure really
doesn't matter.  You have to design your widgets to be derived from
and modified; just randomly all exposing all fields to child classes
will simply result in, something like GtkCList and GtkCTree where
you get a huge hunk of inextricably mixed and contorted code.

And these tree widgets are designed to be customized in clean ways,
not just derive-and-hack.
 
> > i'd rather not repeate the clist misnaming here and see gtk_tlview_move_to(), as
> > far as my knowledge goes, "moveto" isn't a real word in english, right?
> 
> no more then clist is... (-:

Definitely move_to. 'c list' is not two words. But 'move to' is 
two words.

> > this is for user data i suppose. if you spare that one pointer
> > per node anyway, make it a GData* pointer and use the quarked data
> > API, that will scale in the future and provide you with reliable
> > destroy notification out of the box (you can still have convenience
> > variants to wrap the "user-data" quarks for udata though).
> 
> Okay -- I'll investigate this further.

Sounds like how it should be done to me.

> > there's no destroy notification for the data here. couldn't the renderer
> > simply use quarked data with destroy notification ere as well, if it requires
> > the data pointer?
> 
> Each cell has a destroy function too, though moving to Quarked data
> might make sence for consistency here.

I think the current way is correct. Every cell needs the data here,
and keyed data would be a huge overhead. Also, there is no need to
have keys for the data - the cell data is intimately tied to the cell
type; it's not like you'll have 

 a) cell renderers without cell data
 b) other people randomly setting data for the cell renderer

Regards,
                                        Owen