I fail to see why Tiny-fu can't be made backwards compatible with
SIOD; at least sufficiently enough to justify a direct substitution.
If compatibility is assumed as a premise (and the appropriate changes
to Tiny-fu implemented), the differences that Kevin Cozens described
all but disappear.
Quote from Kevin:
Differences and problems compared to Script-Fu
1. The filenames of Tiny-Fu scripts must end in .sct to avoid
conflicts with Script-Fu scripts. 2. Scripts must use
Tiny-Fu/tiny-fu instead of Script-Fu/script-fu in public function
names and in the register block.
3. Variables must be defined before first use.
4. Local variables are local in scope and not global as they are in
Script-Fu. 5. Parsing (and execution of scripts?) seems a bit slower
compared to Tiny-Fu.
6. Tiny-Fu includes many of the SIOD functions via a compatability layer.
1. Don't require the ".sct" extension; make Tiny-fu execute ".scm" files.
2. If Tiny-fu is backwards compatible then there is no need to
differentiate the function names.
3. This is good programming practice, anyway, and enforcing it is not
a horrendous idea.
4. Same comment as for #3.
5. Speed isn't a great concern either way.
6. Nothing wrong with this. If this compatibility layer is implemented
as an extension, it could eventually be deprecated.
The main difficulty would seem to be with concerns #3 and #4; they
would be most likely to "break" existing scripts. I would propose the
following project to address this issue (I have seen similar proposals
made previous in the mailing list, in particular for the SoC):
Create a more advanced and coordinated "Plug-in Registry" which would
be the official repository for Script-fu plug-ins (IMO, there is no
need to change the Script-fu name because the interpreter is changed
from SIOD to Tiny Scheme). This repository could perhaps be a Source
Forge project; but something a bit more advanced than the current
Registry (e.g., supporting of versions and "packages").
Errors that result from compatibility issues would prompt the user
with the message that they must upgrade their script. If something
similar to the "ss" sockets extension (available to SIOD but not the
GIMP's Script-fu) were supported, perhaps this upgrade process could
be automated, fetching the appropriate files from the previously
mentioned repository. Eventually, the repository should hold Tiny
Scheme versions of all worthwhile existing scripts and any new
submissions should be verified for Tiny Scheme consistency.
I very much enjoy working with Script-fu and would be willing to
volunteer to assist in updating scripts (the GPLed ones) and
maintaining the Script-fu portion of such a repository (such a
repository should probably also support the GIMP's other scripting
languages). I am not confident of my skills in actually creating such
a repository but perhaps someone else is.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
