Simon Budig wrote:
Marc Lehmann (pcg@xxxxxxxx) wrote:
On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney <mooney@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Does anyone know any good reasons why Guile would be an inappropriate choice for replacing SIOD?
As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own.
(These are not my arguments, I just repeat what I think was one of the bigger points back then).
It was a point that I indeed support very strongly :)
IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well).
I don't want to tell a newbie on Windows to install Python, because he needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him "drop this file in that directory and invoke it" and I don't have to care whats his platform and what interpreters are installed.
This is, I think, really shooting ourselves in the foot. By making this choice, we are choosing to use a broken, out-of-date, scheme interpreter when _much_ superior alternatives exist, because we don't want to force installers in have to install another library. Isn't that what installers do!? Guile is specifically designed to be an extension language for applications. It is a shared library. It is a perfect replacement for the gimp's soid bundle.
The problem I see with this argument is:
You are turning a packaging problem into a design choice. Suppose, for example, we choose to make siod a seperate dynamically linked library (included in the gimp sources, even). What is the difference between forcing you to install soid, and forcing you to install guile?
The "not-creating-another-depency" argument is an illusion. soid is already a dependency. It is just a dependency we choose to include in the sources. Why did we do this? Is jpeglib included in the gimp source tarball? What about libppm? libpng? These are all dependencies. Should we include those in the tarball as well?
It is true enough that you can argue that jpeglib is not as important as siod because you can disable the jpeg plugin on the configure command line. But this can be true for soid as well. While I don't immediatly see a ./configure option to disable script-fu, there is no technical reason why we can't have a configure option that disables script-fu.
In fact, because you can disable script-fu, you cannot gaurentee that there exists a script system at all, let alone script-fu.
Basically, the only real way to ensure that every single instance of the gimp has a scripting language installed is to package the gimp for every platform ourself. Not moving to something besides siod is *crippling* to our supported, which should be the best, extension language.
So we should have at least one self contained language that comes with the GIMP. I am not exactly tied to Script-Fu, but I don't see any other obvious candidates.
Guile is in all ways superior to siod, and is even self contained. We could even include a version of Guile in the tarball, which is what we do now with soid anyway.
-- Dan
