RE: How to orderly empty a tree view without memory leakage?

[martyn 2 russell bt com]

> I tested it. I found out the following:
>
> gtk_tree_store_new ()           --> model's ref_count = 1
> gtk_tree_view_set_model ()      --> model's ref_count = 2
>
> While this behaviour looks comprehensible I think the 
> following does not:
>
> gtk_tree_view_column_new ()     --> column's ref_count = 1
> gtk_tree_view_append_column ()  --> column's ref_count = 1 (!)

Perhaps GTK assumes that the developer wants a reference (for the tree
store) and then makes it up to them to unreference it.

The append_column() is perfectly logical with the way GTK expects developers
to use the API.  You create a new object and then add it to and object which
GTK already owns (the tree view).  Hence, it now has inherited the column
and the ref count stays at 1 (to GTK).

You can expect to see the same result (I think) when using functions like
gtk_menu_append().

> Is this a bug of GTK or have I overlooked a rule which states 
> that SETTING
> an object is supposed to increase its reference count while 
> APPENDING it
> isn't? If I unref a column after it's been appended my app 
> crashes indeed.

I see your point and perhaps this should be more heavily detailed in the
documentation.

> > See the documentation.  It *SHOULD* state those objects 
> which should be
> > unreferences, all others should not.  If there is something 
> that is not
> > documented that should be unreferenced, it is a bug in GTKs
> > documentation and should be reported to http://bugzilla.gnome.org
>
> Description of which obtained resources to free and which not seems
> slightly insufficient to me anyway. For instance, I haven't found a
> rationale yet why i.e. gtk_widget_get_parent () doesn't increase the
> ref_count for the object returned while gtk_container_get_children ()
> does. Descriptions of those functions don't mention it 
> either. I learned
> that gtk_container_get_children () creates a GList on the fly 
> instead of
> returning an existing one, but that's not documented. I think 
> there are
> quite a number of functions with ambiguous and undocumented 
> behaviour on
> the resources they return.

I would have to agree with you.  File bugs against all those which you think
are inappropriately detailed.  Certainly it is noted that the documentation
is light in places, especially with regards to events - these are confusing
in places and not mensioned in others.  

> > > - What about cell renderers? Are they (supposed to be) 
> unref'd / freed
> > No, not as far as I am aware.
>
> I added a g_object_unref (renderer) at the end of my tree 
> view populating
> function and it doesn't seem to harm. Likely it helps.

You can always ask about this at irc.gnome.org in the gnome-hackers channel,
the best person to ask is probably Havoc Pennington or Owen Taylor.
Jonathan Blandford knows about the intrinsic workings of the GtkTreeView.


Regards,
Martyn