Daniel Rogers ([EMAIL PROTECTED]) wrote:
> Simon Budig wrote:
> >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.

I think you missed my point. I am not advocating for script-fu over
guile (or that is not my main point), I am advocating for a simple
self-contained language, that is included with the GIMP sources.
Lets call it Gimp-Basic.

> 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 difference of course is, that Gimp is most likely the only
application using SIOD and we would have full control over the version
we deliver. I have no idea how GUILE usually is distributed, I was
assuming that GUILE gets distributed similiar to Perl or Python.
[Assuming this is true, I might be wrong here:] When we'd use GUILE (as
the "Gimp-Basic") and the user uses Guile for different tasks he
obviously would expect that GIMPs Guile is the same as his GUILE. Having
our own Guile in the Installer would be a bad idea then, either because
of e.g. Windows DLL hell or because of two different versions.

> 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?

Well, supposing SIOD were a library, it is perfectly natural to include
SIOD, because it is not as universally available as the other libraries.
Having libraries in the GIMPs tarball already has happened...

> 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.

[there used to be a dependency on the SIOD interpreter for parsing batch
commandlines, but IIRC this is gone now]

All true and well, but my point is: I *want* to have a scripting system
that is available almost universally. And this is the reason why siod is
much more important than libjpeg right now. The scripting system not
necessarily has to be Script-Fu, but it did the trick for at least six
or seven years now...

> 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.

I indeed would be very happy if I could write all my scripts in Python,
but this is not an option, since I cannot assume that Python is
available on all gimp installations. Thats why I write most of my
scripting stuff in Script-Fu, and it works. Ok, sometimes it is a pain
to debug (I think most of the debugging problems could be solved by
evaluating errobj instead of displaying a silly "see errobj" message),
but when the script is completed it is plug'n'play.

Include a GUILE in the Gimp sourcecode, make sure that it doesn't
conflict with other GUILEs on the target system and use it as the GIMPs
default language. Perfectly fine with me as long as I have a language
that is guaranteed to be available for 99% of the GIMP installations.

      [EMAIL PROTECTED]       http://www.home.unix-ag.org/simon/
Gimp-developer mailing list

Reply via email to