Arcadie M. Cracan wrote:
From what I could understand Krzysztof has implemented these
PathManipulators,
which seem to extend (am I wrong?) the ShapeEditor or the KnotHolders so as to provide means for every kind of LPE to define its own ways to edit the paths, so I could exploit this for connection points I think.
PathManipulator does not use ShapeEditor or Knotholder. I will write a new object that will more or less replace ShapeEditor (it will store a list of shape manipulators and allow to act on them in a generic way), and Knotholder will go away entirely and be replaced with a separate object for each shape: EllipseManipulator, RectangleManipulator, PolygonManipulator, etc. There will also be a function that allows you to create a manipulator from an SPItem that will edit it; it will eventually be made into a virtual method, so you will be able to write 'spobject->getManipulator()' to create a manipulator for an SPObject without knowing its type (but it could return NULL if the object doesn't support manipulation, like a clone).
Since the talk arrived to a potential LPE re-design, could you consider also these "virtual" LPE, which are not in fact path effects, but more path features or qualities?
It can be done with the new representation. Either the path effect could make its parameters normally visible and selectable, or it could implicitly create 'unmovable' clones (ones that are always at the same place as the source object - as I said before, in addition to the default clone compensation setting it should be possible to set the compensation mode per clone). I'm leaning toward the second idea because if we consider 3 items where each 2 are joined by a connector, it becomes obvious that the 'connector' path effect cannot take ownership of the objects. Another way to implement connectors is to create a different switch like this: svg:switch <inkscape:connector from="#object171" to="#object223" /> <svg:path ...(the appearance of the connector)... /> </svg:switch> The new XML representation would turn path effects into ordinary objects, and since it relies heavily on switch handling it would benefit all other things that would rely on switches in future, like flowtext, the above connector example, and many more.
Still there are things that cannot be done with current LPEs: for example having a label (svg:text) on a shape as an LPE would turn that shape into a path (which is wrong), but this could be a usable feature (having labels on shapes that could adapt rotation, horizontal/vertical flip in a proper way).
This is another place where the new representation turns out superior, and I didn't think of it before: the result of the effect is not limited to a path. For the label effect, instead of converting to path, we would just output the actual objects used: for example, for a rectangle with a text label, we would output svg:g that contains svg:rect and svg:tspan. The switch could contain an inkscape:object-label element in the first branch and a group of the two objects (the labelled one and the label) in the fallback fork.
This opens up tons of possibilities: 1. Editable tilings where you can drag control points to adjust the spacing and tiling area - something like the clone tiler dialog but does not cause you bodily harm. (Currently you have to tweak all parameters by putting numbers in entry fields.) 2. Text effects that output actual text rather than paths, for example an effect that scatters the letters. 3. More types of gradients! (we put a clipped svg:image or clipped and blurred circles in the result fork, while in the renderer we directly compute the gradient from its parameters)
Now that I think of it, we could use different element names for path effects, so that creating the SP nodes does not require looking at the type attribute: inkscape:boolean-union, inkscape:boolean-difference, inkscape:boolean-subtraction, inkscape:pattern-along-path, inkscape:render-gears, inkscape:bend-path, inkscape:offset, etc.
I can try to prototype this for dynamic offset after GSoC. I just noticed my node tool breaks it: using the node tool was the only way to bring up its knotholder, and my tool doesn't (yet) know how to edit things other than paths. The new offset would use the aforementioned switch structure, and the linked offset would be removed (it would be possible to create an offset of a clone which would work exactly like linked offset does now); at the same time the capability to edit the original shape would be preserved.
Regards, Krzysztof