On Monday 11 April 2005 01:53, Murray Cumming wrote:
[snip]
In general we avoid guessing such (undocumented) internal lifetime
details, and just do the same thing with all GObjects. C coders do
whatever works, with lots of errors along the way.
Typically, in a case such as this, where the
gtkmm uses
Glib::RefPtr for things derived from GObject even where GTK+ does not
expect
you to manage the lifetime of the unwrapped object. Taking the example of
gtk_tree_view_get_selection(), in the gtkmm equivalent
(Gtk::TreeView::get_selection()), the Gtk::TreeSelection object is
On Sunday 10 April 2005 12:11, Murray Cumming wrote:
gtkmm uses
Glib::RefPtr for things derived from GObject even where GTK+ does not
expect
you to manage the lifetime of the unwrapped object. Taking the
example
of gtk_tree_view_get_selection(), in the gtkmm equivalent
On Tuesday 05 April 2005 22:57, Matthias Kaeppler wrote:
Hello,
is there a general rule of thumb which classes require access through a
Glib::RefPtr? For example, based on the gtkmm tutorial, a TreeModel is
constructed directly, while a TreeView is handled through a RefPtr. What's
the point?
