Can a Python Plug-in be called from Script-fu

[Graechan]

Does anyone know or know of an example of how you call a python plug-in from script?

[ofnuts]

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.

[Graechan]

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.

[ofnuts]

0/1 should work.

[GnuTux]

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.

[Graechan]

I've called script-fu's, mathmap and GMIC filters.

Calling a python Plug- in should be fun if not challenging.

[saulgoode]

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

[Graechan]

Ofnuts your random ellipses_0.2 Plug-in is giving these errors whenever I run in 2-6-11

The function works OK but the error codes are a worry.

[paynekj]

Ofnuts your random ellipses_0.2 Plug-in is giving these errors whenever I run in 2-6-11

The function works OK but the error codes are a worry.

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

[Rod]

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,

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.

As was pointed out when Ofnuts originally announced this script, it breaks when run on Windows due to printing excess debug messages:

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

[paynekj]

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.

[ofnuts]

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

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

Code:

#   v0.2: 2011-05-22: Enhance error message to track mysterious '9' bug                                                               


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

[ofnuts]

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/

[GnuTux]

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

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.

There is no need to specify the 'run mod' 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.

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?

[saulgoode]

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.

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.

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?

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

[GnuTux]

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.

[Graechan]

This worked fine in windows.

(python-fu-random-ellipse RUN-NONINTERACTIVE image bkg-layer 50 1 50 5 50 5 45 5)

All I need is to replace the numeric values I want to make variable with a string and enter in my menu.