Sent: 2010-09-05 11:42:05 UTC (over 1 year ago)

From: Alan Campbell

script-fu: saving dialog choices

permalink

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.

In most other scripting languages I'd save choices to somethng like
an ini file, and retrieve stored ini file values before displaying
dialog.

Hmm. Ok, a few problems:

(a) How to run code before dialog displays. I tried this at top
level (i.e. not enclosed within any procedure:

(load "F:\\test.scm")

where test.scm contained

(define WRF_BIT_WIDTH_SETTINGS '(17 0 256 0.1 1 1 1)) ;

and script-fu-register dialog def included

SF-ADJUSTMENT "bit width:" WRF_BIT_WIDTH_SETTINGS

That seemed to work. (Now I've just got to figure out how to write
out valid define statements to test.scm and I'm partly there. Looks
like a combination of calls to write-char and write obj may do.)

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.

Any thoughts as to why?

Another approach I tried was to begin declaration of dialog

(script-fu-register WRF_DIALOG_FUNCTION
(wrf_test_text) ;menu label
"Create a Finger Template for Woodrat" ;description
.....
SF-ADJUSTMENT "bit width:" WRF_BIT_WIDTH_SETTINGS

where (wrf_test_text) is

(define (wrf_test_text)
(set! WRF_BIT_WIDTH_SETTINGS '(17 0 256 0.1 1 1 1))
.....
"Finger..." ; return value
)

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.

===============================

(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?

Thanks for any help.

Yrs,

Alan

It costs me never a stab nor squirm,
To tread by chance upon a worm.
Aha, my little dear, I say,
Your clan will pay me back one day.

-- Dorothy Parker

===================== +++++ =====================

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Sent: 2010-09-05 15:44:19 UTC (over 1 year ago)

From: saulgoode@flashingtwelve.brickfilms.com

script-fu: saving dialog choices

permalink

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.

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Sent: 2010-09-10 13:35:54 UTC (over 1 year ago)

From: Alan Campbell

script-fu: saving dialog choices

permalink

Hi Saul,

Many thanks for instant help.

> > I'm trying to figure ut if there's any way that choices made by
> > 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.

Sorry, I mis-stated my problem. I'd like dialog to come up with same
widget values next time GIMP is started up.

...(snip)...

> 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:

Thanks, I think it I read that bit in the Scheme manual and forgot
it.

...(snip)...

> 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.

Sorry, mis-stated by requirement.

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?

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

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

Yrs,

Alan

Public speaking is very easy.

-- Vice President Dan Quayle
to reporters in 10/88

===================== +++++ =====================

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Sent: 2010-09-10 15:36:06 UTC (over 1 year ago)

From: Rob Antonishen

Fwd: script-fu: saving dialog choices

permalink

>
> 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>

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Sent: 2010-09-10 19:39:57 UTC (over 1 year ago)

From: saulgoode@flashingtwelve.brickfilms.com

script-fu: saving dialog choices

permalink

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.

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Sent: 2010-09-11 17:54:48 UTC (over 1 year ago)

From: Alan Campbell

script-fu: saving dialog choices

permalink

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

Ta for reply.

> use the
>
> 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?

Yrs,

Alan

No one is listening until
you make a mistake.

===================== +++++ =====================

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Sent: 2010-09-11 21:26:04 UTC (over 1 year ago)

From: Sven Neumann

script-fu: saving dialog choices

permalink

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

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Sent: 2010-09-12 05:48:12 UTC (over 1 year ago)

From: Alan Campbell

script-fu: saving dialog choices

permalink

On Sat, 2010-09-11 at 16:53 +0000, Alan Campbell wrote:
> On 11 Sep 2010 at 12:26, Sven Neumann wrote:
> >

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

Works, ta.

> That's really an abuse of the gimprc though.

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

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

> 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?

Yrs,

Alan

Sometimes I wonder if men and women really
suit each other. Perhaps they should live
next door and just visit now and then.

-- Katharine Hepburn

===================== +++++ =====================

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

Sent: 2010-09-12 15:37:48 UTC (over 1 year ago)

From: saulgoode@flashingtwelve.brickfilms.com

script-fu: saving dialog choices

permalink

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.

_______________________________________________
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user