Sven Neumann wrote:
It's just a packaging issue. As long as we make sure that everyone can
install gimp-script-fu, we have script-fu support. Do you really want
to continue to include it with GIMP with all the problems that arise
from doing that? I don't think it's worth it.

Including guile doesn't mean supporting it. As it is, there are a bunch of things we include that don't get much support because the original authors have gone their own way. This time we're not even talking about *pretending* that this is a GIMP thing - we set up a configure script that checks if there's a local guile installed, if there is it uses it, otherwise it calls configure && make on its copy, and uses it in the GIMP. It is the same thing as we currently have, except that instead of George Carrette's SIOD, we'll be using GUILE. And this time, we will be using an official release of a scheme interpreter, not a GIMP modified copy. I don't see a downside.

In the long run we should move as much as possible out of the GIMP
package. This will assure that we provide a stable and powerful API
and will enable more extensions and plug-ins to be written. IMO moving
script-fu out of the tree and putting it on the same level as
gimp-perl and other language bindings is a very important thing to do.

There is a certain point at which this is unreasonable. If we move all the C plug-ins out into another module, and all the brushes, patterns and other data to another module, and all the script-fu and python-fu to separate modules, we'd have a small, stripped down core, but a usable GIMP would be made up of 6 or 7 CVS modules, 6 or 7 packages to download, and 6 or 7 packages to maintain.

The sooner it happens the better. Actually I was considering this for
2.2 (along with gimp-python). We are not doing ourselves a favor if we
treat Script-Fu any better than other language bindings.  Especially
since it is technically the worst of them all.

I'm afraid that moving all of the langauge bindings out of the core would only result in the bindings not being maintained as well. As it is, the Python bindings are in need of a bit of a work-over before 2.0, if I remember correctly, and script-fu itself is only getting the minimum of maintenance for it not to be broken.

Anyway - working towards a minimalist GIMP is kind of going away from what I'd like to see. I'd be more interested in being pretty liberal about the patches and plug-ins we accept in the core, and get more plug-in authors involved in maintenance work and development. For that we need to define guidelines for getting a plug-in into the core, and get the word out that we're interested in more or less anything and everything to do with image processing. Hand in hand with that we would also need guidelines for when a plug-in would get dropped (temporarily?) from the distribution if it is unmaintained. If we have decent guidelines, this would add very little work for maintainers, who could just let plug-in authors take care of their own code.


Dave Neary

_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to