Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)



I could easily be misunderstanding the internals, but at some point isn't a call to something like gtk_widget_set_parent on the children needed for widgets to ever be displayed or useful? (which sinks the children)

If it really might be a problem we could work around the leak by tracking if the instance was created within python and if the instance has ever been marshaled to C. At which point we could rely on the GC cleanup of the wrapper to sink and unref the extra ref in cases the GObject was never passed on to C at any point. This sucks but it seems a little better than checking GObject ref counts during marshaling and floating sunk objects based on if it was initially floating and the GObject ref count is only 1, which might be unsafe.

-Simon



On Mon, Feb 4, 2013 at 4:56 AM, Torsten Schoenfeld <kaffeetisch gmx de> wrote:
On 04.02.2013 03:39, Simon Feltman wrote:
I am starting to warm up to an idea where we simply never sink objects
and always follow the rules entailed by
ownership transference annotations already in place, with one caveat:
g_object_new is annotated as transfer full but can also return floating
references. In this case, we must check the returned type and not
believe the annotation when it returns InitiallyUnowned instances, but
instead treat it like transfer none and add a new ref.

What about custom implementations of classes that are supposed to take over floating refs?  For example, how would you write a custom GtkContainer subclass in Python with your scheme?  Wouldn't you then need a way to explicitly sink the floating ref?

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list



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