I haven't seen this posted before, so here it is.

My initial tests using the gimp-context-get-<parameter> functions to to set the Script-fu inputs looked good and very easy.

Unfortunately, the values were the active ones when GIMP started or when the scripts were refreshed. They did not reflect the current state.

So here is a revised process, and it is more work. But the default values will be the currently active ones.

Use null strings for the names in the user interface section:


In the body of the script, set the new values before you use them - but only if they have changed!

The variable names brush font palette pattern gradient should be whatever you called those entries in the script declaration.

The font entry is a special case. All of the others are used through calls that use the currently active <whatever>. But the font name is needed for the text procedures so you need to set the variable to the currently active name if the input name is <null>.

Tested in GIMP 2.6.11

I hope this helps you.

I've revised (radically changed) the process. My testing wasn't as thorough as it should have been.

What would greatly help is if there was a way to protect DEFAULT resources so they can not be moved or deleted.
That would definitely benefit script writers that rely on default files for their scripts or filters to function correctly.

This is quite clever. I might suggest that instead of using the null string, one might use "Currently active gradient" or such to make it more clear to the user; and then instead of testing for string-length, using string=?.

Also, it might be beneficial to create "dummy" patterns/palettes/gradients/etc -- appropriately named (e.g., "Currently active gradient") -- so that the user has the option to revert to that choice after selecting an alternative. Note that merely clicking the selector button will force an actual existing resource to be selected and there is no way to "reset" the input to the null string once this has occurred. By providing resources with the appropriate name, their name will appear in the selector dialog (though with the incorrect corresponding thumbnail icons).

For patterns, brushes, gradients, and palettes, it is possible to include Script-fu code that will create such dummy resources; however, it is not readily possible to create a new font from within Script-fu (I will investigate the feasibility of doing this) so it may very well be necessary to create a suitably named font outside of GIMP (ugh).

The advantage of using the null string is that the script's input window shows the correct current values for all of the entries -- except it doesn't show the font name.



My first attempt at this was very simple. Just use the gimp-context-get-<name> functions to set the defaults. This provided real names for all of the values and no additional code was needed to use the values.



Unfortunately, those values were evaluated when the scripts were initialize (at start-up) and did not reflect the current values when the script was actually run. That was better than a hard-coded value; but not necessarily the correct value.


Fonts, brushes and patterns are widely available and many people customize their collections.

I have done this, especially with the brush and patterns. I didn't like the names of the default brushes so I replaced them with a set that was more appropriately named and got rid of the brushes I never used. Likewise, I replaced many of the default patterns with better patterns, or at least changed the pattern name to more accurately reflect the pattern's contents. But I also saved all the defaults so I could retrieve them when a script had a brush or pattern name hard-coded in.

Oh, I did not catch that. I only played around with SF-FONT (which displays an empty button). There is still the limitation (with null string) of not being able to go back to the currently active resource (without explicitly choosing it in the resource dialog) but I can certainly see the desirability of your approach.

The Reset button in the dialog returns the values to the null string.

Filters > Reset all filters does not reset the inputs.

Yes, I'd noticed that before as well, though the command does work with plug-ins. It is unfortunate that the command does not work with scripts.