
On Thu, 2006-04-27 at 16:00 -0400, bulia byak wrote:
It won't break anything which worked before. To be extra sure, we can prefix all the built-in functions with inkscape:, or even make them full URNs, guaranteed unique.
An aside: at this point I'd go with a x-inkscape-extension: URI scheme for identifying extensions of any sort. I used to favor URNs, but then I realized that the way URNs are specified basically assumes a central registry to maintain uniqueness. Don't think we want to deal with that.
Personally, I'm almost sure that the defs thing will never be needed. But I don't want to bet on that. Instead I propose a start-simple approach which will be easy to extend if really necessary.
I'm not really interested in implementing fully chainable effects or anything to start with. I understand that simple and incremental is the only reasonable way to do things, since you can't expect a complicated feature to spring from the head of Zeus fully-formed. However, I do want to make sure that whatever we release with in the beginning is going to be something like a subset of the "full" approach.
Most importantly, though, as Ted pointed out, extension arguments have names, so we've got a list of nodes (path effect instances) _*which have named parameters*_.
There's not much distance at all between e.g.:
inkscape:path-effects="someeffect(amount: 3, whatever: 4) othereffect(q: 3, argle: 29)"
and the obviously silly:
inkscape:path-effects="<someeffect amount='3' whatever='4'/> <othereffect q='3' argle='29'/>"
I simply don't want to see us using parsed strings for attributed lists in an XML document. Even CSS only deals in lists of named attributes, not lists of things having named attributes.
That has a lot less to do with complexity of the SVG standard and
more with the severe crappiness of our own codebase, which makes the things that should be easy hard.
Yes, but this does not change my argument. We still have the same crappy codebase. But I want path effects NOW, I will not agree to wait 2 years as I did with SVG filters.
I'd really like to see SVG filters NOW, too. As bad as the SPObject code is, it's not so bad that the SPObject part of filters couldn't be done reasonably quickly. But there's not much motivation so long as the canvas/arena code isn't capable of rendering even gaussian blur. I suspect the reverse may be true as well, which is why we've not seen any progress. However, Aaron's already writing the path effect code, so we shouldn't encounter the same impasse for path effects.
I actually wouldn't object to an inkscape:gaussian-blur attribute if it helped us get filters bootstrapped, _provided we never released with it_.
By extension, I also wouldn't object to such a basic approach for path effects either, _provided we never released with it_. But I'm worried we'd find that more tempting because there'd be nobody to beat us over the head with the SVG standard in that case.
Once we release with something, we're stuck with it unless the standard says otherwise. And I'd rather not have to maintain two parallel systems for path effects when we inevitably (looking at the history of all similar things in SVG) needed more flexibility.
With a saner architecture, the SVG filters specification would
actually be something like the path of least resistance.
I'm not so sure of that. Maybe I'm spoiled by our crappy codebase, but at this time I really abhor the "something which refers something else out there" design. In my view it's fundamentally broken, and our ugly "vacuum defs" command is a monument to that brokenness. Again, I'm exaggerating for the sake of the argument, but you get the idea :)
Actually "vacuum defs" is a monument to us not having a real UI for managing resources in <defs>.
But yes, there are two big issues with referencing external resources:
1. handling the appearance/disapparance of the resource (e.g. even if it simply occurs later in the document and hasn't been encountered yet)
2. lifetime -- how and when should we dispose of unused resources?
However, for those resources which are a) document-local, and b) aren't first-class objects from the user's point of view, these are solved problems [via Inkscape::URIReference and inkscape:collect, respectively]. Object-local gradients are one example, and I think per-path effect lists would qualify too.
For a per-object effect list, it might be overkill, but then we've already ruled out the simplest XML solution (child elements).
True. Though was almost all SPObject and RDF code bugs, not XML tree.
Right. But again, this does not invalidate my argument. We still have to deal with the same SPObject and the rest of the code. You won't believe how many crashes I fixed caused simply by the the fact that Adobe SVG files have lots of empty lines and these lines end up as empty text nodes in our tree.
To be honest, I felt the need to clarify that because I feel a bit proprietary about the XML tree code. :) SPObject crashes if you look at it wrong, but I like to imagine that the XML tree, while not perfect, is really pretty decent.
-mental