Quoting Alan Campbell :

Hi,

I'm trying to figure ut if there's any way that choices made by a user in dialog widgets can be remembered and used as values of those widgets next time dialog runs.

That is precisely how script dialogs currently behave; the last used values are presented. These last values will be reset to their original default values if 1) Script-fu is refreshed ("Filters->Script-fu->Refresh Scripts") or 2) GIMP is restarted.

BUT: if loaded scm contains

(define WRF_BIT_WIDTH 17)

and script-fu-register dialog def includes:

SF-ADJUSTMENT "bit width:" '(WRF_BIT_WIDTH 0 256 0.1 1 1 1)

the value of WRF_BIT_WIDTH loaeded from test.scm doesn't seem to take.

Tick quoting does not result in evaluation of the list elements. Use 'list' so that WRF_BIT_WIDTH gets evaluated and replaced by its numeric value:

SF-ADJUSTMENT "bit width:" (list WRF_BIT_WIDTH 0 256 0.1 1 1 1)

Another approach I tried was to begin declaration of dialog

(script-fu-register WRF_DIALOG_FUNCTION (wrf_test_text) ;menu label
:
:
which also seemed to work; in principle I could write code for (wrf_test_text) that interrogated an ini file, retrieved values, constructed correct lists, initialised variables used in later parameters of script-fu-register. Rather round-the-houses, but works.

Keep in mind that the arguments of 'script-fu-register' only get evaluated when the script is registered -- they are not (re-)evaluated when the script is executed. While your code works, you have not really gained anything other than moving the definitions to a different location within the .scm file.

(b) But: to make this work I need to be able to determine if a file exists (error if try to load file that doesn't) and to be well- behaved, be able to specify a particular folder in which to look for ini files (same folder as running script? GIMP install folder? GIMP share\gimp\2.0\..?). Any way to test for file existence or determine script folder/install folder in script-fu?

It is unclear to me what exactly you mean by "to make this work" because within a GIMP session, the values set in script dialogs are indeed retained and used the next time the script is executed.

If you are wishing to have the values derived at the time the script is run (i.e., calculated before the dialog is presented), this is not readily accomplished. For example, you can't have a size parameter default to the run-time width of the image being filtered -- the initial size default would be evaluated at registration time, and for subsequent executions the previous value entered by the user would be used.

If, however, the issue you are attempting to address is having the last values retained across sessions (or survive a Script Refresh), this would be possible by storing your script's last values in the /parasiterc file:

(define (script-fu-woodrat image drawable bit-width) ; Substitute function owing to buggy parasite-attach behavior (define (fu-parasite-attach parasite) (gimp-parasite-attach parasite) (while (not (string=? (caddr parasite) (caddar (gimp-parasite-find (car parasite))))) (gimp-parasite-attach parasite)))

; Save the user-specified bit-width to an application parasite (fu-parasite-attach (list "WRF_BIT_WIDTH" 1 (number->string bit-width))) ...
)

(script-fu-register "script-fu-woodrat" :
:
:
SF-IMAGE ...
SF-DRAWABLE ...
SF-VALUE "Bit width"
(catch
17 ; fallback value if first-time run (string->number (caddar (gimp-parasite-find "WRF_BIT_WIDTH"))) )

Note that 'gimp-parasite-find' is only executed once: when GIMP is initially loaded (or if scripts are refreshed). Even though the parasite is saved every time the script is executed, it is actually GIMP's internally stored last value (not the parasite) that is used in determining the value for the 'bit-width' parameter. The only reason you'd want to take these steps is to support last values across different sessions. The behavior you desired (as expressed in the first paragraph of your post) is already supported by GIMP.

Generally: do all the gimp-*-parasite-attach methods suffer from same bug, so should be reapplied til they work?

Yep.

use the

https://bugzilla.gnome.org/show_bug.cgi?id=572865 https://bugzilla.gnome.org/show_bug.cgi?id=624555 https://bugzilla.gnome.org/show_bug.cgi?id=624567

(last 2 marked as duplicates)

I beleive there is a proposed patch though.

Instead of parasites consider using gimp_gimprc_set() and gimp_gimprc_query() which don't seem to have this issue.

-Rob A>

Quoting Alan Campbell :

parasites are just what I need. Can't find much about them.

(list "WRF_BIT_WIDTH" 1 (number->string bit-width)))

First list member: parasite ID string.

What's the second list member? Flags, I understand from one search result I found. Used?

To my knowledge, the FLAGS parameter controls 1) whether the parasite is persistent across sessions, and 2) whether adding the parasite is an UNDOable operation. 1) is controlled by the least significant bit of FLAGS, while 2) is controlled by the second bit.

This results in four possible settings:

0 - Not persistent and not UNDOable 1 - Persistent and not UNDOable
2 - Not persistent and UNDOable
3 - Persistent and UNDOable

Third list member: parasite value (must always be a string). So an RGB colour value would have to be stringified. unstrbreakup maybe?

That would work.

(set! color (car (gimp-context-get-foreground))) ; as an example (set! str (unbreakupstr (map number->string color) " ")) :
:
(set! color (map string->number (strbreakup str " ")))

Generally: do all the gimp-*-parasite-attach methods suffer from same bug, so should be reapplied til they work?

I believe so. Yes.

On Sat, 2010-09-11 at 16:53 +0000, Alan Campbell wrote:

On 10 Sep 2010 at 9:35, Rob Antonishen wrote:

https://bugzilla.gnome.org/show_bug.cgi?id=572865

Thanks, got that working.

Instead of parasites consider using gimp_gimprc_set() and gimp_gimprc_query() which don't seem to have this issue.

In Script-fu console

(gimp_gimprc_set "xxx" "yyyy") on my win 2.6.10 installation gives

Error: eval: unbound variable: gimp_gimprc_set

Did I miss something?

In Script-Fu it's "gimp-gimprc-set".

That's really an abuse of the gimprc though. It would be much better to get the parasites problem fixed.

Sven

Quoting Alan Campbell :

That's really an abuse of the gimprc though.

So it's really only meant for GIMP and GIMP plugin settings?

I agree with Sven that using gimprc for this purpose is inappropriate.

Also it looks like once I've called gimp-gimprc-set, no way to remove expunge evil deed from the gimprc file?

Correct. it would be quite a task to remove your script-generated settings from the gimprc while retaining the user's configuration choices (as well as the script-generated settings of other scripts, assuming they likewise employed gimprc).

In addition, storing script data in gimprc would somewhat "break" the documentation for gimprc. While a few scripts adding settings to gimprc would be acceptable (which is why those PDB functions are exposed), if this became convention then gimprc might soon become cluttered with undocumented settings.

But the worst aspect of scripts saving data in gimprc is that the gimp-gimprc-set function interacts with the file every time it is invoked (whereas the parasiterc file is only rewritten upon GIMP exit). It is not really a good idea to have a script reading, parsing, and writing back a file each time it is executed -- doing so makes your script dependent upon file system speeds (it is also conceivable in theory that your script will be iteratively executed hundreds of times in rapid succession). It is far better conceptually to manipulate such data in memory, and saving the data only upon exit.

It would be much better to get the parasites problem fixed.

Sure. I'm not in no hurry. Lots more wrok to do on my woodrat scripts. Any guess re timescale?

Keep in mind that even should the bug be fixed today, if you are sharing your script with others then you will want it to work with versions of GIMP which are in current use. Thus I would recommend using the work-around previously provided (if your script isn't intended for general distribution, you needn't worry about this). It would probably be a year or two before you could reasonably expect that most users would have updated to a fixed version.