Hello,
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.
Cheers, Dave.
-- Dave Neary [EMAIL PROTECTED]
_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
