On Thu, 24 May 2007 17:20:26 -0300, "bulia byak" <buliabyak@...400...> wrote:
Therefore, we only need to save the original d, i.e. just a string.
It'll become more important when we start needing more inputs beyond a single path (e.g. for eventually reworking the calligraphy tool as a path effect as had been discussed, we'd also need intput paths representing e.g. pressure and tilt over time).
Why copy and ref the entire element? This will introduce a ton of unnecessary problems of all kinds
- inherited styles,
vePathRef only takes the d= from the <path>, so we need only create a bare <path> to contain the original path data.
(One style issue I _do_ forsee with my suggestion is between setting styles on the switch versus setting styles on the result path.)
relinking clones
Don't we have an existing facility for moving an original object around in the document without breaking clones (e.g. when grouping)? It'd be the same thing here; on conversion to a "live effect", the existing path element, with its original id, would become the final child of the switch.
refcounting
That should be covered via the existing tree refcounting, the xlink:href machinery and inkscape:collect.
, etc. etc. - not only for the person who implements LPEs but, more importantly,
for everyone else who will have to adapt lots and lots of code all around the codebase to work with effected paths.
The idea would be that most things reference the final "output" <path> in the switch statement, so very little code would need to change (it would still be referencing an ordinary path, whose d= corresponds to the visible path).
Similarly, I see no reason to use <switch>. For flowText, using switch is a sad necessity. But here, we can do everything we want in the same path element, via inkscape: attributes, without adding another level of nesting which will make work with such constructs a lot more cumbersome.
Introducing additional XML structure becomes necessary anyway if we want to be able to stack path effects, which I can promise will start getting requested if we release with non-stackable effects. The question is -- how far do we want to reinvent SVG's vector effects without actually using them? If we allow multiple inputs and stacking, the only difference is going to be that we allow custom effect types, and vector effects give us more rendering options.
For the sake of getting Johan's SoC done, I'm content with doing this the expedient way, but I'm reluctant to do a release with the feature enabled as-is if there's going to be a lot of pressure to evolve it into a replacement for SVG vector effects, which I think there will be.
-mental