On Wed, Feb 6, 2013 at 12:57 PM, Owen Taylor <otay...@redhat.com> wrote: > > > class ToolMenuAction(Gtk.Action): > > def do_create_tool_item(self): > > > > return Gtk.MenuToolButton() > > This is basically broken API at the GTK+ level :-( ... a virtual > function can't return (transfer none) unless it's a getter for an > existing field. It is expected that language bindings will have no way > to create a floating object, so a virtual function cannot expect to be > returned a floating object. > > The only thing I can see at the GTK+ level would be to add a > make_tool_item replacement vfunc and use that instead if non-null. >
I don't know GTK+ internals but taking a quick look are you saying to use the "_gtk_reserved" pointers for new vfuncs and annotate them as transfer full? A potential issue is the API which wraps this is also marked as transfer none (gtk_action_create_tool_item) and the code that calls this is all setup to receive a floating ref that it sinks, changing it seems like it would be an API break. In any case if gtk_action_create_tool_item starts returning an already sunk object, it will leak. This could be hacked around by doing a force_floating on the results of the vfunc and then gtk_action_create_tool_item will continue to maintain the same expected floating results. But is this kind of thing acceptable? If it is we might not even need to use the reserved pointers but just start mark the existing vfunc as transfer full and then force the result as floating? -Simon
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
