RUN-NONINTERACTIVE is not a valid parameter for 'script-fu-fuzzy-border'.

Quoting Milos Prudek :

I simplified the above problem into the following script:

(define (fuzzy-border-single filename) (let* ((image (car (gimp-file-load RUN-NONINTERACTIVE filename filename))) (drawable (car (gimp-image-get-active-layer image)))) (script-fu-fuzzy-border RUN-NONINTERACTIVE image drawable '(255 255 255) 120 TRUE 9 FALSE 0 FALSE TRUE)
(gimp-file-save RUN-NONINTERACTIVE image drawable filename filename) (gimp-image-delete image)))

This script should be able to run with this command:

gimp -i -b '(fuzzy-border-single "foo.jpg")' '(gimp-quit 0)'

But it produces only this: batch command: experienced an execution error.

And it operates correctly if the script-fu-fuzzy-border line is replaced with (plug-in-unsharp-mask RUN-NONINTERACTIVE image drawable 1 1 1)

-- Milos Prudek

Quoting Milos Prudek :

How am I supposed to discover that RUN-NONINTERACTIVE is not a valid parameter
for 'script-fu-fuzzy-border' if "run_mode" is in the parameter list in the Procedure Browser, and furthermore plug_in_unsharp_mask does indeed work with RUN-NONINTERACTIVE ?

It is my understanding that ALL Script-fus are run non-interactively. My guess (I am not sure of this) is that the Procedural DataBase browser lists Run Mode as a parameter because it needs to be specified if calling Script-fus from either another scripting language such as Python or from a plug-in.

Nontheless, Run Mode should not be specified when calling Script-fus from Script-fus.

Quoting Milos Prudek :

On Sunday 09 of September 2007 14:53:52 saulgoode@flashingtwelve.brickfilms.com wrote:

RUN-NONINTERACTIVE is not a valid parameter for 'script-fu-fuzzy-border'.

You are right. Unfortunately when I remove RUN-NONINTERACTIVE, the script fails anyway, this time with this error message:

(jpeg:14957): LibGimp-CRITICAL **: gimp_drawable_get: assertion `width > 0 && height > 0 && bpp > 0' failed
/usr/lib/gimp/2.0/plug-ins/jpeg: fatal error: Segmentation fault

The problem with your code is that, since the Fuzzy Border script is being asked to flatten the resulting image, the resulting layer does not have the same 'drawable' ID as before the flattening. If you do a second 'gimp-image-get-active layer' after flattening then you will be passing the proper 'drawable' ID to the save plug-in.

The 'Segmentation fault' is a bit scary; the JPEG plug-in should probably test whether it has been passed an invalid drawable ID.

Quoting Milos Prudek :

It is my understanding that ALL Script-fus are run non-interactively.

script-fu-fuzzy-border can run interactively. It is available in Right-click/Script-Fu/Decor/ menu in GIMP. It asks interactively for its parameters. Is it an interactive run?

The dialogs for Script-fus are generated and handled by the GIMP. Unlike plug-ins and other scripting languages, there is nothing that a Script-fu script has to do to interact with the user -- the parameters are defined by the dialogs before the 'script-fu-*' function is evaluated. This is why the function is considered non-interactive.

not have the same 'drawable' ID as before the flattening. If you do a second 'gimp-image-get-active layer' after flattening then you will be passing the proper 'drawable' ID to the save plug-in.

OK. I tried to implement your idea:

(define (fuzzy-border-single filename) (let* ((image (car (gimp-file-load RUN-NONINTERACTIVE filename filename))) (drawable (car (gimp-image-get-active-layer image))))

(script-fu-fuzzy-border image drawable '(255 255 255) 120 TRUE 9 FALSE 0 FALSE TRUE)
(set! (drawable (car (gimp-image-get-active-layer image)))) (gimp-file-save RUN-NONINTERACTIVE image drawable filename filename) (gimp-image-delete image)))

But it outputs "batch command: experienced an execution error."

I learned the basics of Scheme yesterday. Is this some kind of scope error? Am
I changing a different "drawable" variable?

Sort of. You have a couple of unwanted parentheses in your 'set!' statement and 'drawable' is being treated as a function. The appropriate syntax would be:

(set! drawable (car (gimp-image-get-active-layer image)))

You're doing well for only your second day with Scheme. One thing that might help you in debugging scripts is using the Script-fu console. If you open the console ("Xtns->Script-fu->Script-fu Console") and execute your command providing appropriate parameters:

(fuzzy-border-single "/home/milos/somefile.jpg")

then the error messages produced will be somewhat more useful than "experienced an execution error".

Hi,

On Sun, 2007-09-09 at 15:28 -0400, saulgoode@flashingtwelve.brickfilms.com wrote:

The dialogs for Script-fus are generated and handled by the GIMP. Unlike plug-ins and other scripting languages, there is nothing that a Script-fu script has to do to interact with the user -- the parameters are defined by the dialogs before the 'script-fu-*' function is evaluated. This is why the function is considered non-interactive.

That is not quite right. The dialog is generated by the Script-Fu extension and the extension should only show the interactive dialog when the script is called in interactive mode.

The problem here is that if you call a Script-Fu script from another Script-Fu script, then you are not doing a PDB procedure call. The called script is evaluated directly by the Scheme interpreter. This may lead to a somewhat different calling convention. I haven't looked at it in detail and can't tell you exactly what this means for the run-mode.

Sven

--- Milos Prudek wrote:

Thank you for the debugging tip. It is quite discouraging when the computer tells you "your program is wrong, and I am not going to tell

you what is wrong with it, not even a small hint".

As a Winblows user, you get used to it. :)

_____________________________________

Sven Neumann (sven@gimp.org) wrote:

The problem here is that if you call a Script-Fu script from another Script-Fu script, then you are not doing a PDB procedure call. The called script is evaluated directly by the Scheme interpreter. This may lead to a somewhat different calling convention. I haven't looked at it in detail and can't tell you exactly what this means for the run-mode.

Since script-fu parses all the scripts into memory and invokes the respective functions from there it basically means, that the function gets invoked as defined, i.e. without the run mode parameter.

If you want to pass the run mode parameter you can use the function used internally by script-fu:

(gimp-proc-db-call "script-fu-sphere" RUN-INTERACTIVE 100 100 1 '(255 0 0) '(0 0 255))

I hope this helps, Simon