Main menu
User login
Syndicate
You are here
Creating a menu of open images via Script-Fu
I'm attempting to make a script that will combine two images into one image, and I'd like to display a list of open images when the user runs the script. The problem I'm having is that I can't figure out how to keep the menu options updated, because the registration function only runs when the scripts are updated.
For example, if I open 4 images, refresh scripts, close the images, then run my script, I will see the menus showing the 4 images that were open at the time that scripts were refreshed.
Here's my registration function. (list-images) returns a list of image names and (list-blend-modes) returns the list of available blend modes.
(script-fu-register "script-fu-img-merge"
"Image Merge"
"Merges one image on top of another with the specified blend mode."
"Will Morrison"
"GNU General Public License"
"2010"
""
SF-OPTION "Bottom Image" (list-images)
SF-OPTION "Top Image" (list-images)
SF-OPTION "Merge Type" (list-blend-modes)
)
Does anyone know a way around this issue, or am I going to have to go learn how to write plugins if I want to do this sort of thing?
- Log in to post comments
Are you looking for the
Are you looking for the SF-IMAGE parameter type?
Unless I've missed something,
Unless I've missed something, that would give me only the active image. What I'm looking for is a list of all open images when the script is run, which the user can then choose from. Right now I'm using (gimp-image-list) in the registration function, but that is only run when the registration function is, and as a result, I get a list of images that were opened at the time scripts were refreshed, not when the user ran the script.
I've thought of a way around this now, but it's ugly. If I first call a script that refreshes scripts, then runs the function to merge images in interactive mode, it could work, but all the scripts will have their "last used values" erased as far as I can tell, so I don't really want to do that.
Use more than one
Only the first SF-IMAGE is replaced with the active image (and this only if the SF-IMAGE is the first SF-* parameter). Subsequent SF-IMAGE lines in the registration will produce a dropdown list of all open images.
(define (image-foo active-image active-drawable src-image tgt-image) (do-some-stuff dotdotdot) ) (script-fu-register "image-foo" "Foo Images" "Foo a set of three images" "Me" "Me" "Today" "*" SF-IMAGE "Image" 0 SF-DRAWABLE "Drawable" 0 SF-IMAGE "Source Image" 0 SF-IMAGE "Target Image" 0 )Thanks
I wasn't aware of that. This makes things much easier, thanks!
Edit: I've just tried this out, and it appears that if more than one SF-IMAGE parameter type is used, even the first will produce a dropdown menu of available images, but only if no images are open at the time. Am I right in thinking I should file a bug report on this?
IMO, not a bug
I would find such behavior not only acceptable, but desirable; though I haven't really delved into using extra SF-IMAGE arguments much. Is there a particular problem that this behavior causes for your use case? -- aside from the problem of not enough images being (i.e., zero) for your script to function?
If you don't want such a situation to occur, just make sure that you specify that an image must be open for the script to be run. This is specified in the last argument before the SF-* lines. In my example code, the line contains "*" which means that the command would be grayed out (inaccessible) in the menus should no image be open. If you want the command to be available when no image is open then the string should be empty (""). (You can also be more specific by only having the command available for RGB images, or GRAYSCALE, or INDEXED, or images with an Alpha channel or any combination thereof.)
Thanks
Ok, I had developed a workaround involving putting another parameter first, which solved the issue of extra image menus appearing, but your solution of using "*" as the image type is much better. I guess I'm just not so great when it comes to the registration function parameters.
Thanks again. =)