On Fri, 02 Jun 2006 07:49:05 +0200, Sven Neumann <[EMAIL PROTECTED]> 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.
>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
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.
Gimp-developer mailing list