While rewriting the node tool I necessarily had to look into path effects. Live path effects are currently seem to be represented by a single svg:path that has information on what the original path looked like in the inkscape:original-d atribute, the applied effects in another attribute, and additional. I think this is not very flexible, because it does not allow for example nondestructive boolean operations where both operands are other path effects. What do you think about this representation:
1. A live path effect is represented by an svg:switch element. An Inkscape-specific attribute can be added to it to simplify implementation, but it is not really necessary. 2. The first element in that svg:switch is an inkscape:path-effect element that contains all the information about objects it was generated from. Shape parameters are represented as inkscape:path-effect-param elements that can contain anything including svg:use, svg:rect, svg:path, another inkscape:path-effect etc. This could allow very nifty things like live boolean operations. It would also simplify the node editor, because it could just operate on the invisible children of inkscape:path-effect while being completely unaware of path effects. As bonus points, path effects created from rectangles, circles, spirals, etc. could preserve the editing capabilities of those shapes. 3. The second element would be an svg:path that contains the result of the path effect, style properties, etc. 4. When opening the file in Inkscape, it would only look at inkscape:path-effect and recompute the fallback svg:path whenever something changes. When opening in another SVG viewer, it would only display the svg:path. 5. To handle live boolean operations, there would be an additional parameter for shapes that says whether they are 'live'. If a shape is 'live', all boolean, offset, etc. operations would create path effects instead of paths, similar to how linked offset works now. In fact, the destructive versions could be implemented as a combination of creating a path effect and an object-to-path conversion. 6. Path parameters would accept any SPShape. There would be a separate type of parameter that accepts a group of shapes. To convince an effect to accept an object group as a parameter, a special effect called Flatten Group would be provided - it would convert a group into a path effect suitable for use as a parameter for another one, and could optionally use a clone rather than the original for flattening.
Now some use cases: 1. To create an outline of some collection of objects, we create clones of them, group them, apply Flatten Group and then Offset. Result: whenever any of those objects is moved or modified, the outline updates. 2. The sun and cloud example in http://wiki.inkscape.org/wiki/index.php/Lpe-blueprint would be dead simple: create the circle and the sun ray, use pattern along path; create a clone of the cloud, make it 'live', create an offset; then apply a live subtraction between the sun and the clone. Updating any of the original shapes will now change the appearance. (As a related note, compensation on moving should not be a global property, but a property of the clone! As demonstrated here, we want the invisible clone used for the path effect to move with the cloud, but we want other visible clones to stay where they are when the original is moved)
UI changes: The LPE stack would need to be changed into an LPE tree like the layer dialog. The path effect tool would allow the editing of various parameters using control points and the node editor; selecting an item in the tree would cause its editing controls and toolbar to appear. Live path effects would be created from a menu rather than from the tool, like dynamic offset.
Internal changes: SPLPEItem would be removed, and SPShape would be used as the type of object that can be used as a path parameter.
What do you think? I think when done this way, path effects (or maybe they should be called Vector Effects, because they're not really limited to paths?) provide a generic vector equivalent to filtering. This means they could become super-powerful, and in fact the main method of editing complex drawings. There would be some problems with legacy live path effects, but it can be dealt with at document load.
PS I just noticed this is somewhat similar to the vector effects proposal in SVG 1.2. It might be wise to plan ahead and make it easy to optionally store some path effects as an SVG 1.2 vector effect.
Regards, Krzysztof