Graechan wrote:
ofnuts wrote:
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.
Actually it was one of your Plug-ins that I wanted to call, 'Random Elipses' and it definately seems different.(python-fu-random-ellipse run-mode image drawable density overlap sizeAvg sizeVar flatAvg flatVar tiltAvg tiltVar)
If it were a Script I'd delete the run mode then place settings I wanted to use in my menu and define block the rest of the settings I'd assign a value in my (let* area.But what do you give for TRUE&FALSE.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
1. 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
2, 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.
1 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.
2 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.