Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
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
Re: [PATCH] icon-theme: fix leak in insert_theme()
On 01/12/12 01:42, Alex Chiang wrote: We allocate path with g_build_filename() but never free it. I don't think this patch is correct. Ownership of @path is given to @dir_mtime at line 1109 (in git master as of 97c235405d9), so freeing it as in your patch causes a use-after-free in rescan_themes() and theme_subdir_load(), and eventually a double-free in free_dir_mtime(). If you disagree with my reasoning, please open a bug on bugzilla.gnome.org where this can be discussed. You're welcome to quote this email there. Regards, S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
On 07.02.2013 01:12, Simon Feltman wrote: Unfortunately there are a few more of these: Gtk.Action.create_menu Gtk.Action.create_menu_item Gtk.Action.create_tool_item Gtk.PrintOperation.create_custom_widget Gtk.PrintOperation.create-custom-widget (signal) Gladeui.EditorProperty.create_input Gladeui.BaseEditor.build_child? Gladeui.BaseEditor.build-child (signal) Also: Gtk.CellRenderer.start_editing. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
I've created a ticket and proposed patch for GTK+: https://bugzilla.gnome.org/show_bug.cgi?id=693393 I am looking for feedback to see if this type of thing is even acceptable and if it's worthy of further pursuit. Thanks, -Simon On Thu, Feb 7, 2013 at 1:16 PM, Torsten Schoenfeld kaffeeti...@gmx.dewrote: On 07.02.2013 01:12, Simon Feltman wrote: Unfortunately there are a few more of these: Gtk.Action.create_menu Gtk.Action.create_menu_item Gtk.Action.create_tool_item Gtk.PrintOperation.create_**custom_widget Gtk.PrintOperation.create-**custom-widget (signal) Gladeui.EditorProperty.create_**input Gladeui.BaseEditor.build_**child? Gladeui.BaseEditor.build-child (signal) Also: Gtk.CellRenderer.start_**editing. __**_ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-devel-**listhttps://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
Ticket and patch for the transient argument to the GtkCellRendererText editing-started signal: https://bugzilla.gnome.org/show_bug.cgi?id=693400 This is what I was proposing when I started this thread. If this kind of fix is ok, I have no problem looking for more cases in the GTK+ code base. Thanks, -Simon On Thu, Feb 7, 2013 at 7:08 PM, Simon Feltman s.felt...@gmail.com wrote: I've created a ticket and proposed patch for GTK+: https://bugzilla.gnome.org/show_bug.cgi?id=693393 I am looking for feedback to see if this type of thing is even acceptable and if it's worthy of further pursuit. Thanks, -Simon On Thu, Feb 7, 2013 at 1:16 PM, Torsten Schoenfeld kaffeeti...@gmx.dewrote: On 07.02.2013 01:12, Simon Feltman wrote: Unfortunately there are a few more of these: Gtk.Action.create_menu Gtk.Action.create_menu_item Gtk.Action.create_tool_item Gtk.PrintOperation.create_**custom_widget Gtk.PrintOperation.create-**custom-widget (signal) Gladeui.EditorProperty.create_**input Gladeui.BaseEditor.build_**child? Gladeui.BaseEditor.build-child (signal) Also: Gtk.CellRenderer.start_**editing. __**_ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-devel-**listhttps://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
