SVGPathElement should not inherit from SVGPathParser

• Component: SVG
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

SVGPathElement should not inherit from SVGPathParser

The current design makes it very difficult for things like SVGAnimateMotionElement to parse paths.  They have to create a heavy-weight SVGPathElement, when all they want is something capable of parsing a path into a SVGPathSegList

SVGPathElement is-a SVGPathParser, when it really should have-a SVGPathParser.  all of the "this->createMoveTo" calls would just change to "pathCreator->createMoveTo" calls, and the element could be passed into the SVGPathParser.  There could even be an SVGSegList specific subclass which took a seglist (or created one and then returned it).  SVGPathSegListPathParser perhaps?

[Rob Buis]

Created attachment 14845 [details]
First attempt

This is not a full fix for this bug, but it helps the SVGAnimateMotionElement problem. Let me know if that is enough for this bug and whether SVGPathElement should be changed too.
Cheers,

Rob.

[Eric Seidel (no email)]

Comment on attachment 14845 [details]
First attempt

It's a rather incomplete fix.  Basically you're just adding another class to codify the existing hack of needing to allocate a class to do the parsing.  If you're going to add this PathBuilder class, i would think you would make SVGPathElement use it too.  I don't think that this fix is really much better than the existing hack.  If you got rid of the other instances of classes inheriting from SVGPathParser, that would be a more complete fix.  We can chat about this on IRC if you like.

[Rob Buis]

Created attachment 14896 [details]
Addressing Eric's issues

This seems somewhat nicer IMHO.
Cheers,

Rob.

[Eric Seidel (no email)]

Comment on attachment 14896 [details]
Addressing Eric's issues

Looks good to me!  Great work!

[Rob Buis]

Landed on feature branch in r22068.