Re: gtkmm 3.0.

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 25 Mar 2010 00:00:52 +0100
Oscar Lazzarino <oscar lazzarino gmail com> wrote:
> On Wed, Mar 24, 2010 at 11:55 PM, Germán Diago
> <germandiago gmail com> wrote:
> > Hello. I've been using gtkmm for two small projects now.
> > From my usage, I would like to make some (realistic) suggestions.
> >
> > I see there are some pieces of the api where Glib::RefPtr is used,
> > and some others where it's not used at all. As gtkmm 3.0
> > approaches, there's an opportunity to break API and ABI.
> >
> > I would suggest to treat every object in the same way. gtk+ uses
> > reference counting.
> > What I would suggest is something that gobjectconsume
> > (http://live.gnome.org/GObjectIntrospection/GObjectConsume see
> > examples)
> > already does:
> >
> > to wrap the c type in this way:
> >
> > Gtk::Button button("push me");
> > Gtk::Button samebutton = button; //increases reference count.
> >
> 
> FWIW, I think keeping explicit RefPtr helps keeping in mind that a
> widget should not be copied and can not be placed in multiple places.
> 
> But I agree that some uniformity would be nice (and I would like
> seeing RefPtr everywhere).

On the first suggestion, I think it would be a misuse of the GObject
reference counting system to use it to copy wrapper objects for
widgets and similar components, because it would give the erroneous
impression that there are two different widgets resulting from the copy
when in fact there is only one (whereby for example any change to one
would silently change the other). Hidden shallow copying without
provision for subsequent copying on write is rarely the correct
solution to a programming problem.  As it happens, copying widgets is
also in my view semantically inappropriate given the function they
perform, although I can see that others may disagree with that.

On the second suggestion (using RefPtr everywhere) I think gtkmm has
got its use of RefPtr wrong in parts, by confusing strong and weak
ownership.  This is particularly pertinent where GTK+ provides getter
functions.  At present gtkmm indiscriminately returns all pure
Glib::Object objects by RefPtr (by a "pure Glib::Object" I mean one
which is not a Gtk::Object). 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.

At present in gtkmm all Gtk::Objects are wrapped as independent objects
(what the referenced article refers to as value objects) and all
pure Glib::Objects are held by RefPtr.  The reason for this is that
only Gtk::Objects have a destroy signal which can be invoked by
calling gtk_object_destroy() on the underlying C object in the wrapper's
destructor which will command a container class to drop its reference
to the C object and so allow it to be destroyed.

It would be perfectly feasible to have a scheme whereby all Gtk::Objects
(ie all widgets) are only held by RefPtr.  Conversely, going back to the
first suggestion (but leaving assignment out of it), it would also be
possible to follow the example of, say, PyGtk and to drop RefPtr
entirely and to have all Glib::Objects (where strong references are
appropriate) held as independent value objects, provided it is
recognised that the lifetime of the underlying C object may be longer
than that of its C++ wrapper where these are not Gtk::Objects.  One way
of dealing with this is to have one set of classes, Gtk::Objects, where
having a container manage the class is (as at present) optional and
another set of objects, pure Glib::Objects, where it is compulsory.

Whether this is worth the effort is debatable (although it is an issue
which for example PyGtk and java-gnome have had to deal with).

Overall, I would like to see weak references dealt with correctly if the
current gtkmm approach is kept.

Chris