Hey,
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 took all the examples from Mauve's excellent example file[1] and turned them into effects on the effects menu. Now you should be able to just grab and object and apply these to your objects.
To create your own I suggest copying "sepia.h" in /src/extensions/internal/filter and replacing the strings. All you need is a non-translated name (ID), Menu name, description and then the filter that you want to apply. You'll then need to add it to "filter-all.cpp" but that is also pretty straight-forward. If someone isn't faster, I'll make better docs. [2]
It is a little more difficult to use parameters, but not that hard. There is one example of that, drop shadow, which of course works with live-effects also. I would also like to clean this up and make it easier.
The biggest limitation of the implementation right now is that it will ONLY apply if there isn't a filter on the object currently. Long term, I'd like it to merge the filters.
That's all for now!
--Ted
[1] I didn't take Drop Shadow from there because I was looking at the SVG file and the filter for Drop Shadow is above the linear gradient where I started looking, so I missed it. No seriously, stop laughing.
[2] I would like for someone with a light programming background to do this as they're likely not to skip over things that other people would need to get started.
Darn you people! Just when I think I can go back to enjoying a nice stable release for a while you guys force me back to the snapshots!
Nice work
--bb
On Wed, Apr 23, 2008 at 7:31 AM, Ted Gould <ted@...11...> wrote:
Hey,
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 took all the examples from Mauve's excellent example file[1] and turned them into effects on the effects menu. Now you should be able to just grab and object and apply these to your objects.
To create your own I suggest copying "sepia.h" in /src/extensions/internal/filter and replacing the strings. All you need is a non-translated name (ID), Menu name, description and then the filter that you want to apply. You'll then need to add it to "filter-all.cpp" but that is also pretty straight-forward. If someone isn't faster, I'll make better docs. [2]
It is a little more difficult to use parameters, but not that hard. There is one example of that, drop shadow, which of course works with live-effects also. I would also like to clean this up and make it easier.
The biggest limitation of the implementation right now is that it will ONLY apply if there isn't a filter on the object currently. Long term, I'd like it to merge the filters.
That's all for now!
--Ted[1] I didn't take Drop Shadow from there because I was looking at the SVG file and the filter for Drop Shadow is above the linear gradient where I started looking, so I missed it. No seriously, stop laughing.
[2] I would like for someone with a light programming background to do this as they're likely not to skip over things that other people would need to get started.
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Apr 22, 2008 at 6:31 PM, Ted Gould <ted@...11...> wrote:
To create your own I suggest copying "sepia.h" in /src/extensions/internal/filter and replacing the strings.
Thanks, but this is not what I proposed. Having each filter hard-coded in the source is a bad idea! Can you just make one generic filter-inserter class which takes the filter source from share/filters/filters.svg, where any user could add his/her own filters without recompiling? Your way bloats the source and makes the entire system very limited. Do you want an avalanche of patches submitted with "hey, add my filter too!"? :)
On Wed, Apr 23, 2008 at 9:14 AM, bulia byak <buliabyak@...400...> wrote:
On Tue, Apr 22, 2008 at 6:31 PM, Ted Gould <ted@...11...> wrote:
To create your own I suggest copying "sepia.h" in /src/extensions/internal/filter and replacing the strings.
Thanks, but this is not what I proposed. Having each filter hard-coded in the source is a bad idea! Can you just make one generic filter-inserter class which takes the filter source from share/filters/filters.svg, where any user could add his/her own filters without recompiling? Your way bloats the source and makes the entire system very limited. Do you want an avalanche of patches submitted with "hey, add my filter too!"? :)
Even nicer would be if it would load filters from share/filters/*.svg . Then users could share filter sets with each other by just dropping in an extra file. Plus then their additions wouldn't be lost after upgrading to a new version of inkscape.
This goes for other things there in inkscape/share, too, like the patterns and markers.
--bb
is there a way to provide info on which attributes could be editable in a high level filter effects UI?
I mean... not all parameters of the filter primitives used to construct a filter are easy to understand in the mood of a high level abstraction of the effect.
For instance, drop shadow should have only 2 "high level" parameters: "x-y offset" and "shadow intensity"
(Maybe this info could be stored inside the share/filters/*.svg files on a special inkscape namespace)
On Tue, Apr 22, 2008 at 9:22 PM, Bill Baxter <wbaxter@...400...> wrote:
On Wed, Apr 23, 2008 at 9:14 AM, bulia byak <buliabyak@...400...> wrote:
On Tue, Apr 22, 2008 at 6:31 PM, Ted Gould <ted@...11...> wrote:
To create your own I suggest copying "sepia.h" in /src/extensions/internal/filter and replacing the strings.
Thanks, but this is not what I proposed. Having each filter hard-coded in the source is a bad idea! Can you just make one generic filter-inserter class which takes the filter source from share/filters/filters.svg, where any user could add his/her own filters without recompiling? Your way bloats the source and makes the entire system very limited. Do you want an avalanche of patches submitted with "hey, add my filter too!"? :)
Even nicer would be if it would load filters from share/filters/*.svg . Then users could share filter sets with each other by just dropping in an extra file. Plus then their additions wouldn't be lost after upgrading to a new version of inkscape.
This goes for other things there in inkscape/share, too, like the patterns and markers.
--bb
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2008-04-22 at 22:12 -0300, Felipe Sanches wrote:
is there a way to provide info on which attributes could be editable in a high level filter effects UI?
I mean... not all parameters of the filter primitives used to construct a filter are easy to understand in the mood of a high level abstraction of the effect.
For instance, drop shadow should have only 2 "high level" parameters: "x-y offset" and "shadow intensity"
(Maybe this info could be stored inside the share/filters/*.svg files on a special inkscape namespace)
I think it would be a little crazy to do this. The only thing I could think of (and we can do now that we have proper namespaces) is embed an INX file in there. Could be interesting, but basically uneditable with anything but a text editor.
--Ted
why not a simple (pseudo?)xml with it's own extension maybe *.ftx no need to do a whole svg file when the xml filter could possible for other application to use them as most if not all the filters are pretty standard maybe CREATE guys have a better idea.
<inkscape-filter> <name=fuzz> <effect=turbulence> <type=FractalNoise> </effect=turbulence> </name=fuzz> </inkscape-filter>
Joshua L. Blocher verbalshadow
On Tue, Apr 22, 2008 at 8:34 PM, Ted Gould <ted@...11...> wrote:
On Tue, 2008-04-22 at 22:12 -0300, Felipe Sanches wrote:
is there a way to provide info on which attributes could be editable in a high level filter effects UI?
I mean... not all parameters of the filter primitives used to construct a filter are easy to understand in the mood of a high level abstraction of the effect.
For instance, drop shadow should have only 2 "high level" parameters: "x-y offset" and "shadow intensity"
(Maybe this info could be stored inside the share/filters/*.svg files on a special inkscape namespace)
I think it would be a little crazy to do this. The only thing I could think of (and we can do now that we have proper namespaces) is embed an INX file in there. Could be interesting, but basically uneditable with anything but a text editor.
--Ted
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Bill Baxter wrote:
On Wed, Apr 23, 2008 at 9:14 AM, bulia byak <buliabyak@...400...> wrote:
On Tue, Apr 22, 2008 at 6:31 PM, Ted Gould <ted@...11...> wrote:
To create your own I suggest copying "sepia.h" in /src/extensions/internal/filter and replacing the strings.
Thanks, but this is not what I proposed. Having each filter hard-coded in the source is a bad idea! Can you just make one generic filter-inserter class which takes the filter source from share/filters/filters.svg, where any user could add his/her own filters without recompiling? Your way bloats the source and makes the entire system very limited. Do you want an avalanche of patches submitted with "hey, add my filter too!"? :)
Even nicer would be if it would load filters from share/filters/*.svg . Then users could share filter sets with each other by just dropping in an extra file. Plus then their additions wouldn't be lost after upgrading to a new version of inkscape.
This goes for other things there in inkscape/share, too, like the patterns and markers.
+1
And I would care less about if at adds them all or if you selected the "active" filters file (like swatches). I could see benefits to both methods however.
-Josh
On Tue, 2008-04-22 at 20:14 -0400, bulia byak wrote:
On Tue, Apr 22, 2008 at 6:31 PM, Ted Gould <ted@...11...> wrote:
To create your own I suggest copying "sepia.h" in /src/extensions/internal/filter and replacing the strings.
Thanks, but this is not what I proposed. Having each filter hard-coded in the source is a bad idea! Can you just make one generic filter-inserter class which takes the filter source from share/filters/filters.svg, where any user could add his/her own filters without recompiling? Your way bloats the source and makes the entire system very limited. Do you want an avalanche of patches submitted with "hey, add my filter too!"? :)
Yes, I know. I looked at doing that, but the problem I saw is that there is no way to translate the names.
I think that this might work for ~/.inkscape/filters/*.svg but I don't think it should be for the ones we ship by default. I think we can assume that if a user added the filter, it's in a language that he understands :)
The other problem is of course doing ones that require GUIs, stuff like the drop shadow example.
--Ted
On Tue, Apr 22, 2008 at 07:33:11PM -0700, Ted Gould wrote:
Yes, I know. I looked at doing that, but the problem I saw is that there is no way to translate the names.
XML provides i18n through the use of xml:lang. We could just move the inkscape:label attribute to an inkscape:label element with an xml:lang attribute specified.
Then all translators need to do is open the SVG file in a different locale, rename the filters using the UI, and save it again. Each locale would only save a label xml:lang="$LANG" but when reading labels would fall back to the first label if there wasn't a label for the current locale.
Based on what's been suggested my understanding is that we want to get away from any distinction between an filter library SVG and a drawing SVG.
Parameterisation is a much thornier problem. I don't think it's simply a case of asking what values to insert at which point in a filter; it's more about compiling a filter using configuration options a user specifies. That can already be done with extensions.
Dan
On Wed, 2008-04-23 at 10:52 +0100, Daniel Pope wrote:
XML provides i18n through the use of xml:lang. We could just move the inkscape:label attribute to an inkscape:label element with an xml:lang attribute specified.
Yes. The problem is connecting it into our translation infrastructure and builds. The tools don't really support it.
Then all translators need to do is open the SVG file in a different locale, rename the filters using the UI, and save it again. Each locale would only save a label xml:lang="$LANG" but when reading labels would fall back to the first label if there wasn't a label for the current locale.
This isn't really reasonable. We need the translatable strings to make it into the po files. There are a ton of tools based on this, and we don't want to loose the support of those tools.
Parameterisation is a much thornier problem. I don't think it's simply a case of asking what values to insert at which point in a filter; it's more about compiling a filter using configuration options a user specifies. That can already be done with extensions.
Correct. But since extensions aren't built into the filters, the issue becomes integrating them. I think static filters are marginally interesting, the really interesting stuff comes when you can adjust them live (Drop Shadow).
--Ted
On Wed, Apr 23, 2008 at 12:51 PM, Ted Gould <ted@...11...> wrote:
Yes. The problem is connecting it into our translation infrastructure and builds. The tools don't really support it.
If the choice is between lack of translatability and a wrong non-extensible architecture, I think the winner is clear. Of course translation issues will be sorted out with time once the system is in place.
On Thu, 2008-04-24 at 12:10 -0300, bulia byak wrote:
On Wed, Apr 23, 2008 at 12:51 PM, Ted Gould <ted@...11...> wrote:
Yes. The problem is connecting it into our translation infrastructure and builds. The tools don't really support it.
If the choice is between lack of translatability and a wrong non-extensible architecture, I think the winner is clear. Of course translation issues will be sorted out with time once the system is in place.
I would argue that what you're suggesting is both hard to translate and a bad architecture. :)
But, I'd love to be wrong. I've enabled the build so that if you have any SVG file in /usr/share/inkscape/filters or ~/.inkscape/filters all of those filters will be added to the effects menu. In their static glory. I propose that we remove the system one if no one comes up with a translation scheme by the next release.
https://bugs.launchpad.net/inkscape/+bug/222326
Also included in the check in is support for stacking filters. So with a few short clicks you can remind your CPU who's in charge! This good for taking your leopard skin text that is on fire and getting an accurate drop shadow :)
--Ted
On Sat, Apr 26, 2008 at 1:56 AM, Ted Gould <ted@...11...> wrote:
I've enabled the build so that if you have
any SVG file in /usr/share/inkscape/filters or ~/.inkscape/filters all of those filters will be added to the effects menu.
Thanks!
glory. I propose that we remove the system one if no one comes up with a translation scheme by the next release.
In that case, let's also remove stock markers and stock patterns. They use the same approach and, as far as I know, are untranslatable.
I'm sure users will appreciate that :)
On Sat, 2008-04-26 at 11:52 -0300, bulia byak wrote:
In that case, let's also remove stock markers and stock patterns. They use the same approach and, as far as I know, are untranslatable.
I'm sure users will appreciate that :)
Well, those are displayed graphically to the user while the filters are described entirely with text. So, in that regard, the other possibility is to have the filters shown to the user graphically. This challenge is getting more interesting as we go along :)
--Ted
On Sat, Apr 26, 2008 at 5:06 PM, Ted Gould <ted@...11...> wrote:
Well, those are displayed graphically to the user while the filters are described entirely with text.
Actually, markers have both icons and text, while stock patterns currently have only text.
Adding graphic representations would be nice, but only if they can be rendered in the background and cached, as are the marker icons.
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.
Regards,
-- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
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
Without getting into all the technicalities of this, I love the idea of being able to add filters and extensions as plugins. At least from a non-hacker perspective, plugins seem to have been great for Gimp, Firefox, Thunderbird, Open Office...
participants (10)
-
Bill Baxter -
bulia byak -
Daniel Pope -
Felipe Sanches -
Jon A. Cruz -
Josh Andler -
Joshua Blocher -
Marcin Floryan -
rygle -
Ted Gould