Hi, Dave Neary <dneary@xxxxxxx> writes: > 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. We don't include libpng or libjpeg or glib or gtk+. Why should we include guile? If we need guile for script-fu and you argue that script-fu needs to be part of the standard gimp tarball, then gimp needs to depend on guile. Where's the 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. This sounds like the right thing to do. I'd go even further and move the GIMP libraries into a seperate package as well. The casual user will not even notice the difference. Users can install a meta package, all packaging systems I am aware of support such a thing. But if we had all these separate modules and would even distribute libgimp separately, we would finally allow other apps to use our widgets and the image processing libary we are developing. Other apps like for example a video manipulation program could be developed around the gimp core. > 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. If it turns out the languages are not maintained outside the GIMP it is probably about time to get rid of them. Actually I believe that it is a lot easier for people to maintain and contribute to a smaller package like gimp-script-fu as it is for the GIMP maintainers to keep Script-Fu alive and decide what to do about contributions from others. > Anyway - working towards a minimalist GIMP is kind of going away > from what I'd like to see. This would a major shift in our goals and policies and it definitely needs more discussion. > 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. This is IMHO not a reasonable goal. At the moment we are doing it like this because we are afraid of finally cleaning up our codebase to a point where it becomes maintainable again. At the moment the GIMP tree is way too large. Not only from a maintainance point of view. I also believe that the casual user is struggling with the shear amount of plug-ins and modules we ship by default. Sven
