Hi,

On Thu, 2006-06-01 at 00:34 -0400, Kevin Cozens wrote:

What next?
Script-Fu should be removed from the GIMP source tree and made available as a separately developed project. This would allow the first two issues listed under "Differences" to be easily solved.

How would this solve the issues? Do you propose that the installation of script-fu or tiny-fu is mutually exclusive? This would of course be the ideal solution. But since you say that tiny-fu is never going to be able to run all script-fu scripts unmodified, the chance that anyone would install tiny-fu in favor of script-fu seems rather small.

In regards to some people thinking that moving Script-Fu out of the GIMP source tree is going to make some people feel Script-Fu is being retired they would be correct. A number of the GIMP developers have been wanting Script-Fu to die for some time. It has just been a question of when, rather than if, it will happen.

With the Python binding maturing, it could become the default GIMP script interpreter. But people will still want to be able to run some script-fu script occasionally.

Sven

On Fri, 02 Jun 2006 07:49:05 +0200, Sven Neumann wrote:

On Thu, 2006-06-01 at 00:34 -0400, Kevin Cozens wrote:

What next?
Script-Fu should be removed from the GIMP source tree and made available as a separately developed project. This would allow the first two issues listed under "Differences" to be easily solved.

How would this solve the issues? Do you propose that the installation of script-fu or tiny-fu is mutually exclusive? This would of course be the ideal solution.

I do not think that it would be the ideal solution. I have been running the latest versions of Script-Fu and Tiny-Fu together for several months now and I enjoyed the fact that I could easily compare their behavior without having to maintain separate GIMP installations (well, besides the ones for HEAD vs. stable 2.2.x).

From my point of view, the ideal solution would be this:

- Remove Script-Fu from the gimp module and create a "gimp-script-fu" module. - Declare that Script-Fu is deprecated (but still available as a separate package for those who really want it). - Distribute Tiny-Fu in the gimp tarball so that it becomes the default Scheme interpreter.
Note that the last point does not require merging both modules. This could be done by changing the "make dist" target in the gimp so that it checks for the presence of the tiny-fu module and bundles the whole thing together.

This is the ideal solution, even if it may be controversial. We know that the vast majority of the users will not install a new scheme interpreter if it is not part of the default package. We also know that the Linux distributors and packagers for other platforms will simply follow our tarball structure instead of bundling things together (some distributions provide support for "suggested" or "recommended" packages, but again many users do not bother installing these additional packages). So as long as Script-Fu is part of the gimp package, it will prevent Tiny-Fu from being widely adopted.

The fact that I was the first one to report the problems in bug #342578 although the problem had existed for several months should tell something about the current adoption of Tiny-Fu.

On the other hand, the advantages that Kevin listed for Tiny-Fu over the old interpreter are real and very useful: support for UTF-8, better debugging, etc. Anything that can be done to encourage people to switch from Script-Fu to Tiny-Fu would be a good thing, IMHO.

But since you say that tiny-fu is never going to be able to run all script-fu scripts unmodified, the chance that anyone would install tiny-fu in favor of script-fu seems rather small.

The changes required are rather small. The main requirements are to rename the *.scm files to *.sct and to replace script-fu-* by tiny-fu-* in the files (both of these are easy). The other changes such as making sure that variables are declared and in the correct scope are only applicable to a few scripts and should have been done in the first place anyway, even for script-fu. And in any case, these changes are only necessary for those who have written their own scripts or downloaded them separately. We have broken more things in the past for Script-Fu itself (e.g., PDB changes) so I do not think that the transition from Script-Fu to Tiny-Fu would be more painful than what he have done previously.

If we allow both interpreters to be installed together (which is currently the case), then it would be possible to distribute Script-Fu as an optional package. Those who do not want or cannot update their old scripts could install the optional Script-Fu package to be able to run them. It would simply reverse the current situation by making Tiny-Fu the default and this would be a Good Thing.

In regards to some people thinking that moving Script-Fu out of the GIMP source tree is going to make some people feel Script-Fu is being retired they would be correct. A number of the GIMP developers have been wanting Script-Fu to die for some time. It has just been a question of when, rather than if, it will happen.

With the Python binding maturing, it could become the default GIMP script interpreter. But people will still want to be able to run some script-fu script occasionally.

Whatever comes bundled in the tarball will become the default GIMP script interpreter. In the past, we had Script-Fu and Perl-Fu/Gimp-Perl. Then the Perl bindings started to be distributed as a separate package and people stopped using them rather quickly. The opposite happened for the Python bindings. We can also observe the same thing for many other plug-ins such as gimp-gap, etc.

In summary, regardless of what we claim is required, recommended or suggested, the main thing that matters is what comes inside the official gimp tarball. After having tried both Script-Fu and Tiny-Fu for several months, I would like to get rid of Script-Fu as soon as possible.

-Raphaël

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.