Creating a new subclass works almost like before.

Header file: #define SP_TYPE_xy (sp_xy_get_type ()) #define SP_xy(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), SP_TYPE_xy, SPxy)) #define SP_xy_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), SP_TYPE_xy, SPxyClass)) #define SP_IS_xy(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), SP_TYPE_xy)) #define SP_IS_xy_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), SP_TYPE_xy))

class Cxy;

class SPxy : public SPab { public: Cxy* cxy;

// Add any non-virtual members };

struct SPxyClass { SPabClass parent_class; };

class Cxy : public Cab { public: Cxy(SPxy* spxy); virtual ~Cxy();

virtual void onBuild(SPDocument* doc, Inkscape::XML::Node* repr); // Override whatever you want

protected: SPxy* spxy; }; =========================

Source: G_DEFINE_TYPE(SPxy, sp_xy, SP_TYPE_ab); static void sp_xy_class_init(SPxyClass *klass) {}

Cxy::Cxy(SPxy* xy) : Cab(xy) { this->spxy = xy; }

Cxy::~Cxy() {}

static void sp_xy_init(SPxy *xy) { xy->cxy = new Cxy(xy); // create corresponding virtual pad

delete xy->cab; // remove virtual pad of parent class xy->cab= xy->cxy; // replace it xy->clpeitem = xy->cxy; xy->citem = xy->cxy; xy->cobject = xy->cxy;

// Further init }

void Cxy::onBuild(SPDocument* doc, Inkscape::XML::Node* repr) { SPxy* object = this->spxy;

Cab::onBuild(doc, repr); } =========================

You just put your virtual functions into the other class. Of course this is temporary and these two classes will be combined afterwards. As the two corresponding objects have pointers to each other, you can do whatever you want. Later, these pointers will be replaced by a "this".

Markus

-----Ursprüngliche Nachricht----- Von: Alex Valavanis [mailto:valavanisalex@...400...] Gesendet: Donnerstag, 28. März 2013 19:21 An: Markus Engel Cc: Martin Owens; Inkscape Devel List Betreff: Re: [Inkscape-devel] C++ification of the SPObject tree

Well, I still think it's a great thing to do, and if there's a path toward getting rid of the GObject dependency, it's probably worth committing. My concerns were basically along the lines of wondering what happens if someone tries to create a new subclass somewhere far down the SPObject tree, but they just use GObject inheritance. Will it still work?

On 28 March 2013 17:30, Markus Engel <p637777@...1081...> wrote:

...

As such, we should make sure that we don't break the expected behaviour of GObject objects.

Well, what is the expected behavior? At the moment, the GObject type system is only needed for those casting macros that can easily be replaced by dynamic_casts and for object instantiation. Reference couting can be replaced by using shared_ptrs. I’ve got some code here where I already replaced the factory and the macros and it works, but there’s quite a lot left to do. As soon as the factory is replaced, the SP classes can simply be combined with the corresponding C classes, removing GObject from the derivations. This is not possible now because g_object_new doesn’t fill in the vtable but its own type

information.

Markus

Von: Alex Valavanis [mailto:valavanisalex@...400...] Gesendet: Donnerstag, 28. März 2013 18:15 An: Martin Owens Cc: Inkscape Devel List; Markus Engel Betreff: Re: [Inkscape-devel] C++ification of the SPObject tree

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 28 Mar 2013 16:52, "Martin Owens" <doctormo@...400...> wrote:

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&reg; 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel