My main concern about this kind of approach is that we're hovering between two different object systems. SPObject itself is actually derived from the GObject class structure. However, this patch switches to C++-style inheritance. As such, we should make sure that we don't break the expected behaviour of GObject objects.
Really, I guess it would be good to derive SPObject from Glib::ObjectBase (I.e. use the c++ bindings from upstream) so that we can lose the need for GObject-style inheritance.
AV
On Thu, 2013-03-28 at 16:59 +0100, Markus Engel wrote:
> Okay,
> so here's my branch: https://code.launchpad.net/~engelmarkus/inkscape/cppify
Thanks Markus,
Looking at the changes, the scope and breadth of files changed indicates
that we should deal with merging this branch quickly. I'm tempted to
merge it and deal with the fallout, but I'd like to hear from other
devs.
Martin,
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel