Tim Janik wrote:
[...]
Firstly Tim,
I'd like to publicly apologize for bashing floating
GObjects as hard as I did, I spontainiously felt very
strongly about an issue and completely unloaded the whole
nine yards into my email composer and hit "send", I was
out of place for this argument; I'm s
il.gnome.org/archives/gtk-devel-list/2006-January/msg00010.html
- general sinkability: "Sinkability considered harmful"
http://mail.gnome.org/archives/gtk-devel-list/2006-January/msg00012.html
- inheritance changes: "changing inheritance == API breakage"
http://mail.gnome.org/ar
Tim Janik wrote:
[...]
People have to get over it.
well, i think the question here is whether we assist them with appropriate
functionality, or let everyone learn every possible memory management
failure the hard way over and over again. the latter is prone to produce
bug-ridden software and
muppet wrote:
On Jan 4, 2006, at 11:51 PM, Tristan Van Berkom wrote:
Excuse me but I still dont register, why can you assume that
a function returning a GtkObject cant return an added reference ?
Excuse my intermittent "dropping off the planet" ;-)
Such special cases such as that are handled
On Fri, 6 Jan 2006, Bill Haneman wrote:
(federico)
API freeze for GNOME 2.14 is approaching quickly. Can we please back
out GObject floating references soon?
(timj)
no, there really is no point in that. even if we were to do that, we
couldn't hold off floating references for non-GtkObject
(federico)
API freeze for GNOME 2.14 is approaching quickly. Can we please back
out GObject floating references soon?
(timj)
no, there really is no point in that. even if we were to do that, we
couldn't hold off floating references for non-GtkObjects but GObjects
anyway. the results
On Wed, 4 Jan 2006, Federico Mena Quintero wrote:
On Wed, 2006-01-04 at 12:33 +0100, Tim Janik wrote:
1. "The main motivation for providing floating references is C convenience"
http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref
That's ina
On Jan 4, 2006, at 11:51 PM, Tristan Van Berkom wrote:
Excuse me but I still dont register, why can you assume that
a function returning a GtkObject cant return an added reference ?
Such special cases such as that are handled as special cases. I can
recall implementing a few, but can't rec
muppet wrote:
[...]
For a plain GObject:
$pixbuf = Gtk2::Gdk::Pixbuf->new (...);
- C function returns object with one reference.
- wrapper adds one reference.
- binding knows that this function is a constructor, so it removes
one reference to ensure that the wrapper is the sole owner.
and
On Wed, 2006-01-04 at 12:33 +0100, Tim Janik wrote:
>1. "The main motivation for providing floating references is C convenience"
>
> http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref
That's inaccurate. We added floating references to avoid b
Tristan Van Berkom said:
> muppet wrote:
>> Tristan Van Berkom said:
>>
>>>muppet,
>>> GtkObject is a special case, it means that in your
>>>binding you have to distinguish it from a GObject and treat
>>>it differently, if there were no floating flag; you wouln't
>>>need to do this.
>>
>>
>> T
muppet wrote:
Tristan Van Berkom said:
muppet,
GtkObject is a special case, it means that in your
binding you have to distinguish it from a GObject and treat
it differently, if there were no floating flag; you wouln't
need to do this.
This is indeed the situation -- the binding treats Gt
Tristan Van Berkom said:
> muppet,
> GtkObject is a special case, it means that in your
> binding you have to distinguish it from a GObject and treat
> it differently, if there were no floating flag; you wouln't
> need to do this.
This is indeed the situation -- the binding treats GtkObjects
Gustavo J. A. M. Carneiro said:
> Qua, 2006-01-04 às 15:33 +0100, Tim Janik escreveu:
>> On Wed, 4 Jan 2006, muppet wrote:
> In the long run it will not make any difference either way since we
> will be using "full" introspection metadata which includes ref ownership
> information explicitly; or
Owen Taylor wrote:
[...]
In a sane world where your program doesnt explode
due to OOM conditions, it would read like this anyway:
if ((object = create_a_floating_object()) != NULL) {
some_container_add (container, object);
my_object_unref (object);
}
[ taking the troll
On Wed, 2006-01-04 at 10:50 -0500, Tristan Van Berkom wrote:
> Tim Janik wrote:
> [...]
> > MyObject *object;/* move to declaration section */
> >
> > object = create_a_floating_object();
> > some_container_add (container, object);
> > my_object_unref (object);
>
> In a sane world whe
Qua, 2006-01-04 às 15:33 +0100, Tim Janik escreveu:
> On Wed, 4 Jan 2006, muppet wrote:
>
> > On Jan 4, 2006, at 6:33 AM, Tim Janik wrote:
> >
> >> On Tue, 3 Jan 2006, Federico Mena Quintero wrote:
> >>
> >>> The "floating" flag was introduced in GtkObject to:
> > ...
> >>> 2. make things easie
Tim Janik wrote:
[...]
Actually (to throw a wrench in things), the floating flag *does* make
language bindings easier. The GtkObject wrapper can *always* do an
unconditional ref and sink; if it was floating, e.g., returned from a
constructor, the object is now owned by the wrapper, and if not,
Tim Janik wrote:
[...]
MyObject *object;/* move to declaration section */
object = create_a_floating_object();
some_container_add (container, object);
my_object_unref (object);
In a sane world where your program doesnt explode
due to OOM conditions, it would read like this anyway:
On Wed, 4 Jan 2006, muppet wrote:
On Jan 4, 2006, at 6:33 AM, Tim Janik wrote:
On Tue, 3 Jan 2006, Federico Mena Quintero wrote:
The "floating" flag was introduced in GtkObject to:
...
2. make things easier for language bindings.
this is not quite right. the floating flag is of n
On Jan 4, 2006, at 6:33 AM, Tim Janik wrote:
On Tue, 3 Jan 2006, Federico Mena Quintero wrote:
The "floating" flag was introduced in GtkObject to:
...
2. make things easier for language bindings.
this is not quite right. the floating flag is of no use to langauge
bindings,
if i
On Tue, 3 Jan 2006, Federico Mena Quintero wrote:
Sinkability considered harmful
--
The "floating" flag was introduced in GtkObject to:
1. keep this convention
2. make things easier for language bindings.
this is not quite right. th
On Tue, 2006-01-03 at 19:22 -0500, Owen Taylor wrote:
> On Wed, 2006-01-04 at 00:15 +, Gustavo J. A. M. Carneiro wrote:
> > On Tue, 2006-01-03 at 18:52 -0500, Owen Taylor wrote:
> > > On Tue, 2006-01-03 at 23:43 +, Gustavo J. A. M. Carneiro wrote:
> > > > Completely agree. Interesting re
On Wed, 2006-01-04 at 00:15 +, Gustavo J. A. M. Carneiro wrote:
> On Tue, 2006-01-03 at 18:52 -0500, Owen Taylor wrote:
> > On Tue, 2006-01-03 at 23:43 +, Gustavo J. A. M. Carneiro wrote:
> > > Completely agree. Interesting read too. I'd just like to add one
> > > more thing.
> > >
>
On Tue, 2006-01-03 at 18:52 -0500, Owen Taylor wrote:
> On Tue, 2006-01-03 at 23:43 +, Gustavo J. A. M. Carneiro wrote:
> > Completely agree. Interesting read too. I'd just like to add one
> > more thing.
> >
> > g_object_new *should* always return a new reference, to be owned by
> > th
On Tue, 2006-01-03 at 23:43 +, Gustavo J. A. M. Carneiro wrote:
> Completely agree. Interesting read too. I'd just like to add one
> more thing.
>
> g_object_new *should* always return a new reference, to be owned by
> the caller. It usually does, except for g_object_new(GTK_TYPE_WINDO
01-03 at 17:07 -0600, Federico Mena Quintero wrote:
> Sinkability considered harmful
> --
>
> Why do we have sinkable objects, i.e. gtk_object_sink()?
>
> It is a historical artifact. Early versions of GTK+ did not have a
> consistent or even correc
Sinkability considered harmful
--
Why do we have sinkable objects, i.e. gtk_object_sink()?
It is a historical artifact. Early versions of GTK+ did not have a
consistent or even correct policy for memory management.
In 1997, Marius Vollmer (a Guile hacker with
28 matches
Mail list logo
