On Tue, Nov 25, 2014 at 08:54:41PM +0100, Johan Engelen wrote:
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.
Ah, good retrospective.
It's impressive that LPEs have been a source of so much community contribution. It's hard to predict when an extensible feature is going to receive a lot of outside contribs, but perhaps for future lesson learned is that we need a project infrastructure that allows us to share these contributions outside the core inkscape package. Then, if we have this as a more general purpose solution, then when others come up with clever extensible mechanisms they can use this to collect and distribute their bits. I don't know whether this would be in the form of a 'contribs' tarball, or a plugin repository, or good/bad/ugly packages, or an interactive downloader ala ClipArt; but some method for sharing out these unofficial bits, would allow us to enforce some quality control on them, without violating our culture of open contributions.
Bryce