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

[Simon Feltman <s feltman gmail com>]

For completeness, the two major problems are as follows:

https://bugzilla.gnome.org/show_bug.cgi?id=687522

This is a vfunc implementation which the gtk internals are basically expecting a floating ref from. Using the standard scheme just listed, we sink and own the created MenuToolButton. The held widget is then finalized at the end of the vfunc, returning an invalid object back to the caller. If we add an extra ref we get a leak because the method is marked as transfer-none. Example:

class ToolMenuAction(Gtk.Action):

    def do_create_tool_item(self):

        return Gtk.MenuToolButton()

https://bugzilla.gnome.org/show_bug.cgi?id=661359

This is a very simple case of a widget as a parameter being marshaled as an in arg to a callback. But because the gtk internals have not yet sunk the floating ref for the "editable" parameter, PyGObject will do so. By the time the callback is finished, the editable will be finalized leaving gtk with a bad object. It should really just be adding a safety ref during the lifetime of the wrapper and not mess with the floating flag.

def on_view_label_cell_editing_started(renderer, editable, path):

    print path

renderer = Gtk.CellRendererText()

renderer.connect('editing-started', on_view_label_cell_editing_started)

-Simon

On Tue, Feb 5, 2013 at 5:09 AM, Simon Feltman <s feltman gmail com> wrote:

This is basically how PyGObject works now. There are no problems with this during casual usage when Python is always in the position of the "caller". The problem is this scheme does not work with the marshaling of floating widgets passed into Python vfuncs/closures as arguments or intended as return values from them. I just added a bunch of commentary to the following bug about why it is failing:

https://bugzilla.gnome.org/show_bug.cgi?id=657202#c21