Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Yevgen Muntyan <muntyan tamu edu>]

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

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

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
GtkTreeViewColumn for GtkCellRenderer, whatever. Now, we have a trouble.
Will GtkTreeModel be sinked by GtkTreeView? I believe it should be (if 
we are
consistent and everything). But it can't, because you get crash in old code.

>   
> 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? 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())?

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

> > C is known not to be safe, and it's known that you
> > must be careful. After introducing floating references one will still 
> > need
> > to be as careful, but he also will need to check one more thing - 
> > floating
> > reference (or sink it as soon as possible).
>
>
> no, you can treat a GObject with floating reference support the same way
> you treat GObjects in older glib versions, as if it had no floating ref
> support.

I can't, this is exactly why I'm writing all this stuff.

> > Maybe real solution would be for those 1000 guys to use mono or 
> > something?
>
>
> unfortunately this always depends on other project aspects, like the 
> platform
> and programming skills. the deployment plans, etc. etc.

Yes, true. python is the answer ;)

Yevgen