On 2/8/2013 at 9:43 AM, Simon Feltman s.felt...@gmail.com wrote:
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
On 08.02.2013 04:08, Simon Feltman 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.
Won't gobject-introspection silently
On Fri, Feb 8, 2013 at 3:05 AM, Torsten Schoenfeld kaffeeti...@gmx.dewrote:
Won't gobject-introspection silently turn the (transfer full) annotation
into (transfer none) due to the special handling for GInitiallyUnonwed
descendants?
It seems to pick it up correctly. The problem was actually
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
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
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
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.
Hi Simon,
I didn't see this thread earlier. I wanted to chime in to strongly
support the view that:
* Floating references are C-convenience only
* Languages can and should sink floating references when they
first touch them.
* Any interface or code in libraries that create problems with
Owen,
Thank you, this will definitely make things easier. Comments below:
* Floating references are C-convenience only
It might be a convenience for writing code, not necessarily reading or
understanding it. Something more reasonable would be explicitly
named convenience functions which steal
The side affect of GtkWindow is actually fine in this case because the
annotation of transfer none for gtk_window_new makes sense here. The
function is specifying it returns an internal borrowed reference and Python
will add an additional ref during the wrappers lifetime. However, there is
trouble
On 29/01/13 11:44, Simon Feltman wrote:
It seems like the problem at hand can be solved by maintaining the
floating ref and adding our own safety ref for the wrapper.
My impression was that floating references were purely for C
convenience, and that interpreted languages with their own
This is basically how PyGObject works now. There are no problems with this
during casual usage when Python is always in the position of the caller.
The problem is this scheme does not work with the marshaling of floating
widgets passed into Python vfuncs/closures as arguments or intended as
return
For completeness, the two major problems are as follows:
https://bugzilla.gnome.org/show_bug.cgi?id=687522
This is a vfunc implementation which the gtk internals are basically
expecting a floating ref from. Using the standard scheme just listed, we
sink and own the created MenuToolButton. The
On Tue, 2013-02-05 at 05:33 -0800, Simon Feltman wrote:
For completeness, the two major problems are as follows:
https://bugzilla.gnome.org/show_bug.cgi?id=687522
This is a vfunc implementation which the gtk internals are basically
expecting a floating ref from. Using the standard scheme
On Mon, Feb 04, 2013 at 04:44:02PM +0900, Tristan Van Berkom wrote:
On Mon, Feb 4, 2013 at 11:39 AM, Simon Feltman s.felt...@gmail.com wrote:
[...]
However, it also adds a leak for the most basic (and useless) case:
for i in range(10):
Gtk.Button()
This could arguably
On 04.02.2013 03:39, Simon Feltman wrote:
I am starting to warm up to an idea where we simply never sink objects
and always follow the rules entailed by
ownership transference annotations already in place, with one caveat:
g_object_new is annotated as transfer full but can also return floating
I could easily be misunderstanding the internals, but at some point isn't a
call to something like gtk_widget_set_parent on the children needed for
widgets to ever be displayed or useful? (which sinks the children)
If it really might be a problem we could work around the leak by tracking
if the
On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman s.felt...@gmail.com wrote:
I could easily be misunderstanding the internals, but at some point isn't a
call to something like gtk_widget_set_parent on the children needed for
widgets to ever be displayed or useful? (which sinks the children)
One
After some deliberation and writing a bunch of tests:
http://git.gnome.org/browse/pygobject/commit/?id=97f48f
I am starting to warm up to an idea where we simply never sink objects and
always follow the rules entailed by ownership transference annotations
already in place, with one caveat:
On Mon, Feb 4, 2013 at 11:39 AM, Simon Feltman s.felt...@gmail.com wrote:
[...]
However, it also adds a leak for the most basic (and useless) case:
for i in range(10):
Gtk.Button()
This could arguably trigger a compiler warning, or even an error.
In any case, since there is no
On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
[...]
I know that Python doesn't have a GC in the traditional sense, but you
could still send finalization for GObject wrappers to a idle callback
so there is no risk of finalizing objects that C code assumes
I cannot offer a solution, just a grumpy observation:
The problem occurring with this kind of ref sequence is due to
gobject-introspection's decision to always set transfer-ownership=none
for GInitiallyUnowned descendants and the resulting habit of language
bindings to always sink floating refs.
2013/1/17 Simon Feltman s.felt...@gmail.com:
Hi Everyone,
I'm trying to figure out a complete solution for proper reference management
of gobjects passed into python vfuncs and signal closures as in arguments.
Currently pygobject will add a ref to gobject arguments marked as
transfer-none
Hi Everyone,
I'm trying to figure out a complete solution for proper reference
management of gobjects passed into python vfuncs and signal closures as
in arguments. Currently pygobject will add a ref to gobject arguments
marked as transfer-none during marshaling and additionally sink/ref
the
On Thu, Jan 17, 2013 at 9:42 AM, Simon Feltman s.felt...@gmail.com wrote:
Hi Everyone,
I'm trying to figure out a complete solution for proper reference management
of gobjects passed into python vfuncs and signal closures as in arguments.
Currently pygobject will add a ref to gobject
25 matches
Mail list logo
