Robert Nikander wrote:
>
> Robert Nikander wrote:
>
>> <snip stuff about emitting signals from GenericTreeModel>
>
>
> James Henstridge wrote:
>
>>
>> The GenericTreeModel class has a number of limitations (you just ran
>> into some). For 0.99.5, you probably can't do what you want. Note
>> that GenericTreeModel will leak lots of references (and can't really
>> be fixed).
>>
>> James.
>
>
> Well I did get it to emit signals. I have to call get_iter to get a
> TreeIter. Can't use tuples.
>
> But you were not kidding about it leaking references. I have been
> running a process overnight that has a few lists with 1000+ rows in
> them and 'top' reveals the memory footprint is now an obese 78 Megs.
>
> I am interested in your comment 'it can't be fixed.' I really like
> this toolkit -- it is so much more pleasant than trying to write GTK
> stuff in C! -- and I would take a hack at changing some source and
> seeing if I can't get a good abstract TreeModel working, but I don't
> want to waste my time if you have discovered that there is some reason
> it 'can't be done' -- some kind of essential design problem that I
> will run into after 5 days of hacking. Can you elaborate a little on
> that comment? Who is working on that code?
When using a tree model from C code, GtkTreeIter objects are allocated
on the stack, can be copied by value, and are not explicitly freed. For
example:
GtkTreeIter iter1, iter2;
gtk_list_store_append(list_store, &iter1);
/* do stuff with iter1, and don't need to explicitly free it */
iter2 = iter1; /* can assign one iter to the other, and both are
valid */
/* don't need to explicitly free either iter -- tree model is
responsible for keeping them alive */
With the GenericTreeModel, I stuff a PyObject inside the GtkTreeIter. I
ref the PyObject, so that it doesn't get destroyed, but at the moment,
that reference never gets released, leading to the leaks you are seeing.
One way around this would be to not ref the PyObject in the iter, and
require the python programmer to keep a reference somewhere else (and if
they don't keep a reference, risk a crash).
Another option would be to keep a list of the PyObjects that have been
stuffed into iters, and ask Jonathan ([EMAIL PROTECTED], or jrb on
irc.gnome.org) under what conditions it would be allowable to unref the
objects in the free list. If you can get this to work, GenericTreeModel
would work very nicely in python.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
