2009/8/2 Krzysztof Kosiński <tweenk.pl@...400...>:
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.
Not really. The node tool will still have to know from which branch to take shapes (e.g. when you click or press Ctrl+A) and which branch to ignore. I just don't see how this is better than knowing which attribute to take and which to ignore.
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.
It's not really that simple. Consider LPEs which refer to other paths, for example Pattern along path. These paths can be anywhere, on canvas or in defs. I want Node tool to be able to edit both the skeleton path and the pattern path. This means it will have to know how to traverse from a path with such path parameter to that path parameter, read it, and display it. And it should use at least a different color for the parameter path, so it must be aware that it is a different kind of path. Which means, you will end up with basically what we have now. I don't see where you can shave off much complexity here. Node tool will in any case be central to Inkscape, and it will have to be aware of a lot of things around it.
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>
This looks nifty, but I just don't see how this is principally different from LPE on a group that we can do now. Is it only that the implementation can be simpler with your structure?
I can tell you one thing: the implementation of the current LPE seemed really simple when we were just planning it :) Most of the complexity grew upon it later - when we ran into various scenarios and thought about new possibilities. That is perfectly normal, and I don't think our LPE implementation is particularly bad as it is. But I'm pretty sure that no matter how sleek your implementation seems now in theory, in practice it will be much much hairier :)
BTW, the clones here will not be editable by Node tool anyway, as they aren't now. As I wrote in another email, we could create a simple "copy" LPE for this. Your syntax would allow that too, of course, but it would mean nested switches which adds considerable complexity: the non-Inkscape branch of such a nested switch will still be inside an Inkscape branch of the parent switch! It will be cumbersome to decide what to render and what to edit with such a structure. With our current implementation, it's all in a single path element and therefore much simpler and more straightforward.
- 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.
I wouldn't say that we have such a plenty of LPE code in our current node tool, and what we have there your tool will need just as well - such as editing parameter paths with a different outline color. One thing that will become simpler is that we will get rid of the "next LPE parameter" button because we will be able to edit all parameters and the path itself at the same time, but this simplification does not depend on which XML structure we use for LPEs.
- 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.
Yes, but again, it is desirable that pattern paths use a different outline color and maybe some other presentation or behavior differences (for example it would be nice to edit the pattern not where it is but moved towards the skeleton that uses it), so the node tool will have to learn all this stuff anyway.
Also, your XML example shows only boolean effects where source paths play more or less the same role. What about pattern along path, where one path is skeleton and the other is pattern? How do you identify in your structure which is which?
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.
We should be smart about it and save it as rect when it is representable as rect, and as path otherwise (e.g. when it has LPEs, markers, text on path, etc).
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.
No problem - we can add a "combine" LPE with current implementation.
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.
Booleans are applied to groups, and are updated live when any path inside that group changes, so no problems here.
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.
Why "every tool"? All we need to do is: teach the Node tool to edit parameter paths (done), teach the knotholder to edit knots of an LPE (done), and make sure all these knotholders and multiple paths are editable simultaneously (is being worked on). No other changes are needed in any tools - all shape tools just use the knotholder and that's it.
Whereas with your implementation, I foresee changes at least in Selector - it will need to be taught how to select stuff inside switches and what to ignore there. All export and rendering code will all have to be updated as well, otherwise it will just export both source paths and the result path on top of one another. That's quite some rewriting to do, for no clear gain that I can see.