On Sun, 08 Mar 2009 22:50:58 +0100 Murray Cumming <murr...@murrayc.com> wrote: > On Sun, 2009-03-08 at 17:33 +0000, Chris Vine wrote: > > In glib-2/gtk+-2 a lot of the code formerly in GtkObject was moved > > to GObject. There is no significant difference in memory management > > between a pure GObject and a GtkObject, other than the floating > > reference, which amounts to very little (it is a device to make it > > easier for containers to take ownership). They could both be wrapped > > identically in gtkmm, as they are in other bindings such as PyGTK > > and java-gtk+. They have not been, and that's fine. > > You are welcome to try to create a patch that could be applied for > gtkmm 3.0. If GTK+ 3.0 really happens as planned (not a plan I like) > then we will be forced to do an ABI break anyway.
OK. The changes would be quite extensive so if and when GTK+-3 comes out lets get a consensus on what approach is best and whether you want to go through with it. It would be possible to standardise on all Glib::Objects/Gtk::Objects being managed by intrusive pointer manipulating their reference counts, as is presently done by gtkmm for pure GObjects, or to present all Glib::Objects/Gtk::Objects as native C++ objects with local scope and/or creation by the new expression. In either case, this would allow the code to be significantly simplified. Since glib-2.10, even the floating reference code has been moved from GtkObject into GObject - now pure GObjects can be given a floating reference with g_object_force_floating() (the only difference between GObject and GInitiallyUnowned is that the constructor of GInitiallyUnowned does that for you). So they could all be dealt with through floating references if that were helpful to the implementation (but it probably isn't, depending on how GTK+-3 approaches the issue). Chris _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
