On Thu, 2011-07-21 at 13:35 +0100, Alex Valavanis wrote:
One of the main issues here is that SPCanvasItem (our custom implementation of GnomeCanvas) is a subclass of GtkObject. GNOME Evolution got round this problem in their own copy of GnomeCanvas by changing the parent class to GObject. This introduces a couple of issues that I could use some help with:
- What do we do about the "::destroy" signal? GObject has no such
signal... there is a "::dispose", but is it functionally equivalent? Can we just rename all the gtk_object_destroy calls to g_object_run_dispose, and replace the custom GtkObject.destroy implementations with GObject.dispose? Does the same apply for GtkObjectClass and GObjectClass?
They're slightly different, but for most people they should be equivalent. To over-simplify a bit, dispose is when you give up your references and destroy is when you free your memory. Most people just care about "when is this going to die" which both signify. The reason for two is to clean up inter-dependencies.
I would guess, and I haven't looked closely enough to know, that it would make sense to have the Canvas widget and perhaps others inherit from GtkWidget instead of GtkObject. This would retain some of the destroy functionality. With the new Cairo renderer this could be a huge gain as basically all a Widget is in GTK3 is a Cairo surface....
- What do we do about the GtkObjectFlags enumeration? This is
deprecated, and no equivalent is available in GObject. Can we just add a typedef for a "SPCanvasItemFlags" enumeration in sp-canvas-item.h, and add a "guint32 flags" member to SPCanvasItem?
Yes, I think making a new flags enum makes the most sense.
--Ted