Josh Andler wrote the following on 4/21/2008 12:51 PM:

Aaron Spike wrote:

...

heathenx wrote:

...

A fellow Inkscape user sent me a link from the SVN repo regarding a filter effect svg example file. There are quite a few different effects inside of this file which I think many of us users would appreciate having. Is it possible to get this file posted on openclipart? I'm not sure who authored the svg file but WOW!, what a nice gift. This person should be lifted up on our shoulders and paraded down main street. :)

That person is mauve. (http://mauve.mauvespace.com/) He also did a nice tutorial.

http://blog.mauveweb.co.uk/2008/04/19/svg-filters-with-inkscape-046/

I had seen him on IRC a couple mornings ago when he posted his tutorial. I asked if he'd create a bunch of stock filters for us to provide, as bulia mentioned a desire a while back for "easy filters". So, it's definitely a phenomenal start. But we also need to figure out how to implement the UI for easy filters. Just via menu options with no params? An "easy" dialog which hides the advanced bits? Or filter specific dialogs like the effects? Any other ideas?

Unfortunately, the problem is that we now have figure out where some filter related issues lie. I tried opening up the file in Batik, but it sees it as invalid. Are we producing invalid svg, or is batik just really picky? Also, some filters render differently in Firefox 3 & Opera 9.5.

So at this point, we shouldn't get overly excited until A) we're producing files batik likes (or we file a bug report with them if the problem is on their end) and B) we figure out who really has the most accurate filter implementation and either match it, or inform them if ours is "better".

-Josh

Interesting questions? I don't think your questions are directed at someone like me, although, from my point of view, I envision filter effects being chosen from a menu pull-down which opens the effects settings for that particular effect only. From there the user can take the default settings or choose to tweak things. However, it doesn't seem practical to consistently tweak the same effect when you want to use it again on another project. Some type of "save effect" or "export/import" might be useful.

Understanding these filters might be important to some and not so important to others. I'm sure some would rather click a button for an instant effect rather than spend 20 minutes setting one up for the first time. Think about someone using Inkscape for the first time. I had a little bit of a Yikes! moment myself when I saw the effects dialog for the first time. Of course I would still be at the starting line if it weren't for the help of others.

heathenx

On Mon, Apr 21, 2008 at 1:51 PM, Josh Andler <scislac@...155...> wrote:

I had seen him on IRC a couple mornings ago when he posted his tutorial. I asked if he'd create a bunch of stock filters for us to provide, as bulia mentioned a desire a while back for "easy filters". So, it's definitely a phenomenal start. But we also need to figure out how to implement the UI for easy filters. Just via menu options with no params?

Yes. This is what I proposed long ago. Instant-action commands with no dialogs. So they can be collected in a submenu and assigned shortcuts. In cases where some parameter really needs to be variable, do one or both of the following:

- make filter presets smart so they take into account the size of the object they're applied to and adjust their parameters accordingly

- provide several commands for the same filter, e.g. "Weak Fancy Blur", "Meium Fancy Blur", "Strong Fancy Blur".

Ideally adding a new preset filter must not involve any change in the code, but just adding it to share/filters/filters.svg from where it will be picked automatically.

I don't think it would be too difficult to implement. Any takers?

So at this point, we shouldn't get overly excited until A) we're producing files batik likes (or we file a bug report with them if the problem is on their end) and B) we figure out who really has the most accurate filter implementation and either match it, or inform them if ours is "better".

This needs to be done, but it's all pretty orthogonal to the presets implementation as outlined above.