2009/8/3 Krzysztof Kosiński <tweenk.pl@...400...>:
About bool ops, the actual structure is to have one "ground object" and get the other operands as parameters. I think this is ok.
This introduces additional complexity when you want to edit one of the objects: the path manipulator or the shape manipulator must know that it will be editing a parameter of a path effect, not an actual shape (because the XML representation is different). In the proposed representation, the manipulators can just edit actual XML / SPObject elements that are identical to the elements they edit "normally", and you can select those elements without any hacks - they have an XML representation and a node in the XML tree so they interoperate with Inkscape::Selection without any changes.
The greatest problem being, they should not be entirely "normally" edited. They need to be presented as something different than the main path, otherwise it will be very confusing for the user ("what are these ghost paths? can I just delete them?")
However, this violates the path to path mapping paradigm, and hence goes beyond lpe purpose. In particular, this requires a completely new API.
That's the thing - the paradigm itself is limited! Thinking of an LPE as a path->path mapping is inherently limited, and can only accomodate effects taking multiple paths as input using hacks.
Why LPE on a group is a hack? It is simple and valid SVG, and it works.
Again: the path-to-path limitation is indeed a limitation, but that's by design. These are PATH effects, and the entire API is oriented this way. For different things, invent different concepts.
When we think of an LPE as a shape dynamically computed from other shapes, the new representation is very natural. (Note that I do not use the word 'path' - this also includes ellipses, rectangles, etc.)
If all you do with your proposal is extend source objects from paths to paths plus shapes, then you don't need to bother - as I said, we already support LPE on shapes (those that use svg:path, at least, which means all except rect for now).
With enough hacks one could probably achieve all the things I'm talking about even with the old representation.
I think this is true for both representations :)
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.
In my node tool I edit a single path with a PathManipulator. The manipulators do not need to traverse anything - they are dumb objects that take an SPShape and display the controls to edit it. It is the event context (tool) that takes care of figuring out which items need to be edited and creating manipulators for them. The LPE dialog would be responsible for creating the manipulators for parameters.
No no no. Node tool must NOT depend on any dialog for any of its functionality. This breaks encapsulation in a bad way. The dialog may be on or off, this should not affect the tool. The tool must know itself what to do for LPE parameter paths.
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.
The color of the path will be a property of the manipulator, not something the manipulator figures out on its own. The tool would be responsible for setting it. The LPE dialog would set the correct color when displaying a manipulator for its parameter, because it knows they are parameters.
Right now I can edit parameter paths without going to any dialog, and this functionality must be preserved.
Which means, you will end up with basically what we have now. I don't see where you can shave off much complexity here.
That's because you think of the node tool as a single entity, while I think of it as a wrapper for path manipulators.
No I don't. I'm not against the idea of "wrapper for path manipulators" of course - my own ShapeEditor idea was exactly that. But, regardless of which level it is, Node tool (not some dialog!) must know how to deal with LPEs, as I explained above.
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?
Yes, it can be MUCH simpler, because the manipulators can be created for the internal XML elements.
Just like the current nodepath can also be fed a path in defs, and edit it just fine :)
In my initial proposal there are no nested switches. Look at the example again: there is only one switch that surrounds the topmost LPE only. However, using nested switches is actually be a better idea, because it allows us to degrade gracefully when we don't understand one of the nested path effects, and would make the XML representation of the LPEs look the same regardless of whether they are topmost or not.
OK, can you please write out a detailed XML for your representation of this:
- Two paths, A and B, with different style (one red, the other green).
- A has Bend applied, linked to some path C on canvas as its bend path.
- B has Pattern along path applied, linked to some path D as its pattern path.
- A and B are grouped and the group has Envelope applied, linked to the same C as its bottom envelope path. Note that in the result, A and B still have different style.
I can do this with current implementation, and I can edit all aspects of it. Please show me how it will look in your representation and in what ways it will be easier to implement or edit.
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?
The same way z-order is determined, by their order in the document :) If that turns out to cause problems, I'll add an inkscape:parameter-name attribute to that says which parameter it is, but right now I don't see a case where it would be necessary.
It's wrong to consider only implementation forgetting about the readability of the XML source. If you have two sibling paths and they play very different roles, it must be clear from the XML code what is what.
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).
That last part is actually the most complex one. The first two are trivial by comparison. I can say this from experience :) Even if we have to scrap the first two parts to make the last one simpler, it will be worth it; actually the first two parts are not even necessary with the new XML representation.
So, are you saying that the old representation makes it more difficult for you to achieve the multiple-paths-and-knotholders-at-the-same-time goal? In what way? Please describe some specific problems and maybe we can figure it out together.
And why we need to edit them all at once? The new representation allows you to select and edit one parameter at a time or several of them at once.
I don't see how old representation would not allow you to do the same.
The rendering code does not touch the XML layer, it uses the SPObject layer, so it won't need any changes. Some export plugins might need to be fixed to handle switches correctly, but we would need to do this anyway for the flowtext work. For me the gain is enormous. The new representation is generic - if we use some object as a path effect parameter, it does not change at all, and is in every respect still a normal object!
How is this different? Link to a path making it a pattern for some other path, and it does not change at all, is still a normal object, and editing it updates the result path of the LPE.
With the old representation we have know that we are operating on an LPE almost everywhere.
No, only in places that edit it - which are: nodepath, knotholder, and the LPE dialog. That's all.
I don't say it is incapable of providing all the features we want - probably it could provide them, but only after we made a huge mess with a lot of obscure bugs and quirks and alienated everyone out of working with tool code, because every non-trivial change would break LPEs in some subtle way.
I don't see this at all.
I have discussed and participated in LPE development from the start. We had many difficulties along the way - transforms, stacking, groups, linking and sharing linked paths, and many others. Most of them would be the same with your representation. But I don't remember that we ever had much trouble with enabling Node tool to edit all this stuff. I think this was done quite quickly. Of course it was clumsy because of the one-path-at-a-time and one-knotholder-at-a-time limitation, but that's just the fundamental limitation of the tool, which you are solving now, and has nothing to do with LPEs.
I know it will be very easy to plug in LPE editing into your new node tool. But believe me, it wasn't much harder with the old tool. Just like you (probably) do, we also had an upper layer which chose which attribute to read and what color to use for it, and the lower-level guts which were totally agnostic about what kind of path they are dealing with. Of course it wasn't as cleanly separated as in your new code, but it was separated, and worked fine. If you're trying to simplify something in this area, I think it's not a very fertile one for simplification :)
One point where I totally agree with you is that we do need better support for switches. Whether we use them for LPE or not, we will certainly use them at least for flowtext and probably eventually for some other custom stuff (such as TeX objects), so we must deal with it cleanly, and if you rework this along the lines you described, this will be extremely helpful.