I had a go at making an editable cell renderer and I find the destroy signal on the GtkEntry "editable" widget I return from START_EDITING is not called. Sample program below, click alterately between the two cells to edit, and notice the destroy for $entry is not called. I suspect the SvREFCNT_inc in gtk2perl_cell_renderer_start_editing() keeps it alive forever. The best I can nut out is that there ought to be a floating reference ready for the View container to take over. The normal Gtk2::Entry->new has sunk the initial so I think another should be created. With the change below the destroy runs as I hoped. Does it sound about right? -- before digging out what it should look like for glib pre-2.10. (The "Example 3" in the GObject reference is slightly related to what I think is going on. It shows sinking the floating ref and then putting it back - though the unref there may be 1 too many.) Incidentally, if you create the editable by chaining up to $renderer->SUPER::START_EDITING() the destroy runs ok. But I believe that's only because the chain-up code at the end of GtkCellRenderer.xs uses newSVGtkCellEditable_ornull() to wrap, and that macro does gperl_new_object() with FALSE for "own", so it doesn't sink. That leaves the object with a refcount of 2 -- 1 still floating and 1 from the wrapper -- so the condition for the SvREFCNT_inc bit in gtk2perl_cell_renderer_start_editing() is not met. With the change I'm proposing a count of 2 with 1 floating and 1 from the wrapper would be the normal situation; with the 1 from the wrapper quite possibly dropped at the FREETMPS stage.
Attachment:
iconview-nodestroy.pl
Description: Text Data
Attachment:
GtkCellRenderer.xs.start-editing-float.diff
Description: Text Data