bulia byak wrote:
OK, I stand corrected: our LPEs are not path-to-path. They are more like anything-to-path. That anything can be a single path, multiple paths with different roles, links to paths, or any other data. For example, it is easy to imagine a LPE for variable-width strokes where the widths are recorded as an array, stored in the path effect in an attribute. The output path will then depend on this data. Yes, we will need a new parameter type and a new attribute for each new kind of such data, but adding new parameter types is relatively straightforward thanks to Johan's code.
The only problem I have with this is that the "ground path" is not a real object. If it was preserved in the defs (even stripped of style, etc.) rather than in a special attribute, it would be nicer. Other than this, I agree with JFB that it might be best to leave path effects alone until the more powerful replacement (vector effects) is created.
- svg:use has its cost. Inkscape clones have a lot of code for
behavior when the original is transformed or deleted.
That there is lots of code for this stems from weak href management in our code, for which I have a solution which I will post today or tommorow. Basically objects have hrefcounts and 1-way references where in fact we need 3-way references. With good href management, most such code could be simplified into one or two recursive loops. Same goes for clipboard code.
What you propose amounts to adding more such stuff, one new Inkscape element type per LPE, which will be hardly maintainable.
Why? Most of the code (I'd say at least 80% of the hard stuff) could be shared between all LPEs, because we can use a common base for their SP tree objects that would provide most of the functionality needed by LPEs. Having one SPObject per LPE is a must anyway.
Also this violates the XML philosophy which says, "ignore anything you don't understand." If you have container elements in Inkscape namespace, other renderers will have to _descend_ into these elements instead of ignoring them completely. Yes, they are only present in the Inkscape branch of a switch, but it's a violation nevertheless.
Are you trying to say that if I put a standard SVG element inside an Inkscape-specific element, then an SVG-conforming parser will try to render the inner SVG element? No, this should never happen. After reading the relevant bits of the spec, that is definitely not the behavior I would expect from any conforming implementation. SVG user agents are only required to include the unknown elements in the DOM (if applicable), but should ignore them when rendering. For me this means that the renderer should not look inside the unknown element for anything SVG-like, because doing this is not ignoring, it is actively trying to interpret an unknown element. As long as we do not have XML syntax errors, nothing wrong will happen, unless the viewer is totally broken.
Just as we do when a path has a clippath and a mask. If we can do this for clips/masks, why not do the same for LPE parameters?
There is a difference: the LPE ground path is not an object, while all other path parameters are. If this minor nonorthogonality was fixed then it would be OK.
I don't understand your point about selecting knotholders - they are not selectable and don't need to be selected.
No, it's not about selecting knotholders, it's about reusing the existing Inkscape::Selection as a list of objects for which to display manipulators. If some path parameters are not objects, then it's harder to use the selection to determine what should be edited and what shouldn't. What I had in mind is to have an object tree in place of the current LPE stack, and the user would select the invisible shape parameters to edit by selecting them using that dialog. If the entire LPE was selected, then based on the preferences only the LPE's controls would be shown, or manipulators for everything would be shown; while when selecting some internal objects in the LPE, only the selected objects would have their manipulators shown. It's very similar to how selecting in groups work. Even when some objects are grouped, you can select inside the group. I want to reuse this fact for LPEs.
PS: Another possible change that gives similar benefits and probably needs less changes is if we replace inkscape:original-d with a hyperreference to the original shape, and just move that shape to defs instead of moving its data to a special attribute. That's how SVG 1.2 vector effects work - all shape parameters are given using a href.
Yes, this is possible too, but I don't see why duplicate the style, id, and the rest of it when I only need one attribute?
The style can be stripped when the path is moved to defs. Duplication is not a problem in that solution, but there might be some problems with transforms. I think this solution can be realistically applied to the existing path effects (the original one is better to implement as something completely separate). We only need to copy the original path (with its style stripped) to defs, instead of moving its data to another attribute. This would allow for really symmetric boolean operations, and could probably simplify the code a bit, because there would be no fundamental difference between the source path and other path parameters.
Regards, Krzysztof