Am I right in thinking that many of the issues are down to the absence of a ::destroy signal in GObject? (i.e. things are only getting cleaned up if we explicitly say so).

In fact, maybe instead of replacing "gtk_object_destroy" with "g_object_unref" all over the place and hoping for the best, it would be less of a disaster if I just adopted all relevant bits of the dead GtkObject parent class from upstream into SPCanvasItem? That way, we'd preserve all the signalling stuff and the new "sp_canvas_item_destroy" function would behave exactly the same way as the old "gtk_object_destroy".

Any thoughts, or shall I just have a go at this?

AV

On 7 June 2012 09:07, Jon Cruz <jon@...18...> wrote:

On Jun 5, 2012, at 11:05 AM, Alex Valavanis wrote:

...

Hi All,

I've created a branch at lp:~inkscape.dev/inkscape/gtk_object_removal [1] in which I have started trying to rebase SPCanvasItem on GObject rather than GtkObject.

I don't really know what I'm doing with Glib/GObject so I have made some (un)educated guesses about how to replace bits of the functionality!

The code compiles and gets rid of a huge number of the remaining GTK+3 build errors, but there are major runtime issues (lots of crashes & Glib warnings). Please could someone who knows about Glib memory management take a look at this and give me a couple of pointers about what I'm doing wrong? Am I completely on the wrong track here?

Thanks,

Alex

[1] http://bazaar.launchpad.net/~inkscape.dev/inkscape/gtk_object_removal/change...

Nothing jumps out right off hand. I'll take a longer look and see if I can match up all the conversions.