Re: Various questions about Gtk::PlacesSidebar



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]