bulia byak wrote:
The greatest problem being, they should not be entirely "normally" edited. They need to be presented as something different than the main path, otherwise it will be very confusing for the user ("what are these ghost paths? can I just delete them?")
That doesn't require any LPE-specific code in the manipulators, just a function to set the outline color and some logic in whatever examines the selection and creates the manipulators.
Why LPE on a group is a hack? It is simple and valid SVG, and it works.
Again: the path-to-path limitation is indeed a limitation, but that's by design. These are PATH effects, and the entire API is oriented this way. For different things, invent different concepts.
You just answered yourself: the current repr would be satisfactory if LPEs were a strict path-to-path mapping, but they are not. For example, Bend is not a path-to-path mapping, it is two-paths-to-path mapping. A group is not a path, so LPE on a group doesn't fit the path-to-path paradigm either. I would have no problems with the current representation if it was really intended to be used for pure path effects, but it is not.
If all you do with your proposal is extend source objects from paths to paths plus shapes, then you don't need to bother - as I said, we already support LPE on shapes (those that use svg:path, at least, which means all except rect for now).
The old repr requires that we turn all input shapes into paths and preserve editing capability using extra attributes, so the manipulators need to know how to edit both those representations; in the new one they only need to know how to edit the correct semantic representation (svg:rect or svg:ellipse).
No no no. Node tool must NOT depend on any dialog for any of its functionality. This breaks encapsulation in a bad way. The dialog may be on or off, this should not affect the tool. The tool must know itself what to do for LPE parameter paths.
The node tool does not depend on this dialog, it's just a way to select invisible objects.
Yes, it can be MUCH simpler, because the manipulators can be created for the internal XML elements.
Just like the current nodepath can also be fed a path in defs, and edit it just fine :)
That's right - it's proven that editing invisible objects that have normal XML elements is simple, so why not take advantage of this for path effects as well, rather than inventing clever ways to preserve editability?
OK, can you please write out a detailed XML for your representation of this:
Two paths, A and B, with different style (one red, the other green).
A has Bend applied, linked to some path C on canvas as its bend path.
B has Pattern along path applied, linked to some path D as its pattern
path.
- A and B are grouped and the group has Envelope applied, linked to
the same C as its bottom envelope path. Note that in the result, A and B still have different style.
I can do this with current implementation, and I can edit all aspects of it. Please show me how it will look in your representation and in what ways it will be easier to implement or edit.
If I understood the description correctly, it would look like this (with nested switches):
svg:switch inkscape:envelope-deformation <svg:g inkscape:param-name="object"> svg:switch inkscape:pattern-along-path <svg:path inkscape:param-name="path" id="pathA" ... /> <svg:use inkscape:param-name="pattern" href="url(pathD)" ... /> </inkscape:pattern-along-path> <svg:path ...(result of pattern along path)... /> </svg:switch> svg:switch inkscape:bend <svg:path inkscape:param-name="path" id="pathB" ... /> <svg:use inkscape:param-name="bend-path" href="url(#pathC)" ... /> </inkscape:bend> <svg:path ...(result of bend)... /> </svg:switch> </svg:g> <svg:use inkscape:param-name="envelope-bottom" href="url(#pathC)" ... /> </inkscape:envelope-deformation> <svg:path ...(result of envelope)... /> </svg:switch>
Somewhere else in the document: <svg:path id="pathC" ... /> <svg:path id="pathD" ... />
In the new repr every parameter can be given either 'by value' (by using it directly) or 'by reference' (by using its clone). By the way, if some other version of Inkscape does not understand e.g. inkscape:bend, then it could use its result path and only the bend part would not be editable, instead of the entire effect. Right now it seems that even if only one effect in the stack is not recognized, the entire stack is not editable.
It's wrong to consider only implementation forgetting about the readability of the XML source. If you have two sibling paths and they play very different roles, it must be clear from the XML code what is what.
An attribute like inkscape:param-name can be used, which I added to the example above.
So, are you saying that the old representation makes it more difficult for you to achieve the multiple-paths-and-knotholders-at-the-same-time goal? In what way? Please describe some specific problems and maybe we can figure it out together.
Having multiple knotholders isn't a big problem, but to select only some of them we need a different concept of selection, because some of the shapes to edit share an XML node (for example, if I stack two effects on a path, the a single XML element represents 3 editable objects: two path effects and the original path. In the new repr we just put the items to edit in Inkscape::Selection.
I don't say it is incapable of providing all the features we want - probably it could provide them, but only after we made a huge mess with a lot of obscure bugs and quirks and alienated everyone out of working with tool code, because every non-trivial change would break LPEs in some subtle way.
I don't see this at all.
OK, maybe that was an overstatement. But if we have to edit two different representations of a rectangle, then something is wrong, especially since the second one (path + attributes) is mostly useless outside of 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.
Regards, Krzysztof