2009/8/10 Krzysztof Kosiński <tweenk.pl@...400...>:
The only problem I have with this is that the "ground path" is not a real object.
What is "real"? Why d= is real but original-d= is not? I think it's pure terminology issue. The code is the same.
- svg:use has its cost. Inkscape clones have a lot of code for
behavior when the original is transformed or deleted.
That there is lots of code for this stems from weak href management in our code, for which I have a solution which I will post today or tommorow.
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 is purely behavior code and will get in the way if you use clones for some "helper" or "invisible" paths. Again, we were already bitten by this once with flowed text.
What you propose amounts to adding more such stuff, one new Inkscape element type per LPE, which will be hardly maintainable.
Why? Most of the code (I'd say at least 80% of the hard stuff) could be shared between all LPEs, because we can use a common base for their SP tree objects that would provide most of the functionality needed by LPEs. Having one SPObject per LPE is a must anyway.
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 is bad. 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.
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. 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.
Just as we do when a path has a clippath and a mask. If we can do this for clips/masks, why not do the same for LPE parameters?
There is a difference: the LPE ground path is not an object,
Why do you need an object so badly? What you wrote is called Path Manipulator, not Object Manipulator :) And "path" is just a sequence of path commands, which can well be stored in an attribute of any element.
I don't understand your point about selecting knotholders - they are not selectable and don't need to be selected.
No, it's not about selecting knotholders, it's about reusing the existing Inkscape::Selection as a list of objects for which to display manipulators. If some path parameters are not objects, then it's harder to use the selection to determine what should be edited and what shouldn't.
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.
What I had in mind is to have an object tree in place of the current LPE stack, and the user would select the invisible shape parameters to edit by selecting them using that dialog. If the entire LPE was selected, then based on the preferences only the LPE's controls would be shown, or manipulators for everything would be shown; while when selecting some internal objects in the LPE, only the selected objects would have their manipulators shown. It's very similar to how selecting in groups work. Even when some objects are grouped, you can select inside the group. I want to reuse this fact for LPEs.
So what's the problem with our current LPEs which are applicable to groups? And you can select inside those groups, of course. Not "like in groups" with some switches and Inkscape non-g elements treated "as" groups, like in your variant, but simply and literally inside groups with LPEs on them. For example by Ctrl+click. Isn't it even simpler?
At least, it is for things like boolean ops or envelopes. For LPEs where one path is a e.g. pattern upon another, it's not a group in our system. But it won't be in yours either! 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?