Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Sun, Feb 08, 2004 at 07:35:08PM -0800, Manish Singh [EMAIL PROTECTED] wrote: currently, and go beyond that with a full gtk and gimp binding. The same should be done for python (I have plans to do this) and perl, the idea being having languages besides C that can use the entire gimp API. Hmm, at least during the 1.2 era, perl did have access to the full API (i.e. low-level pixel access, full UI transparency etc.), and right now I don't think something important has been added that is not accessible (as opposed to parts that haven't been converted to the new API). I mean, in the sense of you can write plug-ins indistinguishable from plug-ins wirtten in C, this was possible in perl for a long time already. However, very few authors have used these features, and only two perl plug-ins, both written by me, use their own Gtk-UI instead of relying on Gimp::Fu, so I guess the demand for the latter power in perl is pretty low. (I might err and there are lots out there, perl developers have this tendency of doing stuff for themselves without polishing publishing them...) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 08:35:04AM +0100, Marc A. Lehmann wrote: On Sun, Feb 08, 2004 at 07:35:08PM -0800, Manish Singh [EMAIL PROTECTED] wrote: currently, and go beyond that with a full gtk and gimp binding. The same should be done for python (I have plans to do this) and perl, the idea being having languages besides C that can use the entire gimp API. Hmm, at least during the 1.2 era, perl did have access to the full API (i.e. low-level pixel access, full UI transparency etc.), and right now I don't think something important has been added that is not accessible (as opposed to parts that haven't been converted to the new API). I mean, in the sense of you can write plug-ins indistinguishable from plug-ins wirtten in C, this was possible in perl for a long time already. However, very few authors have used these features, and only two perl plug-ins, both written by me, use their own Gtk-UI instead of relying on Gimp::Fu, so I guess the demand for the latter power in perl is pretty low. (I might err and there are lots out there, perl developers have this tendency of doing stuff for themselves without polishing publishing them...) Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb. I'd like to see more bindings that let you do everything a C plugin does, so people have language choice when it comes to writing things, which could mean a larger pool of plugin coders. It's also nice to have a quick way of trying out new algorithms. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Manish Singh [EMAIL PROTECTED] writes: Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb. We will have to make the libgimp APIs more language binding friendly then. If we made more use of GObject properties, that would probably help. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 11:58:15AM +0100, Sven Neumann wrote: Hi, Manish Singh [EMAIL PROTECTED] writes: Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb. We will have to make the libgimp APIs more language binding friendly then. If we made more use of GObject properties, that would probably help. Yeah, there's a bit of work to be done on the libgimp* side too. Not a whole lot though, and certainly doable for 2.2. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 12:53:40AM -0800, Manish Singh [EMAIL PROTECTED] wrote: Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb. Ah yes, I haven't looked into the new stuff... [hints for implementors, after looking into a slightly older 2.0 snapshot that I have on my disk:] Most of libgimpcolor and libgimpmath is available in other perl modules (using them directly would be rather slow in perl, using pdl is faster, although the results might be subtly dfferent, of course. Wrapping these into PDL interfaces would be best). The way to wrap the remaining libgimpwidgets is to make them into real gtk2 widgets with properties and signals. The way it is now, every language interface has to reimplement the api, if they were written in the same way as other libgtk2 widgets it would be as simple as calling the register function and have everything available without extra C code. (as I understand, at least the python gtk2 interface is working very similar and would benefit automatically from this). libgimpthumb would probably just need a few init calls to be called on module init, although the design of combining an initialisation function with setting parameters (gimp_thumb_init) might not have been the wisest choice, but this could be handled in perl using use Gimp:Thumb (MyApp /basedir), athough it's not clear how to handle multiple users of Gimp::Thumb. Everything else is nicely wrapped into gtk enums and properties there. (Gimp::Thumb might become an extra module on CPAN, even, I see possible uses in non-gimp-apps. Same is true for the other libgimp interfaces that are not tied into the gimp protocol themselves). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Script-Fu template - really this time...
Simon Budig ([EMAIL PROTECTED]) wrote: The script is attached as well as available at http://www.home.unix-ag.org/simon/files/script-fu-template.scm /me feels stupid. Now it really is attached... :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ; ; Script-Fu template, fill in the blanks and have fun :) ; ; (C) 2004 Simon Budig [EMAIL PROTECTED] ; ; This template is in the public domain, I'd like to encourage you to ; place your script under the GPL. ; ; define the function that does the actual work. Choose a name that ; does not clash with other names in the PDB. It starts with script-fu ; by convention. ; functions that should be registered in the images context menu have ; to take the image and current drawable as the first two arguments. (define (script-fu-template image drawable color) ; the let* environment allows you to define local variables. ; It is considered good style to define all variables used ; in the script here, so that the global namespace does not ; get polluted. (let* ( ; calls to PDB functions always return a list. We have ; to pick the first element with car explicitely, even ; when the function called returns just one value. (width (car (gimp-drawable-width drawable))) (height (car (gimp-drawable-height drawable))) (x0 (car (gimp-drawable-offsets drawable))) (y0 (cadr (gimp-drawable-offsets drawable))) ; - here we pick the second element of the ; returned list... (old-fg-color (car (gimp-palette-get-foreground))) ) ; Ok, we are about to do multiple actions on the image, so ; when the user wants to undo the effect he should not have ; to wade through lots of script-generated steps. Hence ; we create a undo group on our image. (gimp-image-undo-group-start image) ; Here you'd implement your own ideas. For now we ; just select and fill a rectangle centered on the ; currently active drawable. (gimp-rect-select image (+ x0 (* width 0.25)) (+ y0 (* height 0.25)) (* width 0.5) (* height 0.5) CHANNEL-OP-REPLACE 0 0) (gimp-palette-set-foreground color) (gimp-edit-fill drawable FOREGROUND-FILL) ; it always is a good idea to restore the state of the ; GIMP. This makes it easier for the user who uses gimp, ; since e.g. his foreground color does not change ; unexpectedly. Thats why we saved it in a variable, ; now we restore it again. (gimp-palette-set-foreground old-fg-color) ; We are done with our actions. End the undo group ; opened earlier. Be careful to properly end undo ; groups again, otherwise the undo stack of the image ; is messed up. (gimp-image-undo-group-end image) ; finally we notify the UI that something has changed. (gimp-displays-flush) ) ) ; Here we register the function in the GIMPs PDB. ; We have just one additional parameter to the default parameters: ; the user can choose the color for the script. For more available ; script-fu user interface elements see the test-sphere.scm script. (script-fu-register script-fu-template Image/Script-Fu/Render/Rectangle... script-fu template (right now renders just a rectangle) Simon Budig [EMAIL PROTECTED] Simon Budig 2004/2/10 RGB* GRAY* SF-IMAGE Input Image 0 SF-DRAWABLE Input Drawable 0 SF-COLOR Rectangle Color '(10 80 256) ) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
