On 25-11-2014 5:46, Krzysztof Kosiński wrote:
- Better XML representation for path effects. Currently code-wise LPE
support is a mess and this is in large part caused by piggybacking LPE data on normal objects instead of putting it into dedicated objects with svg:switch fallback. The whole design of storing all LPE parameters as attributes on a special node instead of as separate objects in defs is a nightmare to work with.
Some counter text here: The design of having all parameters of one LPE in a defs node has been very nice to work with (I think I am one of the /very/ few that actually worked with this?). Previous to the node tool changes, we could edit a path's original path and LPE bend path at the same time perfectly fine. What happened to this? ;-) :P
Yes, the LPE design is simple. I agree parts of it have turned into spaghetti, mostly because people wanted LPE's to work on groups, text, their shoelaces, etc ;) Also, cruft has collected because of unfinished work that never got removed. For advanced work, something new is needed. LPE was never meant to do bool ops on two paths. Nor was it meant to be generative (create path out of nowhere). The thing you describe with clones actually did work pretty nicely, but got distroyed in experimental by the "Fill Between Many" change. I don't know why that change was made and it will have to be reverted I think.
One thing to keep in mind while designing a broader math operations framework: gradients are (in my opinion) over designed, with too many objects and different tree nodes for just one gradient. This actually made and makes our gradient code buggy and hard to work with.
Fair warning, Johan