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

[Tristan Van Berkom <tvb gnome org>]

On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman <s feltman gmail com> wrote:
> 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)

One of the more gross internal details of GTK+ is that GtkWindows
(any toplevel widgets) get added to an internal 'list of toplevels'.

So a GtkWindow is an odd subclass that (like someone else
pointed out), sinks it's own floating reference at initialization time.

The ownership of the window is virtually given to "GTK+" and then
disposed of automatically at gtk_widget_destory() time.

I suppose that strictly speaking, an object constructor can indeed
have side effects (but I can't think of any case where it would be
anywhere close to 'sane' to intentionally use object constructors
for their side effects and ignore the results).

Best,
     -Tristan

>
> 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
>
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>