bulia byak wrote:
What is "real"? Why d= is real but original-d= is not? I think it's pure terminology issue. The code is the same.
The svg:path that represents the LPE is both a representation of the result of the LPE, and the original path. By a "real object" I roughly mean an object that can be legitimately put in a href. The original-d attribute cannot, so it is not a "real object" in some sense.
No, our href management is adequate for clones. We have all necessary signals and callbacks. I was referring to the code that compensates transforms of clones so that they behave logically from the user viewpoint when the original is transformed.
This code might be useful rather than getting in the way. If create a 'linked' effect usng a clone of some object, I would expect the clone used as the parameter not to move according to the rules for clones. If the behavior is consistent between clones and 'linked' parameters of LPEs, it's a good thing. Moreover the svg:use parameters of LPEs would be created from clones, so it's natural to expect them to behave like clones. As an example, consider linked offset: its behavior is really weird to me, because it does not behave the same way a clone would.
As for href management: good href management would allow us to transform clones during dragging (right now they are only transformed when the original's transform finishes - not good) and do other interesting things.
Once again: our code has hundreds of tree traversals. They all work the same for groups and layers, but they often have to special-case flowtext because it is special and has special rules.
This shouldn't be more complicated than 'if (SP_IS_VECTOR_EFFECT(item)) continue;', or not adding the children of the effect to SPObject 'children' attribute and instead providing access to them using a different function - if it's more involved then it highlights a larger problem.
Once you add a non-SVG container element, you have to define a lot of semantics for it: how style is inherited to/from it, how transforms are handled below it, etc. etc. This is all worked out for svg:g and is used, often implicitly, in many many places. So this will be a mess. Now that I think some more about it, I think we should make this a hard rule: no non-SVG container elements for SVG elements. If you need a container, subclass svg:g as we did for layers.
A non-SVG element can act exactly like a group, if its SP node is derived from SPGroup. If svg:g can act as the 'generic case' of handling transforms, styles, etc. for container elements, then I don't understand why we cannot have SVG elements in non-SVG ones.
Are you trying to say that if I put a standard SVG element inside an Inkscape-specific element, then an SVG-conforming parser will try to render the inner SVG element?
It might. No guarantees here.
I believe there is actually a hard guarantee. The only instance where this might happen that I imagine is when an implementation tries to be actively non-conformant, and descends into unknown elements. Descending into an element is not ignoring it, and implementations are required to ignore unknown elements, therefore SVG implementations are required not to display SVG elements that might reside inside unknown elements. Ultimately, it would be most productive to conduct some tests with actual SVG implementations.
The 'move path to defs and make a href' approach is not affected by this issue.
The only guarantee is svg:switch, which you also have at the upper layer, but it looks wrong below it. Even if it works fine :) For example, by thus hiding SVG inside non-SVG, you are also hiding it from SVG validators.
SVG validation is a special case of XML validation. If the XML validator has DTDs for all namespaces in the document, then it should be able to validate even the elements inside non-SVG elements, provided that they have DTDs that specify that SVG elements can be present there.
The point of Inkscape::Selection is the signals it emits. Do you need those signals? I think not, in which case any GSList or other container would work just as fine.
I need the equivalent of selection_changed to know when to create or destroy manipulators :)
You won't be able to select the pattern by Ctrl+click because it is invisible by itself. The only way to select inside such a "group" would be by using some list or tree in the dialog. But so you can do with the current system, too. What's the advantage?
I assume that we're talking about the second idea (change original-d into a href to a path in defs). I would be able to use the selection_changed callback of Inkscape::Selection to create or destroy the manipulators for all path parameters, including the source path. Otherwise I'd have two options: a) use some kind of sub-object selection, so that the user can select whether he wants to edit the LPE itself, the source path, or both b) always show the source path manipulator when the LPE is selected With option b) it wouldn't be possible to only show the knots of the LPE, or only the source path; with complex LPEs or source paths this might be a problem.
Regards, Krzysztof