Dave Neary <[EMAIL PROTECTED]> 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.

Gimp-developer mailing list

Reply via email to