Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)

[David Nečas]

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  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.

This is nonsense.  Since Gtk.Button() is not guaranteed *not* to have
any side effects it is perfectly valid to run it without doing anything
with the return value.

In fact, since we talk about a dynamic language, the interpreter does
not know, in general, what Gtk.Button will mean at the time the code is
actually executed.

Yeti

___
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)

[Torsten Schoenfeld]

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
references. In this case, we must check the returned type and not
believe the annotation when it returns InitiallyUnowned instances, but
instead treat it like transfer none and add a new ref.


What about custom implementations of classes that are supposed to take 
over floating refs?  For example, how would you write a custom 
GtkContainer subclass in Python with your scheme?  Wouldn't you then 
need a way to explicitly sink the floating ref?

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

bugzilla cleanup

[Matthias Clasen]

Hi everybody,

a while ago, we've talked about getting a handle on the enormous
number of open bugs in glib and gtk.

This weekend, I've spent some time closing old bugs and sorting things
into correct categories. I ended up closing some ~150 old bugs. That
does not really make a dent in the bug number, but it is a start, at
least. If you have expertise in one of the glib or gtk bugzilla
components, feel free to chime in.

Just thought I should mention this, so nobody gets upset if their
favourite 10 year old bug is WONTFIXed...

Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: bugzilla cleanup

[Matthias Clasen]

On Mon, Feb 4, 2013 at 10:21 AM, Florian Müllner
 wrote:
>
> On Feb 4, 2013 4:08 PM, "Matthias Clasen"  wrote:
>
>> Just thought I should mention this, so nobody gets upset if their
>> favourite 10 year old bug is WONTFIXed...
>
> Did you close the time machine one?

I didn't come across it - maybe it is already fixed ?!
___
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)

[Simon Feltman]

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 instance was created within python and if the instance has ever been
marshaled to C. At which point we could rely on the GC cleanup of the
wrapper to sink and unref the extra ref in cases the GObject was never
passed on to C at any point. This sucks but it seems a little better than
checking GObject ref counts during marshaling and floating sunk objects
based on if it was initially floating and the GObject ref count is only 1,
which might be unsafe.

-Simon



On Mon, Feb 4, 2013 at 4:56 AM, Torsten Schoenfeld wrote:

> 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
>> references. In this case, we must check the returned type and not
>> believe the annotation when it returns InitiallyUnowned instances, but
>> instead treat it like transfer none and add a new ref.
>>
>
> What about custom implementations of classes that are supposed to take
> over floating refs?  For example, how would you write a custom GtkContainer
> subclass in Python with your scheme?  Wouldn't you then need a way to
> explicitly sink the floating ref?
>
> __**_
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://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)

[Tristan Van Berkom]

On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman  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 of the more gross internal details of GTK+ is that GtkWindows
(any toplevel widgets) get added to an internal 'list of toplevels'.

So a GtkWindow is an odd subclass that (like someone else
pointed out), sinks it's own floating reference at initialization time.

The ownership of the window is virtually given to "GTK+" and then
disposed of automatically at gtk_widget_destory() time.

I suppose that strictly speaking, an object constructor can indeed
have side effects (but I can't think of any case where it would be
anywhere close to 'sane' to intentionally use object constructors
for their side effects and ignore the results).

Best,
 -Tristan

>
> If it really might be a problem we could work around the leak by tracking if
> the instance was created within python and if the instance has ever been
> marshaled to C. At which point we could rely on the GC cleanup of the
> wrapper to sink and unref the extra ref in cases the GObject was never
> passed on to C at any point. This sucks but it seems a little better than
> checking GObject ref counts during marshaling and floating sunk objects
> based on if it was initially floating and the GObject ref count is only 1,
> which might be unsafe.
>
> -Simon
>
>
>
> On Mon, Feb 4, 2013 at 4:56 AM, Torsten Schoenfeld 
> wrote:
>>
>> 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
>>> references. In this case, we must check the returned type and not
>>> believe the annotation when it returns InitiallyUnowned instances, but
>>> instead treat it like transfer none and add a new ref.
>>
>>
>> What about custom implementations of classes that are supposed to take
>> over floating refs?  For example, how would you write a custom GtkContainer
>> subclass in Python with your scheme?  Wouldn't you then need a way to
>> explicitly sink the floating ref?
>>
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://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
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list