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.