Re: [Gimp-developer] Script baffling
Thanks very much folks. I discovered this by accident when I couldn't figure out why the gimp-hue-saturation wasn't working, and I wasn't sure why moving that fixed it, just that it did. I just wish I knew scheme better, but this kind of getting my fingernails dirty is sure helping! Again, thanks for the very helpful help! On Thu, Feb 24, 2011 at 11:44 PM, wrote: > Quoting Kevin Cozens : > > > Roger Penn wrote: > >> The included script worked just fine before upgrading from 2.2 to 2.6. > I've > > [snip] > >> (define (BulletinBoard_Blue_Header inText inFilename) > >> (let* ( > >> (drawable -1) > >> (text inText) > >> (filename inFilename) > >> (gimp-context-set-foreground '(41 11 169)) > >> (img (car (gimp-file-load 1 > >> "C:\\userfiles\\admin\\images\\GIMP\\bulletin.gif" "bulletin.gif"))) > >> (gimp-image-convert-rgb img) > > > > Your script is calling "gimp-image-convert-rgb" in the variable bindings > > part of the let*. It needs to be in the body of the let*. Move the line > to > > just before or after the call to "gimp-selection-none". > > I would add that likewise the script is attempting to call > 'gimp-context-set-foreground', 'gimp-hue-saturation' and > (conditionally) 'gimp-layer-scale' within the binding block. The > actual effect of this is that new, local variables are created and > assigned the values of the ensuing expressions. The line that attempts > to conditionally call 'gimp-layer-scale' is particularly problematic > because it is redefining "if" (though only for the duration of the > let*). > > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Fri, Feb 25, 2011 at 1:30 AM, Bogdan Szczurek wrote: > And let me throw in another thing. It's been in my head for some time > but now I think it's good to show it to the world. Just in the matter > of shear curiosity: I'd like to see some conceptual work/code/working > example/whatever about automatically configurable grid processing. It > may be more of GEGL project than GIMP one, but I believe still > beneficial in the end. Since 3D rendering engines do that, maybe it > would work nice in 2D world too. Of course a metric and some kind of > benchmark would be needed to decide if sending some part of work over > network to another node is beneficial. Anyway I think it have chances > to make things snappy even on slow machines. I see it as a something > between freakin' fat workstations, thin clients with some heavy “mother > goose” and mighty cluster. It would (hopefully ;)) help to use what is > at hand more optimally. GEGL is designed to be able to split up the rendering requests from the public part of it's API internally and to distribute it among threads/processes/hosts without needing changes to the application using GEGL. At the moment there is only experimental support for using threads in this fashion, but the architecture has been made with distributed processing in mind. This also applies to the GeglBuffers for which there a few years ago already was done experiments with doing multi process/user concurrent manipulation of the same buffers. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
