bulia byak wrote:
But it will still need to know to go into your switch's correct branch to find them. Just as now, it just knows to read the inkscape:original-d attribute instead of d, but otherwise it is "completely unaware of path effects."
If it knows to read a different attribute, then it obviously is aware of path effects. Using the switch structure would entirely remove the need to care about path effects, so that things work automatically. By using this new XML structure we reduce a great deal of complexity. The node editor is no longer "something that can edit some element that has some attribute that has SVG path data". It becomes "something that can edit an svg:path", and nothing more.
Here is an example how it could look like in the document: svg:switch <inkscape:path-effect type="boolean-union"> <svg:path ... /> <inkscape:path-effect type="boolean-difference"> <svg:use ... /> <svg:use ... /> </inkscape:path-effect> </inkscape:path-effect> <svg:path ...result... /> </svg:switch>
- it only works in shape tools, not in Node - hopefully your node tool
rewrite will take care of that
I can say with confidence that the new structure would allow my node tool to work with path parameters without introducing even 1 line of code related to LPEs. That's one of the reasons I suggested it. The node tool is very complex and it is important to keep it as simple as possible, so that bugs can be found and people other that me can understand it.
- if you assign an effect which has its own knotholder, such as
Hatches, you will lose ellipse handles because we can only have one knotholder at a time.
The proposed XML representation would allow one to actually select the parameter objects without the tools knowing they are path effect parameters - this problem would go away instantly. It would make path effects a different type of object, so they can have their own event contexts to edit them with control points and the like, without overloading elements that were not designed to edit them. We could edit the ellipse or the offset without ANY hacks either in the offset editor or in the ellipse tool - it would just be the normal behavior of switching the tool in response to selecting an object.
- rect does not use path element at all and so cannot have any path
effects - this needs to be fixed in SPRect, has been planned for a long time.
I do not agree with the plan to turn svg:rect into an svg:path. Using svg:path to represent a rectangle removes even more semantic information from the document and makes life harder for whoever uses our markup. Instead of trying to make everything an svg:path (the whole point of SPShape is to avoid this!) we should allow effects to accept more types of shapes as parameters. Preserving semantic information is the whole point of this new XML structure, and in fact it is in large part motivated by the svg:rect and svg:ellipse problems. It would allow *arbitrary* SVG elements to be used as input for path effects, because the SPObject layer would automatically create the shape information for all parameters of the path effect whatever they are.
This is possible now, if only we had these effects available. One of them is there but disabled - it's Union.
Flatten Group is not Union. Union performs a boolean 'or' of all shapes whereas flatten is more or less equivalent to the 'combine' operation. On top of that, I'm not sure whether the boolean operations are able to also take the second parameter "by reference" so that the result is updated whenever any of the arguments changes. The new XML is perfectly capable of that because it can use a clone.
Well, I think our path effects are already a "vector equivalent to filtering" and "super-powerful" :) They just need to be cleaned up, UI limitations fixed (which you are working on right now!) and then it will be dream come true :)
I agree they are already useful despite their limitations, though maybe not 'super-powerful'. I just think that the simplest way to achieve this 'cleanup and fixing' without introducing LPE-related functions to every tool is to change the XML representation. If we don't do it, we'll end up either with a ton of unnecessary junk in every tool, or adding a third layer between the XML and SPObject. If we change the XML, we can leverage a lot of existing code to get an impressive feature set, and even simplify it a lot. In other words, I think it's the quickest way to achieve the desired functionality. I cannot find a way in which the existing implementation is superior to the proposed one, except the fact that the existing one is partially done (though with several bugs, limitations, and far reaching interdependencies) and the new one is not.
Regards, Krzysztof