Hi,
Your proposition sounds good to me, at least worth thinking about it twice!!
I'm not familiar enough with internal inkscape code (node tool, shape tools, helper path display, etc...) to be definitely sure it simplifies everything so well, but I agree it looks so.
The main issue I can think of is that we already released lpes with the actual xml representation, and maintaining compatibility might be painfull. But this can be understood in the other direction: should we change something to the xml structure then the earlier the better. And in all cases, think about it twice!!
Let me start with the main reason I think some move in that direction should be taken:
The path to path mapping paradigm absolutely needs one exception: lpe
need to be allowed for clones (clones can be used as
parameters, but we need to allow them as ground object). This is absolutely required, event for most path to path mapping observing lpes: suppose you
want to draw several outlines of the same shape, or to skectch the same
path with several stroke styles, widths, or sketch it and fill with hatches, etc... there are tons of
situations where different lpes have to be applied "in parallel", i.e.
to clones of the same path to get the desired effect.
Atm, you can only use copies, which means editing the ground
path is forbidden (making "live effects" not so "live" anymore). Our xml
representation does not allow clones, and this is a strong limitation.
Of course we can work around it using more fancy "inkscape:blah" parameters to
remember the object was a clone and store it's original href, but I'm
pretty sure this will mess up the code and introduce terribly
complicated tests everywhere. We definitely need a representation that
allows more general paths as input: anything that can be converted to a
path should be allowed. I think your proposition is good for that.
[
Now some remarks about less convincing points:
About parameters: we can already use complex objects (in particular, objects carrying lpes on theire own) as parameters using "cloned" parameters. The only limitation is that the source object has to exist somewhere in your drawing and, you generally have to hide it by hand in a separate layer or something... I think this is not a big problem. Recieving a group as parameter should not be a big deal, but since we can only output a single path, this is not very usefull, is it?
About bool ops, the actual structure is to have one "ground object" and get the other operands as parameters. I think this is ok. Your proposition makes the things more symetrical, replacing the ground object by a (sorted) list of operands. This is closer to the user workflow, who may want to select a collection of objects, and click somewhere to get the union or instersection of all at once. I doubt this is a big trouble however; since we can still make an arbitrary choice of the ground object and add as many bool ops as needed. (I didn't get your proposition about making a shape 'live').
one new feature your xml representation allows is to have a separate new object as output: this allows in particular the style to be edited (set opacity according to area, or whatever), and more generally lpes to output groups: this is required to get the interpolate extension for instance, where not only the shape is interpolated but also the style. There are tons of situations where this is desired. However, this violates the path to path mapping paradigm, and hence goes beyond lpe purpose. In particular, this requires a completely new API.
This means we need a more general "vector effect" object, which after all is nothing more than an lpe allowed to output groups... We all know we'll need this sooner or later. Once we have it, we'll can think about letting lpes be particular cases of vector effects.
]
Finally, if this new lpe generation should look like filters, it might be worth organizing the inputs as "slots", like filters do: one lpe in the stack could use the result of another as a parameter(?). Hm. This is maybe too complex for only a few use cases...
Anyway, I support your proposition; I've be looking for something like that for a long time, but didn't know the switch element, and did never end up with a clean solution. Thank's!
Cheers, jfb.