Re: custom cell renderer start_editing refcount

[Torsten Schoenfeld <kaffeetisch gmx de>]

Kevin Ryde wrote:
> > The pre-2.10 branch would need to use GTK_OBJECT_FLOATING
> > and GTK_OBJECT_FLAGS, I think.
>
> Maybe something like below.  I think it compiles, but does someone have
> an old enough gtk setup to try the test program?

My GNOME 2.12 sandbox has glib 2.8.6.  Your patch compiles and works, as judged 
by your test program, Gtk2's test suite, and odot.

> > A unit test would be great.
>
> Unit testing means it compiles doesn't it?  Integration testing is if it
> links too. :)

Then I guess I'm asking for a complete inspection by the QA department. :-)

> Actually I don't know really how to programmatically make TreeView or
> IconView start editing then stop editing, as normally done by mouse
> clicks of course.  A forced focus change to stop editing might be ok, or
> maybe running $entry->activate, but I don't have a good idea for a
> realistic start editing.

Gtk2::IconView and Gtk2::TreeView have set_cursor() with a bool argument that 
starts editing.

> What about the newSVGtkCellEditable macro?  Since a GtkCellEditable
> interface requires GtkWidget I'd think maybe it should wrap the same as
> other widgets, ie. it should be gtk2perl_new_gtkobject() instead of the
> current gperl_new_object(...,FALSE), the difference of course being the
> latter doesn't sink a floating ref.

All GInterfaces are automatically treated like GObjects by the code that 
generates these macros.  It doesn't take the interface's prerequisites into 
account.  That's usually not a problem since interfaces define abstract types 
that cannot be constructed directly.  The exception to this, of course, are 
constructors that can create different kinds of objects all of which have in 
common only that they implement some interface.  GtkCellEditable's start_editing 
is an example.  I don't think we need generic support for these exceptions.

And since the generated object handling macros are part of our public API, we 
can't just change newSVGtkCellEditable, I think.

> Something like $renderer->start_editing from say an ordinary
> Gtk2::CellRendererText comes back with a floating ref to be taken over.
> I don't think there's any outright bug, since any viewer widget will add
> it as a container child, sinking the ref at that point.  But leaving a
> floating ref kicking around is not normal is it?

Not normal, no.  This can be fixed by a CLEANUP section for start_editing which 
does ref_sink() followed by unref(), right?  Or maybe use the _noinc typemap and 
just unref() in CLEANUP.