Re: Gtk{Tree,List} replacement proposal

[Jonathan Blandford <jrb redhat com>]

Tim Janik <timj@gtk.org> writes:
> > First, a quick note about the design of the tree:
> > 
> > There are a number of objects associated with this:
> >  GtkTLView - a view for trees/lists
> >  GtkTLModel - a generic model for Trees/Lists.
> 
> why is this a GtkObject? are there any reasons for making it not directly
> inherit from GObject?

Yes.  GObject didn't exist when I wrote it.  I will make it a GObject now. 

> note that we have an established convention to underscore-split capitalized
> type names, encoded in the enum stringification macros in gtk's sources.
> that is:
> 
> PrefixXOneLetter   -> prefix_xone_letter    -> PREFIX_XONE_ENUM_VALUE
> PrefixXYTwoLetters -> prefix_xy_two_letters -> PREFIX_XY_TWO_ENUM_VALUE
> 
> so you'd either have to go for TLview (odd), something like ZView that uses
> only one capitalized letter as prefix, or gtk_tl_view...

ugh.  GtkZView is looking better and better.

> the _GET_CLASS() macro is missing

Owen informed me of it's existence this afternoon.  Will fix.

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

> please move those asterisks away from the function name, since owen and me can't
> agree on using GtkWidget* for return types, simply make it:
> 
> GtkWidget *      gtk_tlview_new_with_model           (GtkTLModel       *model);

ugh.  I don't like this as much, but if that's convention...

> maciej already made appropriate coments on the naming here:

Duly noted.

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

> > ---------
> > gtktlmodel.h
> > ---------
> 
> > typedef gpointer                GtkTLNode;
> 
> what is this? i suppose you use a real GtkTLNode structure internally?
> then use:
> typedef struct _GtkTLNode GtkTLNode; and use GtkTLNode *node throughout
> the API.

Because it isn't necessarily a struct.  It's up to the model to
determine what it's internal data pointer is.  For example, a simple
model could just pass around an offset into an array.


> is this the number of columns, i.e. gtk_tlmodel_get_n_columns()?

yes.  Will change.

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

> hm, argument alignment wouldn't hurt ;)

Owen's cool emacs-alignment function doesn't seem to catch those.  I'll
fix it by hand... (-:

> ok, i just quickly glanced over it, it seems to be a good straight
> forward approach so far. gotta have to look at some of the implementation
> and use it a bit ;)

Cool!  Thanks for the feed back.  Let me know if you have any
immplementation issues...

Thanks,
-Jonathan