On Sun, 2010-09-26 at 16:08 +0200, Benjamin Otte wrote: > - GtkObject is gone > With the existance of GObject, GtkObject became unnecessary. The > functions it provided are now either part of GObject or GtkWidget.
For gtkmm, I welcome this for the little GtkAdjustment, GtkFileFilter and GtkRecentFilter objects. Now they are simple reference-counted objects. But for some other more commonly-used objects (GtkWidgets, GtkCellRenderer, GtkTreeViewColumn), I'd like to avoid changing our memory management too much. Is there no way now to force an object to be destroyed? Right now, we let our GtkWidgets be destroyed when their C++ wrappers go out of scope automatically. For instance, when a C++ class's destructor automatically destroys its member instances, like so: http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-helloworld.html.en Our GtkWidget classes should be OK, because we can use gtk_widget_destroy() instead of gtk_object_destroy. But I wonder what to do with GtkCellRenderer and GtkTreeViewColumn. We could just unref the underlying object, but once the wrapping C++ object has been destroyed, the vfuncs (and default signal handlers) will fall back to default C implementations, if any, and this could even cause different UI behaviour. If I must, then I'll force Gtk::CellRenderer and Gtk::TreeViewColumn to be used only via RefPtr<>, like other reference-counted objects, but this will probably just annoy C++ programmers. They feel like widgets, so it seems odd for them to not have similar memory management. -- murr...@murrayc.com www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list