Effects documentation
I would like to see some basic documentation for every effect in Inkscape telling: - what state Inkscape must be in for the effect to be successful - how the effect responds to errors - what changes to the document result from the effect - dependencies of the effect (language, additional libraries)
A wiki seems like it's a good place to start for this documentation. Someone has already started a page for this here: http://wiki.inkscape.org/wiki/index.php/WhatEffectsDo, and I have added one more example. I was going to attempt this on my own, but I thought I'd do a callout to the developers first because they know what their effects do better than I do, and when I was effects code on the SVN some of it wasn't documented much.
Thanks for effecting,
--Justin
On Mon, 2006-05-15 at 11:18 -0400, Justin Wikinator wrote:
I would like to see some basic documentation for every effect in Inkscape telling:
- what state Inkscape must be in for the effect to be successful
- how the effect responds to errors
- what changes to the document result from the effect
- dependencies of the effect (language, additional libraries)
A wiki seems like it's a good place to start for this documentation. Someone has already started a page for this here: http://wiki.inkscape.org/wiki/index.php/WhatEffectsDo, and I have added one more example. I was going to attempt this on my own, but I thought I'd do a callout to the developers first because they know what their effects do better than I do, and when I was effects code on the SVN some of it wasn't documented much.
While I have no problem with documentation, I think you might have some trouble getting developers to write an maintain it :) Currently the INX file format has room for a lot of the things your mentioning. Specifically the dependencies and where to get them. But, almost none of the INX files have that data in them currently.
So, I'm suggesting two things: - Effort put into making the dependencies in the INX files more correct or robust will pay off for users directly. Also, documenting things there is more likely to be maintained. - A tool that would pull that data out into a human readable format would be cool, as we already said that it is more likely to be maintained :)
--Ted
On Sat, May 20, 2006 at 09:48:08PM -0700, Ted Gould wrote:
While I have no problem with documentation, I think you might have some trouble getting developers to write an maintain it :) Currently the INX file format has room for a lot of the things your mentioning. Specifically the dependencies and where to get them. But, almost none of the INX files have that data in them currently.
So, I'm suggesting two things:
- Effort put into making the dependencies in the INX files more correct
or robust will pay off for users directly. Also, documenting things there is more likely to be maintained.
- A tool that would pull that data out into a human readable format
would be cool, as we already said that it is more likely to be maintained :)
Maybe a third thing would be to simply try to recruit a few interested users to get involved in helping to improve the inx files? The INX file format is reasonably straightforward, and with a little guidance I would bet even non-technical users could get quite good at improving these files.
I suspect most of the reason people haven't been adding to those files is just that they don't know that they can, or that they are assuming it to be much harder than it actually is.
Bryce
participants (3)
-
Bryce Harrington
-
Justin Wikinator
-
Ted Gould