The side affect of GtkWindow is actually fine in this case because the annotation of "transfer none" for gtk_window_new makes sense here. The function is specifying it returns an internal borrowed reference and Python will add an additional ref during the wrappers lifetime. However, there is trouble when using g_object_new(GTK_TYPE_WINDOW) because it is annotated as "transfer full" which means the constructor is giving us full ownership of that internal reference and without some type of special case, the language binding wrappers will free that internal reference. The cleanest fix would be for gtk_window_new to specify transfer full along with sinking and adding an additional ref before returning, this would at least give consistency between g_object_new(GTK_TYPE_WINDOW) and gtk_window_new in terms of how introspection based bindings see it. But this is most likely out of the question.
Instead it will take some combination of tracking and testing things like: is derived from InitiallyUnowned, is it floating, are we calling a constructor, and what is the ownership transfer. And then try to make a best guess as to what we are supposed to do. -Simon On Mon, Feb 4, 2013 at 11:05 PM, Tristan Van Berkom <t...@gnome.org> wrote: > On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman <s.felt...@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 <kaffeeti...@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 > > >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
