Didn't try, but as far as I can tell there is no difference for your script. My python plugins appear in the PDB browser for script-fu, prefixed by "python-fu". That's about the only thing that would make them "special" from the script-fu side of the fence.

0/1 should work.

I'd be interested to know how this works out for you, Graechan.

It would be nice to be able to call other Script-Fu scripts interactively and pass parameters but I'm not sure how that would be achieved. I don't think I've seen an example where it has been done.

The best way to understand this is to think of Script-fu as a plug-in; that is to say, the entirety of Script-fu including all of the individual scripts is one plug-in¹. This is somewhat distinguished from the case of plug-ins written in Python (or C, or Perl, etc). For these other languages, each individual procedure is typically a separate plug-in.

When you call a procedure registered with the PDB, GIMP executes that plug-in; however, in the case of scripts, the procedure that gets executed is actually the Script-fu plug-in -- and the Script-fu plug-in gets passed the name of the particular script that was registered (in addition to any other arguments).

So when you call a Python plug-in from a script, it is no different than calling any of the other plug-ins (e.g., the ones written in C and with names starting with "plug-in-"). Your script has to pass all of the expected PDB parameters, including the 'run mode'.

When a plug-in calls a script, the plug-in also has to provide all of the expected parameters², including the 'run mode' (which is indicated in the PDB documentation for even the "script-fu-*" procedures). However, what happens in this case is that the "Script-fu plug-in" is invoked with the name of the procedure to be run as an extra, hidden argument. The 'run mode' provided by the original plug-in instructs Script-fu how it should behave, and this behavior (interactive, non-interactive, or last-values) would apply to any scripts that then get executed. This is why when you write a Script-fu procedure, you do not generally worry about the run mode; it has already been taken care of before your code is ever executed.

The only special case occurs when you wish to execute another script from your script. In other words, when your script calls a PDB procedure whose name starts with "script-fu-". When this happens, Script-fu is already running (executing your script) and so there is no need to "run the Script-fu plug-in with the name of the procedure to run". All that is necessary is for Script-fu to execute the function that is already defined (just as if it were any other Scheme definition). There is no need to specify the 'run mode' because the invoked procedure will be executed by the same Script-fu interpreter/plug-in as your script and using whatever run mode that Script-fu plug-in was already using. (Note: if your script was invoked from a menu command then it will be using RUN-INTERACTIVE mode. If it was invoked from another plug-in then it will have whatever mode that plug-in specified, usually RUN-NONINTERACTIVE).

In short, as ofnuts stated, calling a Python plug-in from a Script-fu script is no different than calling any other plug-in. It is only when calling a Script-fu script from a Script-fu script which should be treated specially.



¹ Technically speaking, Script-fu is considered an "extension", however, the distinction between an extension and a plug-in is to me rather elusive. If someone has a clear delineation of the distinction between an extension and a plug-in, please share; but in general I haven't found the difference to matter much.

² I believe that Python plug-ins default to a run mode of RUN-NONINTERACTIVE when invoking PDB functions, so the run mode is often omitted from the parameters being passed and if interactive execution of the procedure is desired then it is necessary to explicitly override the default run mode by specifying it as an optional argument.

As was pointed out when Ofnuts originally announced this script, it breaks when run on Windows due to printing excess debug messages:
viewtopic.php?f=9&t=1790&start=30#p23056

Kevin

I never really thought there was any difference between an add on, filter, plug-in, or extension.
Always seemed to be the same thing to me just a different way to name them.



Didn't Ofnuts fix that though?Seems to me that he did.

My impression was that you fixed your copy. It's still the same problematic version offered for download.

I don't remember. The header of the version I have here says:

Looking at the code, I just chnage the code I execute when I get an exception to print more detailed information. So the problem is acknowledged but likely not solved, because I didn't get significant feedback since...

Some investigation leads me to believe that it is some external console message interception that does uncouth things with the I/O stream. So I removed most traces, and reorganized a bit the context save/restore so it should not damage the undo stack even if it crashes.

https://sourceforge.net/projects/gimp-t ... s/scripts/

That's the rub though, isn't it? If the interface to the interactive dialog can't be called while you already have a script running in the scheme interpreter, then the interface code lies outside the interpreter.


I'm not following you here. If an invoked script-fu procedure inherits the run mode, wouldn't it run interactively when invoked from a script that was initially ran from a menu (interactively)? Seems it could never run interactively, if there were no interface available. So in other words, a script-fu script can't call another script-fu script in interactive mode, no matter how it was initially invoked, correct?

You are correct. It was a mistake for me to describe it as "inheriting". The run mode is taken care of before the script code is ever executed -- if interactive then the dialog is presented, the user's settings accepted, and then the script run non-interactively with those settings. The script code itself is in actuality always run non-interactively.


Correct. It should also be mentioned that if a script wishes to call a plug-in using interactive mode, it should not typically use RUN-INTERACTIVE, but instead should use SF-RUN-MODE. SF-RUN-MODE is a system variable that holds the initial run mode of the running script (how it was initially invoked). Even though the script is running in non-interactive mode (per the preceding discussion), it may have been invoked either non-interactively (from a menu, script, or plug-in) or interactively (from a menu or plug-in). If it has been invoked non-interactively then it should not be having plug-in dialogs popping up asking for user input; this should only occur if the script has been invoked interactively (the Difference Clouds script provides a suitable example of this).

Well, I guess the only option is to create the input dialogs in python-fu and call our script-fu scripts (or vise versa), as Graechan is looking to do. Sounds messy. Either that or modify the script-fu interface to allow more options on the screen.