Re: Various questions about Gtk::PlacesSidebar

[Murray Cumming <murrayc murrayc com>]

On Tue, 2013-09-03 at 21:20 +0100, Chris Vine wrote:
> On Tue, 03 Sep 2013 09:40:19 +0200
> Murray Cumming <murrayc murrayc com> wrote:
> > On Mon, 2013-09-02 at 16:13 +0200, Krzysztof Kosiński wrote:
> > > 2013/9/2 Kjell Ahlstedt <kjell ahlstedt bredband net>:
> > > > Objects of classes that derive from Gtk::Object are not put in
> > > > Glib::RefPtr<>s. I'm not sure why.
> > >
> > > I'm also a little confused by this but it probably has something to
> > > do with Gtk::manage().
> >
> > GtkWidgets don't use simple reference counting in the GTK+ C API. They
> > can be destroyed at any time regardless of the reference count. So we
> > can't use RefPtr with them easily.
>
> That is not really true.  widgets are always (and only) destroyed when
> their sunk reference count reaches 0,

Calling gtk_widget_destroy() will destroy a widget. Containers destroy
their child widgets by default in GTK+ with C.

>  and incrementing the reference
> count before removing a widget from a container is how you move them
> between containers.

Yes, that is necessary, though we do that for you in gtkmm.

>  There is no problem with holding a non-top level
> widget by RefPtr provided you call g_object_ref() on the C object
> first, which is inconvenient with gtkmm and leaves the opportunity to
> forget to do so. So it is inadvisable.

I believe that this would lead to having RefPtrs pointing to invalid
(destroyed) GtkWidget instances.

I suppose you could improve this by letting the RefPtr know when the
widget is going to be destroyed, allowing us to check the RefPtr at
runtime, but I don't think you could stop the GtkWidget destruction, I
don't think GTK+ would want you to, and I don't think it would be a nice
C++ API.

> With top level windows it would be highly confusing to take your own
> reference in this way.  You expect a top level window to disappear when
> you call gtk_widget_destroy() on it to drop GTK+'s top level reference,
> not hang around.


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