I am wanting to take RobA's multifill script, and add a patterns option instead of just either random colors or palette colors.

The purpose of this script would be to replace selections randomly with patterns (the primary project in mind is stained glass window patterns).

I'm looking at this portion of the script to determine what changes I would need to make in order to add a new set of patterns options:


This is how the code is currently written, but I'm thinking I need to add an "if" flag for when the (palettes) option is true.

1. Is it crucial to set a statement for the other options to be false, in order for the new pattern option to be true, or is simply adding another (begin (if (= inPatterns TRUE) sufficient? My thoughts are, I wouldn't want the user to be able to make 2 or 3 options to be true at the same time. Something to flag the user that they cannot use more than one option at a time.

2. Could I continue using (nextcolour) in the same fashion with patterns as it is used in palettes and random colors, or would I need to make a new definition? (My gut says a new definition to assign patterns randomly is needed)

3. I am aware of (palettecount) so I would also need to establish a (patterncount).

4. I'm totally lost on how I would assign the script to look for a subset folder of patterns, and not the .gimp-2.6/patterns folder. I would want the ability to assign this value on the script menu, as the folder location could change for a different project.

A menu to elaborate my intentions:

That would be a cool Script-fu if you could get it to work Mahvin. Wish I could help, but I never Script-fu and the few that I modified were simplistic little things. Might have to get RobA's help again on this one. I would be interested in it though; like the stained glass idea.

Me too.

Have you looked into snatching some code from the LayerFX script?
I mentioned this in the other thread too.(stained glass)

Script-fu's dialog interface does not support the concept of "radio buttons" (where only one of a group of options can be chosen). The best alternative, in my opinion, is to use the SF-OPTION widget to provide a drop-down list.


Codewise, you will probably want to use Scheme's 'cond' statement, rather than nested 'if's.


Better to treat pattern filling as a separate "fill mode", for this is what is really being done (see code below). But basically you are correct that pattern filling is little different from filling with a solid color.


Correct. In the code below, I use a 'palettecount' variable to index into a list of all the .pat files in the specified directory. (Note: I did not attempt to randomly select patterns from the pattern directory. If you wish to provide support for such randomization, I would be glad to assist.)


When registering your script (script-fu-register), include an SF-DIRNAME widget.



Kudos on putting so much effort into describing your expectations -- and even providing a mockup of the desired dialog (instead of merely writing down a few thousand millipictures). Clearly understanding what software is supposed to accomplish is the first step in writing the code -- and for me is the most challenging part. The time you've put into requesting help makes it much easier for those who would provide it to do so (this is true not just for coding requests, but for reporting bugs -- or seeking help in general). I would say, however, that it would have been nice had you provided a link to the location of the original script.

Since your goal seems to be learning more about scripting (and since I did not write the original script), I submit the following code fragment to demonstrate how I would approach adding such a feature. I have not tested the code (or even modified the script to attempt so). I leave it to you to incorporate the appropriate changes to your version of RobA's script (remember to add the SF-DIRNAME and SF-OPTION widgets as previously mentioned).

(Note: I did not use RobA's 'listeq?' function since the same thing can be accomplished with Scheme's 'equal?' procedure.)

Add the following variables to your 'let*' bindings:

The following code (or somesuch) should be substituted into the appropriate location of the original script. EDIT: this code will definitely not work. One cannot set the current active pattern based on the pattern's filename (which the file-glob provides). We will have to either extract the pattern's name from the file, or load the pattern file as an image, copy it to the clipboard, and fill using the clipboard as pattern. The second approach is probably better since it doesn't depend upon the pattern being in GIMP's path for pattern directories.

Why only the .pat files ?
Gimp may use also pattern in jpg, png,and gif(not sure about tif)

on the other hand i didn't see in the script any limitation to the pat format (maybe there is but i just didn't notice )

The following code will assign a list of pattern names to a variable 'patterns'. It is not very robust (it doesn't check for non-existent files and could stall if the file is corrupt or not a pattern), but it should be sufficient for initial experimentation. Of course, the pattern file must be in GIMP's search path for patterns in order that 'gimp-context-set-pattern' will be able to specify it as the current active pattern.

The flatting and multi-fill tool is located at the registry here (I love this script by the way, a comic panel artist's best friend!):

http://registry.gimp.org/node/14051

I stay up too late sometimes, and the mind gets fuzzy.

Thanks for the heads up, Saulgoode, I'll will definitely play around with this code a bit to see how much damage I can do.

Oh wow, I'm not going to kid myself here, this is way over my head. I will definitely need your help, Saulgoode. I need to be able to break this down so that I can at least understand why I am setting up or using code in this form. It's a daunting task and a lot for me to ask of you, but the scheme tutorials online are limited to simple tasks and automation. Are there more intermediate level tutorials somewhere online that takes you into this area of scheme? My search results usually land on the "hello world" variety, and that's too much milk for someone needing a little more solid food.

Some script-fu guru should write a book, I know they'll make a fortune.

So, simply adding an additional path in Edit - Preferences for patterns search would resolve this? I have a small problem with this for other people using this script, requiring them to take additional steps might cause confusion. Is there a more global method to use a script to set that step? Not sure if I am asking in the right way, but I am curious if a script could actually set preferences?

Maybe i didn't understand well...I don't see much a problem here

Just in case the user find too hard create a new path he may anyway use 1 of the 2 default paths,( the first for pattern included by default and the second for the patterns (maybe) added in his gimp user directory)

then the user remain free to create new paths in preference as suggested

but if he doesn't that 2 paths always exist and more important the first always contain something so maybe the first path in preference may be used as default

to the user the possibility to make a more advanced use of the script , creating new folder(s) for patterns
and link them from Preferences... if doesn't his possibilty to chose will be limited to the default paths, but the script will work, maybe not at his best but without errors

PC:

I've learned the hard way that problems come easy to people in the simplest of ways. For instance, if the script remains dormant (unused) for a period of time and the user returns to use it again, having made changes since the last time they used it, it could be problematic. For me and you, and others of our mindset, maybe not so much, but a fresh out of the box noob, perhaps more so. I'd want flags to prompt the user if something needs to be done, like a reminder to set up a pointer to a pattern folder. This is just to prevent an error from scaring the user into thinking the script is broken and avoiding all that "blah blah blah" your script doesn't work" scenarios.

I found this, for starters: http://community.schemewiki.org/?scheme-style

Plus, I clicked your cond link above (that information seems to be geared to those who already know scheme, in advanced)

I applied all your recommendations, and got it to register, but I see a conflict between the ability to select your directory and declaring a directory name (at least I think it's a conflict).

I also get this error when attempting to use patterns:



EDIT: Fixed this by putting the palette back in. Heh!

Mahvin
i really don't know script fu, i just try to use lateral thinking, but i fear i may wrote some nonsense



i was following what Saulgoode said, the path for the pattern should be in the gimp preference:

So the first path for pattern in the gimp preference will be always the same ,will never give errors because there are all the default pattern so may be declared as default
but if the user prefer may declare something else.

Only problem i may image is that the default path is different in Windows and in Linux
(at least the absolute paths...maybe the relative paths are not different, not sure here )

but this is a problem only if the path should be written by the user...if could be chosen from the list of the paths in in Preferences/folder/pattern then will be no problem

But i don't know if a gimp script may access to that list

I don't know if it can access a list, either. But saulgoode did offer to help with randomization of patterns.

Right now the script is telling me: Error: eval: unbound variable: inPatternDirectory with all his recommendations implemented. Menu pops ok, everything looks good til you try to run any option, doesn't matter which option you choose, same error.

ah
i fear i can't help for that but if you post the script as it is now...well more chances to get help
(hem...i am very tempted to make blind guess but i try to resist to the tentation..)

The coder? Hahaha... I already admitted I was in over my head, I'm just remaining determined.

And no, I didn't take offense to your earlier comment. I was trying to sort out any possible confusion before it even exists. I have Project Manager mentality. :gah!

Saulgoode used string-append:

(patterns (cadr (file-glob (string-append inPatternDirectory DIR-SEPARATOR "*.pat"))))

I got to thinking maybe it needs to be defined. When I add it to define, it then declares the new error:

Error while executing script_fu_MultiFill:

Error: string-append: argument 1 must be: string (so I think by adding it to the define list, broke the string). I have no idea how to define, so I am searching for similar scripts.

The 'inPatternDirectory' variable needs to be added as a parameter to the main 'script_fu_MultiFill' definition such that it is associated with the corresponding widget (SF-DIRNAME) created in the registration procedure.

When I do that, it gives the string error I mentioned above.