Re: gtkmm 3.0.

[Murray Cumming <murrayc murrayc com>]

On Thu, 2010-03-25 at 10:52 +0000, Chris Vine wrote:
> On Thu, 25 Mar 2010 09:46:08 +0100
> Murray Cumming <murrayc murrayc com> wrote:
> > On Thu, 2010-03-25 at 01:57 +0000, Chris Vine wrote:
> > > In cases where GTK+ does not in fact
> > > intend ownership to be passed, gtkmm gets round this by incrementing
> > > the reference count in the getter function, thus neutering the
> > > RefPtr, but also leaving open the possibility of a reference being
> > > owned by a user to an invalid object.  In such cases the object
> > > should really be returned by a simple pointer or a weak pointer. 
> > 
> > Do you have an example GTK+ C function for that? Maybe it should even
> > be in gtkmm's bugzilla.
> 
> I am thinking of all those GTK+ getter functions where the user is
> not expected to call g_object_unref() when finished with manipulating
> the return value. These objects are usually owned by another GTK+ object
> (the one whose method the getter function is) and will have parts of
> their implementation which become invalid when the owner is finalised
> (they are expected to be destroyed at the same time).
> 
> Particularly obvious examples are manager classes such as a
> GtkTreeSelection object, which is owned by a GtkTreeView object.  It
> is part of the TreeView's implementation and is completely invalid when
> the TreeView no longer exists.

What would some application code look like if you fixed this in the
gtkmm API?



-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com