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

[Gus Koppel <gtk spamkiller bytechase cx>]

martyn 2 russell bt com wrote:

> The easiest way to do this is to use the gtk_tree_store_clear() or
> gtk_list_store_clear() function.  This removes the data.

Yes, but it only removes contents of a model and not the model itself,
does it? I.e. its reference count stays unchanged.

> Adding and removing columns is only necessary if you change the columns
> based on the data being displayed.  If the data is similar, it is
> probably best to hide/show columns as necessary.  If the data is
> completely different, I would suggest having two different treeviews and
> hiding/showing which ever one is required at the time.

I hide/show treeviews as required if they're of limited content. If
there's too much being stored in them then memory considerations, thus
only building needed ones / destroy no longer needed ones, become more
important.

> When you use gtk_tree_store_new() or gtk_list_store_new(), there are two
> references on the store.  One is GTKs reference and the other is for you
> (although a quick look at the gtk_list_store_new() API documentation
> does not state this and I think it should).

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 (!)

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.

> As the demo (gtk-demo) demonstrates, you should free your copy if you
> wish to no longer keep it around. - This is usually after creation.

Despite the result above I'll account for it even closer at construction
time of objects.

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

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

Thanks for your quick reply.