Re: [gnome-db] Tree-structured data



2006/1/31, Diego Zuccato <diego otello alma unibo it>:
> Vivien Malerba wrote:
> > I suggest rather a function like:
> > GdaDataModelTree *gda_data_model_tree_new (GdaDataModel *model);
> > which creates a GdaDataModelTree object.
> > Each row of @model will possibly be expanded.
> Uhm... Some possible problems:
> 1) Maybe not all rows from the model are expandable (in the "localities"
> model, top level rows for "America", "Asia", "Africa", "Europe" and
> "Oceania" can be expanded, "Utopia" can't: it's a leaf node, but only
> the programmer can know it);

A row is expandable only if someone catches the "expand_row" signal
and adds the children rows (maybe we need an initial setting there to
be able to show the user which row is expandable and which is not).

> 2) A tree gets bound to another datamodel: what happens if the base
> datamodel is modified?

I meant that the children rows of a tree row should be the contents of
another GdaDataModel which means that the tree row needs to add or
remove rows if the "sub-model" adds or removed rows.

If an expanded row is removed, then the data model which contained its
children is unref'ed and is not used anymore by the GdaDataModelTree.

>
> > Then make that object emit a "row_to_expand (gchar *row_path)" signal
> > which can be caught to actually add the children of the
> > GdaDataModelTree for the corresponding row. The children are added by
> > specifying a new GdaDataModel which contents is added below (as
> > children) of the corresponding row.
> I hate handling strings in C. Specially when they have to be passed
> around and modified often. When possible I prefer a reference/pointer
> (that could eventually be serialized/deserialized to/from a string, but
> only when needed -- model MUST NOT change between serialization and
> deserialization, or you open a huge can of worms to keep 'em coherent).
>
> > It can also emit a "row_to_collapse (gint row)" which can be caught
> > before the GdaDataModel which represented the children of the row is
> > removed.
> Not orthogonal with previous row_to_expand(). IMO it's better to have a
> single notation (that's why I used GdaRow* in both... Better yet
> GdaRowReference * -- the infrastructure is already present in
> GtkTreeStore, with proxies & co.).


Right, in fact having row numbers is better and is enough in this
case. The GdaRow object is only used by the GdaDataModelRow (and
inheritants) objects, and is not useable in the general case with
GdaDataModel objects.

>
> > Also we need to have:
> > void gda_data_model_tree_expand(GdaDataModelTree *, gchar *row_path);
> > void gda_data_model_tree_collapse(GdaDataModelTree *, gchar *row_path);
> > The row_path is the same as the string used along with GtkTreePath objects.
> Same as above. I don't like handling strings if not strictly needed, but
> could be worse :)

Yep, just use plain gint row numbers.

> > Now, I think the GdaDataModelTree should really be just another
> > GdaDataModel object (to be put into libgda) and we need to write an
> > object in libgnomedb which implements the GtkTreeModel interface on
> > top of the GdaDataModelTree.
> Sure.
>
> > How does it sound?
> Quite good. :)
>
> I could send the code I use to handle a similar case (I have a PG
> backend, handled with a wrapper lib I wrote some time ago, that contains
> a table with a ltree field that implements the localities tree).

Ok, I'll try to frame a header file for the GdaDataModelTree object.

Thanks,

Vivien



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]