by wallace grrrr
Just did it 10 times, 5 times with each sphere

@Wallace - That error appears to be GIMP 2.8.4 gradient select bug we discussed in the other thread. You're gonna have to update to 2.8.6 (or higher) to fix that. Might as well go with 2.8.10.

@Molly - In which script? What happened? Any errors?

Bevel reflect, no errors

Actually, the default does not get set back to the filename specified in your script-fu-register function, it gets sets to "(None)" -- whereas your specified filename is "none". Maybe this is what you meant but I think it is necessary to be clear on this (perhaps change test.scm to use a more distinct filename).

It is still unclear to me exactly what is going on, but I suspect the offending code appears in script-fu-interface.c. The documentation for GtkFileChooser states that gtk_file_chooser_set_filename() should not be used for non-existent files (instead gtk_file_chooser_set_current_name() should be used). However, the SF-FILENAME specification of Script-fu's script-fu-register procedure does not protect against specifying non-existent files, and I see no special handling for this case.

saulgoode,

When I set the path/filename to null (empty string)
SF-FILENAME _"Select File" ""

It defaults to my home folder /home/gnutux
When I hit reset, it changes to "(none)".

The same thing occurrs when I set it to the following: "beavis.jpg".

SF-FILENAME _"Select File" (string-append gimp-data-directory "/scripts/images/beavis.jpg")
After a reset, it reverts to "(none)".

It seems to me, the proper behavior for a reset would be to set it back to what is specified in SF-FILENAME.

The strange thing is, the error I'm seeing gets generated only when both SF-FILENAME & SF-GRADIENT are in the script (and I click reset). At least for me, that's seems to be the case. I'll attempt to trace though the module you pointed out and look for anything odd. When the reset is clicked, maybe something is being left undefined?

Btw - I do have the latest devel version of GIMP (cloned GIT from a couple of weeks ago) but *I haven't tested this issue on that version yet. I've setup my system to allow me to run 2.8.10 and the latest devel version, side by side, so I can compile any test changes we make and it will not affect the production version of GIMP provided in my distro's repos.

*Tested in the devel version and get the same "String Read" error. Tested the EnviroLogo script on the GIMP devel version, which has both dialogs, and it worked several times. It did finally quit working after several resets and generated the following error at stdout: "EEEEeEeek! 15 GeglBuffers leaked"

I don't know is that Gegl error is related but I thought I'd mention it, nonetheless

Just to clarify on the "(none)" issue. If I set it to anything other than null "" or a valid path/filename, it appears as "(none)" in the Script-Fu Select File browse dialog, which is what it reverts to when the Reset button is clicked. That tells us it's not being reset to null, and it's not being reset to a valid path/filename. It actually suggests that it's undefined, after a Reset. The fact that it shows up as "(none)" after a Reset, means that it could be set to anything (other than null or a valid path/filename).

I tried this again and after running the test filter on a jpeg image for about four or five times the error message started appearing. Hope this helps.

Thank you, Caz, for confirming that I'm not crazy and the problem isn't limited to my machine.

On my box, if I run the test script, click the reset multiple times, then click OK, I get the error every time.

Molly is running Fedora but she cannot duplicate this error. She is running Gnome 3. What you and I have in common, I believe, is that we are both running the MATE desktop. Is that correct?

So far, we have 2 confirmed Linux machines that see this problem, one is Mint 16 (Ubuntu derivative) and the other is Fedora 20 (does it in Fedora 18 too). No Windows boxes, yet..

I inserted some kludge code to display the filename in the progress bar (and pause for a few seconds to offer time to read it).

This code only executes if the error is not raised (of course), however, I noticed that when it was executed, the filename was erroneous: "/home/saul/home/saul". Such erroneous filenames might be the cause of your GEGL buffer errors (depending upon what the script is attempting to do with the filename).

Good idea to display that filename.

The same thing happens on my machine. I'm thinking that on reset, the intent is to set the filename to be the home folder (or null), but for some reason, it's being concatenated with itself. In lieu of it being "reset" to whatever is specified in SF-FILENAME, if it were set to the home folder (or null), everything should be OK, wouldn't you think?

When I set the filename "" to an empty string (null) in Scheme, it displays the home folder. Perhaps on reset, somewhere in GIMP the filename is set to null (which makes it the home folder), then it appends the home folder again, thinking it's being appended to an empty string. That's how it gets doubled. I dunno. It's just a theory, based on what I've seen so far.

Do you think it's worth changing gtk_file_chooser_set_filename() to gtk_file_chooser_set_current_name() to test what happens?

I was under the impression that hitting the reset was the same as "refreshing scripts", except it was just being applied to the current script. Obviously, that's not the case. I guess the code that's executed when a reset occurs needs to be traced to find out what's going on.

Btw - I installed Fedora 20 Gnome3 in a VM and got the same errors there too, so it's not a GTK3 DE issue.

Yeah, I'm running the mate desktop.

I think that testing whether the file exists and choosing the appropriate one of those two functions would be worthwhile pursuing. I chatted with Kevin Cozens on IRC and he will hopefully get a chance to look into this; so I'm going to wait a few days and see what he comes up with (but you may want to pursue a solution on your own, which is fine).

Sounds good, saul. Thanks for all your help in running this one down.

Perhaps I will pursue this further on my own, if for no other reason than to learn something new.