GNOME Bugzilla – Bug 588755
Port pattern generation scripts to work on the current image
Last modified: 2010-01-15 20:50:13 UTC
In order to make the scripts under File -> Create -> Pattern more generic, they should be ported to work on the current image and moved menu-wise to Filters -> Render -> Pattern. For example, instead of having File -> Create -> Patterns -> Camouflage... creating a 256x256 image and filling it with a camouflage pattern, it shall be moved to Filters -> Render -> Pattern -> Camouflage and fill the current image with this pattern. Before we can close this bug report, all scripts needs to have been ported. This is a merge of bug #145145 and bug #145146.
Setting milestone to 2.8 for now. Unless someone fixes this rather soon I suggest we close this bug report as WONTFIX and instead focuses on porting these pattern generators to GEGL.
Hello, If I understand right, all we want to do is to add the option to generate these patterns in the current image on the active/new layer? If this is all that needs to be done, I'll be happy to do so. There are 2 issues to be considered: 1. These pattern scripts (swirly, camoflouge, any other scripts?) generate a new image with a custom size so generating them on the active layer will make them look distorted. I suggest that a new layer will be created by the script. 2. At least in the camofloge script, the user has the option of flattening al the layers of the patterns, or keep them seperate. We do want to flatten the layers if it's not on a new image, right? As soon as we decide on the two issues above, I'll start working on it.
p.s. I have no idea how to write a GEGL plugin (or how GEGL works), however if it is possible to port these to GEGL (and someone has the time to do so), I do believe it would be a better option.
The idea of this bug report was that the size of the pattern is determined by the layer/drawable that you invoke the script on. Creating a new layer is not an option, then we can as well leave the scripts as is and let them create a new image.
OK, In that case I'll create the patterns on the current layer. I'l work on it :)
I started working on it, and I have two questions: 1. do we also want to port the other pattern scripts? (Truchet, land, etc.) 2. should I remove the File->Create->Pattern Entry and keep only the Filters->Render->Pattern, or should I keep both?
1. Yes, all pattern scripts 2. Pattern Entry? Where is that?
2. I meant, do we want to keep the pattern scripts in the "File->Create->Pattern" menu, or do we want to get rid of this menu?
It will be empty, so we'll remove it. We need to remap <Image>/File/Create/Patterns to some other place though I guess.
The core part of the pattern generation scripts can be extracted to a separate function so the scripts can be used both with and without an existing image. If you don't want menu entries for the pattern scripts in two places, only one set of menu registration calls can be used. The naming structure for the new functions that act on an existing image will need to be chosen. We shouldn't remove the ability to call the pattern scripts without an image as that would constitute a form of API change.
Hello Kevin, As you suggested, I already extracted the core to a seperate function, and removed the menu registration call for the original scripts. How do we want to name the new functions? I suggest script-fu-render-pattern-XXX in order to start getting a more standard naming for scripts. See https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-August/023093.html which explains why this should be the new name.
p.s. Martin, I thought about what I asked again and I was wrong. What if some users have scripts which register to file/create/pattern? Then their scripts will be move to filters/render/pattern while they originally in the right place... We should probably keep this menu if possible, and simply hide it when it's empty.
We don't need to keep the menu. If a third-party script actually registers there, then it will be created. What Martin suggested was to remap the menu location. But I don't think that's a good idea in this case.
Whil fixing the script swirly pattern, I saw that it would be practically impossible (making all the loops manual - about 70+ lines of super messy code) to apply it on a layer unless it's dimensions (both width and height) are divisible by 4. In some of the other patterns, there are similar size problems. Is it ok to create the pattern on a different layer and then simply paste it? If not, it would mean that we will have to resize the drawable on which this script is working (and the user won't want that).
If a script is hard to convert, don't bother with it. We should rather convert it to GEGL at some point.
OK, I won't convert the impossible ones. Can you please point me to where can I find how to write a gegl action for GIMP (I will use it to substitute the script)? Or instead, can you show me where in GIMP's source code we have the gegl actions? (I'll read it and understand from there). I haven't managed to find anything under http://git.gnome.org/cgit/gimp/tree/app/gegl (for example, where is the gegl perlin action that we have in GIMP?)
Oh, porting them to GEGL is a future project that can be done when GEGL is actually useful in GIMP. Anyway, some operations: http://git.gnome.org/cgit/gegl/tree/operations/common/perlin/perlin.c http://git.gnome.org/cgit/gimp/tree/app/gegl/gimpoperationcolorbalance.c http://git.gnome.org/cgit/gegl/tree/operations/common/invert.c
No progress here, closing as WONTFIX as I originally proposed. We'll inevitably revisit this topic when we begin integrating GEGL for real and looks at new APIs etc.