Add function to load scheme libraries by traversing Gimp paths
Use case
You have a library of functions in Scheme. The functions could be shared among other script plugins or the SF Console.
Example: share a test framework among many test scripts.
Now
You have these choices:
-
Cut and paste the source into each script file.
Poor because hard to maintain.
-
Put them in a script file that registers each function in the PDB as a procedure without menu items.
Poor because of the script-fu-register boilerplate and the overhead of PDB calls.
-
Call the built-in Scheme function '(load "C:/Users/joe/my library.scm")'.
Poor because the path and filename are platform dependent.
-
Put the library in a .scm file in /scripts. An example is /scripts/script-fu-utils.scm, which defines e.g. the function 'with-files'.
Poor because it is only seen by extension-script-fu and the Console, not by stand-alone script-fu-interpreter (which doesn't now load /scripts/*.scm)
Poor because every script plugin in /scripts/*.scm sees the library, even if not used, and increases potential for name clash.
Enhancement
Add a ScriptFu function: (script-fu-load "filebasename.init")
This is like item 3 above, the built-in '(load fooPath)' but it only takes a filename, not a path. It searches for the filename in the paths that GIMP knows for script locations (user specific /scripts and installed GIMP /scripts.) It searches for a file having the name and suffix you give.
Implementation
This can be implemented in C files implementing ScriptFu or in Scheme.
In Scheme use (gimp-gimprc-get "script-fu-path)) and then map (load "fooFileName") over the path list. Putting the function in /scripts/script-fu.init, which is loaded by all ScriptFu tools.
Suffix
Library authors are responsible for using a suffix that hides the file. Suffix .scm is generally wrong, since extension-script-fu etc. would load it anyway, obviating the need to call script-fu-load.
Suffix .init is similar to what ScriptFu uses to find the two scripts that initialize the interpreter (explicitly loading by name: script-fu.init and script-fu-compat.init.)
Installation of libraries
For Gimp plugins
When any script plugins in the Gimp repo use this feature (now, none) they can install their library file(s) using similar names.
For example, the main function in contact-sheet.scm could call (script-fu-load "contact-sheet.init")
For third party plugins
Similarly, the install instructions for a third-party plugin using this feature would say:
Install both foo.scm and foo.init to ~/.config/GIMP/2.99/scripts
Or for a plugin interpreted by the standalone interpreter:
Install foo.scm in a subdirectory ~/.config/GIMP/2.99/plugins/foo AND install foo.init to ~/.config/GIMP/2.99/scripts
An alternative
One alternative might be special directories that all ScriptFu tools load automatically e.g.
~/.config/.../scripts/lib
and /usr/lib/GIMP/.../scripts/lib.
ScriptFu tools would load every text file in those directories, regardless of name and suffix. When loading, tools would disable registering of plugins i.e. calls to(script-fu-register ...). script-fu-util.scm would be moved there. This alternative would add one more step to the initialization of ScriptFu tools: load all files in the special directory.
Currently:
- extension-script-fu loads all files with .scm suffix in /scripts, but enables registering.
- SF Console loads all files with .scm suffix in /scripts, but disables registering.
- But script-fu-interpreter does not load the /scripts directory and catches no files as libraries.
(1) and (2) happen to catch script-fu-util.scm as a library, seen by: all /scripts/*.scm plugins (served by extension-script-fu), by the Console, Server, Eval and TextConsole.
Other considerations
Versioning
A shared library creates a dependency relationship between scripts that use it. Changing a shared library's API may require updating all scripts that use it.
Name clash
When you load a script, you can unwittingly redefine a symbol, causing unexpected behavior. The first proposal reduces that risk, because scripts explicitly load only the scripts they need.
Lisp/Scheme convention
There could well be a convention in the community for the name and location of Scheme libraries, that this enhancement should follow.
Security
The enhancement adds no new security concerns i.e. attack surfaces. Gimp's script directories are already secured by sandboxing in flatpak or by usual OS file permissions.