jontait2 wrote:
@Saul:
What I don't understand is how defines in one user script can affect the operation of other scripts - they're supposed to be independent, aren't they?
There is no distinction/separation between top-level definitions in different files; the result would be the same if all of the .scm files in the scripts directories were merged into one massive file.
One can easily localize any variables or functions, but the procedures that get registered with PDB (e.g., script-fu-images-grid-layout) have to be defined at the top-level.
It is generally a poor idea to define anything but the registered procedure as a top-level, global definition. It is far better to place unregistered procedures within the definition of the main procedure that is using it (as I suggested in my previous post). At a minimum, any "utility" procedures should be named so as to avoid conflict with other functions (certainly globally re-defining a native procedure such as 'round' is not a good idea).
If some utility procedures are needed by more than one global procedure, they can be placed within their own environment, effectively creating "modules" or "packages" which isolate the procedures; but this is typically only beneficial if the file is registering several PDB commands that share some common utility functions (the
Layer FX script would be a good candidate for this approach).