GtkObject is gone (was GTK3 breakage)
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
Re: GtkObject is gone (was GTK3 breakage)
On Tue, 2010-09-28 at 09:55 +0200, Murray Cumming wrote: 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. g_object_run_dispose() is very similar to gtk_widget_destroy() in terms of memory management semantics. The main difference is that there's no ::destroy signal emitted. - Owen ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: GtkObject is gone (was GTK3 breakage)
On Tue, 2010-09-28 at 10:11 -0400, Owen Taylor wrote: On Tue, 2010-09-28 at 09:55 +0200, Murray Cumming wrote: 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. g_object_run_dispose() is very similar to gtk_widget_destroy() in terms of memory management semantics. Yes, after talking on irc we came to the same conclusion. The main difference is that there's no ::destroy signal emitted. For some reason we use a qdata destroy callback to detect GObject destruction anyway, instead of the destroy signal. -- 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
