On Wed, 2008-04-23 at 10:27 +0200, Marcin Floryan wrote:
On Tue, Apr 22, 2008 at 03:31:04PM -0700, Ted Gould wrote:
So I subclassed the effects to provide an easier way to just add filters on a group of objects. Hopefully bringing this into the realm where anyone who understands the filter dialog could build their own filter effect. It needs to documentation and overall is less than complete, but I thought I'd put it out there for people to play with.
I have seen the new code for filters in extensions. Cool work! I was just wondering though - would it not make sense to move the XML from the .h files to separate .INX files?
Current solution requires some programming skills (albeit very basic) while the .INX would only require new files. Obviously this would require a small change to the schema, but this should not be difficult (and could even validate the XML for SVG filters I suppose). The downside would be that rather than having it all in code we would add quite a few new files.
I was thinking about this. I'm still on the fence about it. The problem I see is more of an architectural one. The place where you'd put the filter would be in the implementation section, which the filters really aren't. They're an easy to program effect.
I guess there could be an attribute on effect or something like that, but it all seems a little dirty architecturally.
It still doesn't solve the problem of how the parameters get embedded into the filter. Since they are likely to need math and be put in the middle of space separated attribute lists (values in a matrix) I'm not sure of a clean way to do that.
--Ted