On 04/04/2010 11:53 AM, Andreas_P wrote:

Now my proposal: Just look at the upcoming (brand) new version of "racket" which is nothing else than the newly renamed and rebranded "PLT-Scheme". PLT is (in case you don't know) the bunch of hackers who are refining the elements of R6RS-Scheme to a mixture which can sb. call "impressive"...

Hi

To me, there is only one sensible scripting language to consider when talking about a major overhaul of the GIMP scripting core, and that is JavaScript. It is a well-known and understood scripting language with a bright future (HTML5) and that also is already embraced by the GNOME community. IMO, putting a big effort on introducing any other scripting language to GIMP would be futile.

/ Martin

I thought I'd comment with some of my opinions on the proposal/project presented by Andreas_P. I have included the original post in its entirety at the end of this mail (as it's been a while since it was made).

Over the years, GIMP's plug-in/extension system has remained fairly language agnostic. In addition to the original C and Script-fu, there have been implementations for Perl, Java, Python, C#(Mono), Lua, Javascript, and Ruby. There should be no real objection should someone wish to provide support for Yet Another language or even another dialect/implementation. However, should the goal be incorporation within the "official" GIMP distribution -- or supplanting of Script-fu with another Scheme implementation -- then it would be necessary to gain a broader acceptance from the project's developers.

Script-fu, both the original SIOD-based and the current TinyScheme-based implementations, is inarguably limited in capability, but it is important to understand the reasons behind the limitations when considering alternative GIMP extension languages. In many ways, Script-fu's limitations prove to be beneficial and offer advantages over other, more capable alternatives. Hardly any of the limitations are particularly attributable to the fact that Script-fu uses Scheme as its basis, other than perhaps Scheme's non-algebraic syntax for formulas and its lack of popularity amongst the general programming community. (There may be some issues that result from the specific Scheme implementation; e.g., unit testing support).

Script-fu's main limitations are that it is restricted from interfacing directly with libgimp -- it only has access to functionality as provided by the Procedural DataBase (PDB) -- and that it does not support usage of external libraries or modules (e.g., SF can't produce a customized GTK dialog window or employ a third-party FFT algorithm). These limitations are both artificial and by design (TinyScheme supports extensions and external bindings, but access to these is disabled in Script-fu).

Nonetheless, it is because of this restriction that a Script-fu script can be relied upon to work with all platforms without any dependency on libraries/functionality not included in a GIMP install. While Python-fu may itself be bundled with the official GIMP distribution (and thus not depend upon Python being installed on the host system) and a Python-fu programmer might be able to write a plug-in which limits itself to using only the GIMP-provided functionality, it is not uncommon that Python scripts "import" functions from external libraries which may not be available on the user's system; or worse, are not available for the user's platform. This creates a mini version of "dependency hell" and in practice distributing such plug-ins can be more problematic than distributing C-based plug-ins (which can statically link the necessary libraries).

I say this not to criticize Python-fu (or any of the other more capable plug-in languages), but to highlight that the "module" functionality provided by R6RS does not particularly resolve any issues for current TinyScheme. I currently have an "sflib" file that contains several dozen convenience functions which I often employ within scripts I'm writing; however, I include the functions by copying the "library" code to my script, defining it within a local scope. Yes, this results in duplication of code and all the negative aspects that entails, but the alternative is that my script should fail unless the users have my library file installed on their system.

This issue is not one of modularization, encapsulation, environment scopes, or any number of "advanced features" in modern high-level programming languages; it is a matter of distribution of dependencies not included in GIMP by default. The only way to properly resolve the issue would be institution of a repository/packaging system with automatic dependency resolution a la Debian's apt-get (while providing cross-platform support). This is certainly doable -- in fact the G'Mic project does a pretty fair job of implementing this in their third-party offering -- but in my opinion this challenge should be met before any script or plug-in language can expect to supplant Script-fu in GIMP.

I don't mean to sound negative, in fact I would personally encourage your project to pursue adding Racket support to GIMP. However, you should initially approach it from the standpoint of producing a self-contained, third-party extension which provides its own infrastructure for distribution and maintenance of Racket-based GIMP add-ons. I would even be interested in participating in such a project. If successful, then later on the GIMP project might see its way clear to incorporating your offering within the official GIMP distribution.

=============================== -------------------------------

Quoting Andreas_P:

I hope that this email was not being posted several times here Hey all,

I think I did loose the previously designed letter which I thought, having sent to Kevin Cozens.
Now I have to write the whole letter again, hoping for him, that he is on this list, from time to time.

It sounded like that:

Dear Mr. Cozens,

Thank you for contributing to GIMP!

[For the sake of clarity I have to introduce myself: My name is Andreas Posur and I am a student on a big technical university inside Germany, enrolled in BSc. EECS]

I got the feeling that Script-Fu / Tiny-Fu (SIOD) isn't well recepted because of "old & unsexy"...
quote: from the internet research.
I personally can support this statement. And I had some "REALLY" difficult problems to get a proper "unit testing" within R5RS (tinyscheme).

Now my proposal: Just look at the upcoming (brand) new version of "racket" which is nothing else than the newly renamed and rebranded "PLT-Scheme". PLT is (in case you don't know) the bunch of hackers who are refining the elements of R6RS-Scheme to a mixture which can sb. call "impressive"...

[quote

Lazy - Functional - Reactive - OO - Macros (powerful, hygenic) - Delimited continuations - Module system (dynamic)

Not too mention the basics, eye opening approaches to XML and Web, an IDE, debugger, contracts, typed/dynamic language, jit, Android development, ... and on and on.

The talent of the core PLT group is outstanding. Matthias Felleisen for example was awarded an ACM Fellowship in 2006 for contributions to programming languages and development environments. His academic publications are right up there with the best out there, yet he spends as much time focused on the foundational aspects of teaching kids, and students as high brow papers, and the real world demands of programming. And the rest the core are not too shabby either.

/quote] taken from: http://news.ycombinator.com/user?id=boskone

The Programming Languages Teaching Website: http://www.plt-scheme.org will be transferred to plt-racket.org

DrScheme [IDE] will be DrRacket, MrED will be gracket, and mzscheme will come out as racket.

My main problem is that only Kevin probably will have the insights, what has to change and what not in terms of tiny-fu and tinyscheme, he developed the interpreter connector.

So if anybody is able to help me (and perhaps later others with this) I would really appreciate that.
My target is finally to get a powerful, ease of use, sexy Scheme derivate running and implementing GEGL Operations/Services/Actions that PhotoShop would have to fear...

Greetings from Germany, yours sincerely: Andreas Posur

(And when I have the time then I would do some basic bughunting (my c skillz aren't that good yet)...)

The real problem with script-fu is that it is archaic. Few people in this modern age want to deal with Lisp-derived languages, with all those ridiculous strings of parentheses. It's like going back to the dark ages of programming. Even a scripting language derived from BASIC would make more sense.

-- Bill

On Wed, 2010-04-07 at 12:56 -0400, saulgoode@flashingtwelve.brickfilms.com wrote:

Script-fu's main limitations are that it is restricted from interfacing directly with libgimp -- it only has access to functionality as provided by the Procedural DataBase (PDB)

I think I better add a comment here, since there might be a misunderstanding originating from this sentence. libgimp is the C wrapper of the Procedural Database. It wraps the PDB into an API that can be conveniently called from plug-ins written in C. Additionally it provides read/write access to the tiles of an in-core image. But this functionality can also be accessed by other language bindings, either directly or by wrapping the C API in libgimp.

Sven

On Wed, 2010-04-07 at 10:54 -0700, Bill Skaggs wrote:

The real problem with script-fu is that it is archaic. Few people in this modern age want to deal with Lisp-derived languages, with all those ridiculous strings of parentheses. It's like going back to the dark ages of programming. Even a scripting language derived from BASIC would make more sense.

That is totally irrelevant for this discussion. There are other scripting languages that can be used, Script-Fu is just one of them. It addresses the needs of people who like those strings of parentheses. If you prefer BASIC, feel free to add a GIMP extension that allows to write scripts in BASIC. It's really pretty simple to wrap the PDB to whatever scripting language you like.

Sven

I'd like to chime in here also supporting tiny-fu.

I agree with almost everything said by SG

While the language is less common than some languages, it provides a very simple way to script existing pdb functions when you have no need to access the individual image pixels.

Rather than considering replacing scheme or adding yet-another-scripting-language, there are two things that could really improve the usability of the existing implementation:

-A visual editor (proposed here as a GSOC project: http://archives.free.net.ph/message/20100325.130320.3246ef1c.en.html ) I would envision this to be a separate plugin sharing code with the existing script-fu plugin
-(optional) preview capability within the script-fu plugin, or even full document preview, applying the script to the existing document without exiting the filter, updating on change of the parameters.

Just my biased opinion (having used a RPN calculator for 25+ years, Scheme doesn't scare me ;)

-Rob A>

Hi,

On Thu, Apr 8, 2010 at 4:27 PM, Rob Antonishen wrote:

Rather than considering replacing scheme or adding yet-another-scripting-language, there are two things that could really improve the usability of the existing implementation:

-A visual editor (proposed here as a GSOC project: http://archives.free.net.ph/message/20100325.130320.3246ef1c.en.html )  I would envision this to be a separate plugin sharing code with the existing script-fu plugin
-(optional) preview capability within the script-fu plugin, or even full document preview, applying the script to the existing document without exiting the filter, updating on change of the parameters.

I believe most users write script-fu scripts to automate commonly repeated steps. Therefore, it would be even better to complete action framework so that user could record commonly used action sequences and play them from GUI.

2010/4/8 Aurimas Juška :

I believe most users write script-fu scripts to automate commonly repeated steps. Therefore, it would be even better to complete action framework so that user could record commonly used action sequences and play them from GUI.

I think script-fu would be ideal for such use. If you could record an action, and then optionally convert it to a full script a lot of convenience and ease of automation would be added.

Von: Alexia Death

2010/4/8 Aurimas Juška :

I believe most users write script-fu scripts to automate commonly repeated steps. Therefore, it would be even better to complete action framework so that user could record commonly used action sequences and play them from GUI.

I think script-fu would be ideal for such use. If you could record an action, and then optionally convert it to a full script a lot of convenience and ease of automation would be added.

Writing out recorded actions in any language shouldn't be the problem...

Regards, Michael

Martin Nordholts wrote:

To me, there is only one sensible scripting language to consider when talking about a major overhaul of the GIMP scripting core, and that is JavaScript. It is a well-known and understood scripting language with a bright future (HTML5)

It is well known in that a lot of people know it exists. As for it being understood, not so much. I don't know much about Javascript. Once or twice I've used it for some small thing. I don't think of it as useful for anything outside a web site use.

On 1/14/11, Kevin Cozens wrote:

It is well known in that a lot of people know it exists. As for it being understood, not so much.

I hate to tell you, but JS indeed is broadly known and used. At least half of Creative Suite is scripted in JS, and there is a whole industry around various JS based extensions and scripts for CS. I won't say how many times I heard users saying "Oh my, I could write scripts in JS, but learning a new language just for GIMP? Thanks, no." only because I stopped counting few years ago. Just a little perspective from outside :)

Alexandre Prokoudine http://libregraphicsworld.org

On 01/14/2011 12:29 PM, Alexandre Prokoudine wrote:

On 1/14/11, Kevin Cozens wrote:

It is well known in that a lot of people know it exists. As for it being understood, not so much.

I hate to tell you, but JS indeed is broadly known and used. At least half of Creative Suite is scripted in JS, and there is a whole industry around various JS based extensions and scripts for CS. I won't say how many times I heard users saying "Oh my, I could write scripts in JS, but learning a new language just for GIMP? Thanks, no." only because I stopped counting few years ago. Just a little perspective from outside :)

This might be true for Scheme but Python is a lot more mainstream.

And IMHO it's not as much a question of language than a question of API ( I write my Python scripts by looking at Scheme code & docs). When your remove all things "document"-related from someone's alleged JS expertise, there isn't much left and that's all they would be able to reuse to write Gimps scripts in JS...

Python is a rather nice and sound language, GIMP already has an interface for it, it only needs some improvements and a better/more up-to-date documentation...

On Thu, Apr 08, 2010 at 05:17:45PM +0200, Michael Schumacher wrote:

Von: Alexia Death

2010/4/8 Aurimas Juška :

I believe most users write script-fu scripts to automate commonly repeated steps. Therefore, it would be even better to complete action framework so that user could record commonly used action sequences and play them from GUI.

I think script-fu would be ideal for such use. If you could record an action, and then optionally convert it to a full script a lot of convenience and ease of automation would be added.

Writing out recorded actions in any language shouldn't be the problem...

I think that this is one of the most wanted TODO for GIMP. If it is not a problem, why noone has planned to do it?

It is not a rethoric question...I am really interested to hear the reasons behind this, apparently easy, uninplemended feature.

I'm not a developer, so forgive me if I may post stupid questions..

On Friday 14 January 2011 21:59:36 Marco Ciampa wrote:

On Thu, Apr 08, 2010 at 05:17:45PM +0200, Michael Schumacher wrote:

Writing out recorded actions in any language shouldn't be the problem...

I think that this is one of the most wanted TODO for GIMP. If it is not a problem, why noone has planned to do it?

As far as I (not a GIMP developer) know, it's not writing out actions that is a problem, but recording them. Preferably in a proper, clean, not too hackish way. And also as far as I know, it's not about missing plans, but about implementing it and the prerequisites.

Cheers, Daniel

On 14.01.2011 21:59, Marco Ciampa wrote:

On Thu, Apr 08, 2010 at 05:17:45PM +0200, Michael Schumacher wrote:

Von: Alexia Death

I think script-fu would be ideal for such use. If you could record an action, and then optionally convert it to a full script a lot of convenience and ease of automation would be added.

Writing out recorded actions in any language shouldn't be the problem...

I think that this is one of the most wanted TODO for GIMP. If it is not a problem, why noone has planned to do it?

Note the "If you could record an action" in Alexia's message.

Recording is the hard part, actually. The Undo list only has images, not the commands and parameter values used for them.

See the corresponding report: https://bugzilla.gnome.org/show_bug.cgi?id=51937

Martin wants to change the Undo system using the Command Pattern (see comment 43 of the above report, and
http://en.wikipedia.org/wiki/Command_Pattern for an explanation of this pattern).

Once we have that (or something equivalent), then writing out the commands in any programming language shouldn't be a problem anymore.

HTH, Michael

On Fri, 2011-01-14 at 22:39 +0100, Michael Schumacher wrote: [...]

Martin wants to change the Undo system using the Command Pattern (see comment 43 of the above report, and
http://en.wikipedia.org/wiki/Command_Pattern for an explanation of this pattern).

It's a good architecture - I've used a scheme-scriptable editor once before that had this pattern (before they were called patterns) along with MVC, and along with scheme access to the menus, keypress events etc., and it turned out to be very powerful.

(when I brought it up in IRC some time ago there didn't seem to be much support, though, so I am not sure there's agreement on it yet)

Liam

On Tue, 2011-01-18 at 19:59 -0500, Liam R E Quin wrote:

On Fri, 2011-01-14 at 22:39 +0100, Michael Schumacher wrote: [...]

Martin wants to change the Undo system using the Command Pattern (see comment 43 of the above report, and
http://en.wikipedia.org/wiki/Command_Pattern for an explanation of this pattern).

It's a good architecture - I've used a scheme-scriptable editor once before that had this pattern (before they were called patterns) along with MVC, and along with scheme access to the menus, keypress events etc., and it turned out to be very powerful.

(when I brought it up in IRC some time ago there didn't seem to be much support, though, so I am not sure there's agreement on it yet)

I discussed this with Martin, and the outcome was to have a command layer around the core, and not make it a 1:1 match of undo operations, because undos are very atomic operation, whereas commands rather correspond to undo groups of arbitrary complexity.

So there will be a connection between the two, but they can't be "merged" the way Michael's last mail suggests.

ciao, --Mitch

On Thu, 2011-01-20 at 15:10 +0100, Michael Natterer wrote:

I discussed this with Martin, and the outcome was to have a command layer around the core, and not make it a 1:1 match of undo operations, because undos are very atomic operation, whereas commands rather correspond to undo groups of arbitrary complexity.

In Author/Editor we had command groups, so that one command might have a whole sequence of sub-commands but make a single entry in the undo/redo history. The handler chain got to see the outer command as well as the sequence of inner commands, of course.

Liam

On Thu, 2011-01-20 at 23:01 -0500, Liam R E Quin wrote:

On Thu, 2011-01-20 at 15:10 +0100, Michael Natterer wrote:

I discussed this with Martin, and the outcome was to have a command layer around the core, and not make it a 1:1 match of undo operations, because undos are very atomic operation, whereas commands rather correspond to undo groups of arbitrary complexity.

In Author/Editor we had command groups, so that one command might have a whole sequence of sub-commands but make a single entry in the undo/redo history. The handler chain got to see the outer command as well as the sequence of inner commands, of course.

Yes, but still even the most basic, non grouped command might still be triggering a whole series of atomic micro undo operations that would go into an undo group associated with the command.

Look at the current set of undo pushing functions in app/core/gimpimage-undo-push.h, which cover the entire set of available user actions and PDB calls. They are really few compared to what variety of manipulations are possible.

--mitch

(oops, forgot to send this)

On Fri, 2011-01-21 at 13:32 +0100, Michael Natterer wrote: [...]

Yes, but still even the most basic, non grouped command might still be triggering a whole series of atomic micro undo operations that would go into an undo group associated with the command.

I'm not sure why that's a problem. Probably I'm missing something.

The _theory_ is that anything that changes the model goes through a command that is matched against a chain of handlers, with the default handler being the app core.. the _practice_ is that the granularity of that is up to the developers to expose or not expose, so if "open-as-layers" is an atomic command, then the handlers wouldn't ever see the "add layer" and "file open" commands happen and won't be able to change "open as layers" to position the layers automatically (for example). Long term, people writing scripts would probably push for more things to be exposed.

Look at the current set of undo pushing functions in app/core/gimpimage-undo-push.h, which cover the entire set of available user actions and PDB calls. They are really few compared to what variety of manipulations are possible.

It could change over time though.

I'd really like to see things like the ability to call anything that has a keystroke or menu item or button to do it, for example. And at that point, if every menu command went through the command/handler chain, recording actions would be a lot more feasible. Or consider "undo last brush stroke and repeat with eraser instead"...

We'll see - it's easier to have dreams than to dig ditches.

Best,

Liam