Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Tim Janik <timj gtk org>]

On Thu, 15 Dec 2005, Yevgen Muntyan wrote:

> I apologize for junk-posting, I'll learn to use mozilla next time.
>
> Tim Janik wrote:
>
> > it's language bindings and container implementations that do this.
> > the floating flag is actually meant to make it easier on the user as
> > outlined in:
>
> Let me expand my code samples:
>
> Old code:
>
> object = fancy_not_gtk_object_new();
> fancy_container_add(container, object);
> /* what do i do now? unref or not unref?
>   yes, unref() because i own it */
> g_object_unref(object);

because fancy_container_add() is documented to not take a reference.

> New code:
>
> object = fancy_not_gtk_object_new();
> g_object_ref_sink(object); /* because I don't know what will container do */
> fancy_container_add(container, object);
> g_object_unref(object);

this will work if fancy_container_add() didn't change. also with floating GObject
this will work:
  object = fancy_not_gtk_object_new();
  fancy_container_add(container, object);
  g_object_unref(object);
as long as fancy_container_add() didn't change.

with and without floating support fancy_container_add() may change though.
e.g. it may always take a reference, to which you'd have to adapt your code then
(remove your unrefs).
or it may randomly take a reference, to which your code would be hard to adapt
without leaks.
or it may sink the obejct, to which your code would be easy to adapt again
(remove your unrefs).

the point is, you only have to adapt your code if fancy_container_add()
changes, and that can occour regardless of libgobject changes.

the only relation existing here is:
  fancy_container_add() cannot sink GObjects as long as libgobject does not
  support floating objects.

and we'r about to change that. the only thing libgobject will do is to
*enable* fancy_container_add() changes wrg sinking though. nothing more.

so adding floating ref support to libgobject doesn't change any GObject
refcounting semantics at all. it's the fancy_container_add() changes in
other projects that are enabled to change semantics then, and whether
they do that, and if that's compatible or incompaatible will be up
to the maintainer of "fancy".

> So far we have had one simple rule - GtkObject has floating reference, it's
> supposed to be taken by parent, whether it's parent GtkContainer or

GtkObject per se doesn't even introduce parent<->chuild relationships,
it's GtkWidget that does this. (and some "containers" take non-widget
GtkObjects).
and note that libgobject hasn't been floating reference-free anyway,
GParamSpec already had floating references as had GClosure.
so, maybe it's not as siple as you'd think ;)

> GtkTreeViewColumn for GtkCellRenderer, whatever. Now, we have a trouble.
> Will GtkTreeModel be sinked by GtkTreeView? I believe it should be (if we are

that depends on whether it could compatibly be ported to that behaviour.
cou could e.g. be deprecating one model setter and adding another, or you
could not support sinking at all, etc...

> consistent and everything). But it can't, because you get crash in old code.

that sounds like a non-compatible change then ;)


> >   http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref 
> >
> > and for historic heritage see:
> >
> >   gtk+/docs/refcounting.txt
>
> Is it not correct that floating reference in GtkObject is one of
> well-known sources of misunderstanding/problems for bindings?

with bindings you mean langzage bindings?
i'm not really worried about confusing language binding authors, because
there's only a finite oevrseeable number of them. anyone wanting to code
up a proper language binding for gtk/glib will have to come here and get
informed about a couple involved topics anyway. floating references aren't
too complicated for that scope by my experience (they just need to be
explained which the docs i pointed you at should take care of already).

> And
> that it should not exist at all, but it exists only for historical reasons 
> and
> convenience of gtk_container_add(container, gtk_label_new())?

it exists for C convenience. that's what the official API reference doc says:
 http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref

C convenience is an iomportant concern for a C toolkit with large amounts of
depending C applications. so that basically justifies having a floating
reference at all.

> > > These arguments about bugs and stuff are good arguments about why
> > > one should use C++ or whatever other language with some sort of automatic
> > > memory management.
> >
> >
> > this is absolutely correct. reall OO applications should be written in
> > languages with native OO support. for the scope of glib, gobject and gtk+, 
> > we're stuck with maintaining an
> > OO system implemented in C though, and we're simply doing our best to
> > live up to that expectation.
>
> I am not saying that glib should be written in other language. And I agree
> that glib should try to solve users problem. But it should not solve problems
> of lazy users by adding problems for others.

i don't think this is the case with supporting floating references for GObject.

> Yevgen

---
ciaoTJ