Re: custom cell renderer start_editing refcount

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]