Net-Fu + Gimp 1.2.x
Hello, I installed Gimp 1.04 with NetFu and it works great. But I didn't manage to work Gimp 1.2.0 with Net-Fu. Is it possible to run Net-Fu with Gimp 1.2.x ? Nicolay Mausz
Re: Problem with perl-plugin (script-fu rip off)
On Tue, Dec 05, 2000 at 08:54:44PM +0100, "Thomas S. Iversen" <[EMAIL PROTECTED]> wrote: > ... and on a related note, I can't seem > to get Gimp->file_png_save($img,-1,) to work > or file_gif_save() maybe because -1 is not a valid drawable. Use a layer here (e.g. "($img->layers)[0]") and it should work. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Problem with perl-plugin (script-fu rip off)
On Tue, Dec 05, 2000 at 08:54:44PM +0100, "Thomas S. Iversen" <[EMAIL PROTECTED]> wrote: > I have converted a script-fu script to perl-fu, but are having some > problems. While I get nearly the same pictures, the original have > transparency around the button while my perlified version doesn't. The image or just the saved version? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Problem with perl-plugin (script-fu rip off)
Hello there I have converted a script-fu script to perl-fu, but are having some problems. While I get nearly the same pictures, the original have transparency around the button while my perlified version doesn't. I thought it could have something to do with the save routine In the original script I press save and save it. In the modified version I do #./uni -o test.gif ... and on a related note, I can't seem to get Gimp->file_png_save($img,-1,) to work or file_gif_save() for that matter. Please help Yours Thomas ; The GIMP -- an image manipulation program ; Copyright (C) 1995 Spencer Kimball and Peter Mattis ; ; Round Button --- create a round beveled Web button. ; Copyright (C) 1998 Federico Mena Quintero & Arturo Espinosa Aldama ; [EMAIL PROTECTED] [EMAIL PROTECTED] ; ; Changed on Feb 4, 1999 by Piet van Oostrum <[EMAIL PROTECTED]> ; For use with GIMP 1.1. ; All calls to gimp-text-* have been converted to use the *-fontname form. ; The corresponding parameters have been replaced by an SF-FONT parameter. ; ; ; This program is free software; you can redistribute it and/or modify ; it under the terms of the GNU General Public License as published by ; the Free Software Foundation; either version 2 of the License, or ; (at your option) any later version. ; ; This program is distributed in the hope that it will be useful, ; but WITHOUT ANY WARRANTY; without even the implied warranty of ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ; GNU General Public License for more details. ; ; You should have received a copy of the GNU General Public License ; along with this program; if not, write to the Free Software ; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. (define (text-width extents) (car extents)) (define (text-height extents) (cadr extents)) (define (text-ascent extents) (caddr extents)) (define (text-descent extents) (cadr (cddr extents))) (define (round-select img x y width height ratio) (let* ((diameter (* ratio height))) (gimp-ellipse-select img x y diameter height ADD FALSE 0 0) (gimp-ellipse-select img (+ x (- width diameter)) y diameter height ADD FALSE 0 0) (gimp-rect-select img (+ x (/ diameter 2)) y (- width diameter) height ADD FALSE 0))) (define (script-fu-round-button text size font ul-color lr-color text-color ul-color-high lr-color-high hlight-color xpadding ypadding bevel ratio notpressed notpressed-active pressed) (cond ((eqv? notpressed TRUE) (do-pupibutton text size font ul-color lr-color text-color xpadding ypadding bevel ratio 0))) (cond ((eqv? notpressed-active TRUE) (do-pupibutton text size font ul-color-high lr-color-high hlight-color xpadding ypadding bevel ratio 0))) (cond ((eqv? pressed TRUE) (do-pupibutton text size font ul-color-high lr-color-high hlight-color xpadding ypadding bevel ratio 1 (define (do-pupibutton text size font ul-color lr-color text-color xpadding ypadding bevel ratio pressed) (let* ((old-fg-color (car (gimp-palette-get-foreground))) (old-bg-color (car (gimp-palette-get-background))) (text-extents (gimp-text-get-extents-fontname text size PIXELS font)) (ascent (text-ascent text-extents)) (descent (text-descent text-extents)) (height (+ (* 2 (+ ypadding bevel)) (+ ascent descent))) (radius (/ (* ratio height) 4)) (width (+ (* 2 (+ radius xpadding)) bevel (- (text-width text-extents) (text-width (gimp-text-get-extents-fontname " " size
Re: Gimp gimp-1.1.28 (script-fu problem)
Hi, Jeff Sheffield <[EMAIL PROTECTED]> writes: > [jsheffie@kelly bin]$ ./gimp > ^[[A./gimp terminated: Interrupt > /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/animate_cells terminated: > Interrupt > --- > animate_cells...?? animate_cells is a gimp-perl script, which makes me think that this thread should be titled "perl-fu problem". The fact that the splash says script-fu when gimp hangs most probably means nothing but the fact that the script-fu extension has been properly started, but gimp hangs during initialization of the first plug-in, which seems to be a gimp-perl plug-in in your case. I suggest you make sure that there are only recent plug-ins in your plug-in dir (probably the gimp-perl scripts are from an earlier installation?). Then check that you run a compatible verion of perl (ask Marc what that means and please ask him to put that information into the README). If everything else fails, compile gimp with --disable-perl. Salut, Sven
Re: Gimp gimp-1.1.28 (script-fu problem)
On Wednesday, 25 Oct 2000, Jeff Sheffield wrote: > the splash screen hangs with the subtitle > Plug-ins > and the path > /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/script-fu > > another interesting thing that happens is. > when I ctrl-C the app I get the following strange output > - > [jsheffie@kelly bin]$ ./gimp > ^[[A./gimp terminated: Interrupt > /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/animate_cells terminated: > Interrupt > --- > animate_cells...?? That's presumably the plugin that's currently in the process of being probed when you killed the main application. Make sure you've deleted all the plugin directories before you "make install" so there aren't any old plugins left around. Austin
Re: Gimp gimp-1.1.28 (script-fu problem)
Actually that should not be the problem... (I think ;) I build it with the --enable-gimpdir= flag set like this #!/bin/sh date |tee build-start; ./configure --prefix=/opt/gimp/gimp-1.1.28 \ --enable-gimpdir=.gimp-1.1.28 |tee configure.out; \ make |tee make.out; date |tee build-end; \ make install |tee make.install.out;\ echo "build start time"; cat build-start; \ echo "build end time "; cat build-end - just to bee sure i tested removing the ~user/.gimp-1.1 as you suggested and I still had the problem... more details. the splash screen hangs with the subtitle Plug-ins and the path /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/script-fu another interesting thing that happens is. when I ctrl-C the app I get the following strange output - [jsheffie@kelly bin]$ ./gimp ^[[A./gimp terminated: Interrupt /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/animate_cells terminated: Interrupt --- animate_cells...?? Jeff On Wed, Oct 25, 2000 at 12:06:18PM +0300, Tuomas Kuosmanen wrote: > On Tue, Oct 24, 2000 at 07:07:27PM -0500, thus said Jeff Sheffield: > > Ok i have Linux Mandrake 7.1 > > > > I build the gimp 1.1.28 > > everything built and made fine > > when I start running the program > > the status screen comes up and starts loading > > it hangs while trying to load the "script-fu" > > stuff. nothing goes to STRERR > > > > i also downloaded (last night) the cvs version and tried to build > > that one and got the same problem. > > > > Note i build these from the ground up (i don't patch) > > i also build them in nonstandard places. > > > > thoughts..? > > If you used an ancient 1.1.x before, you can try "rm -rf ~/.gimp-1.1/" > Back up the stuff if you have any custom brushes or stuff there though. > > That seems to help sometimes. > > Tuomas > > -- > > .---> [EMAIL PROTECTED] .|\,/| [EMAIL PROTECTED] <-. > +> www.helixcode.com - ()-@@ , tigert.gimp.org <+ > `-> art director , `--')/ a gimp artist <---' > Thanks, Jeff -- | I started out with nothing... | | I still have most of it left. | | --Anonymous | -- | Jeff Sheffield | | [EMAIL PROTECTED] | --
Re: Gimp gimp-1.1.28 (script-fu problem)
On Tue, Oct 24, 2000 at 07:07:27PM -0500, thus said Jeff Sheffield: > Ok i have Linux Mandrake 7.1 > > I build the gimp 1.1.28 > everything built and made fine > when I start running the program > the status screen comes up and starts loading > it hangs while trying to load the "script-fu" > stuff. nothing goes to STRERR > > i also downloaded (last night) the cvs version and tried to build > that one and got the same problem. > > Note i build these from the ground up (i don't patch) > i also build them in nonstandard places. > > thoughts..? If you used an ancient 1.1.x before, you can try "rm -rf ~/.gimp-1.1/" Back up the stuff if you have any custom brushes or stuff there though. That seems to help sometimes. Tuomas -- .---> [EMAIL PROTECTED] .|\,/| [EMAIL PROTECTED] <-. +> www.helixcode.com - ()-@@ , tigert.gimp.org <+ `-> art director , `--')/ a gimp artist <---'
Gimp gimp-1.1.28 (script-fu problem)
Ok i have Linux Mandrake 7.1 I build the gimp 1.1.28 everything built and made fine when I start running the program the status screen comes up and starts loading it hangs while trying to load the "script-fu" stuff. nothing goes to STRERR i also downloaded (last night) the cvs version and tried to build that one and got the same problem. Note i build these from the ground up (i don't patch) i also build them in nonstandard places. thoughts..? Thanks, Jeff -- | Do not try to cut your own hair. | | -- Forrest Gump | | -- Winston Groom | -- | Jeff Sheffield | | [EMAIL PROTECTED] | --
Re: calling script-fu from perl script
Thus spoke Marc Lehmann > >script_fu_old_photo($drawable, 0, 1, 1, 1, 0); > > Ah, now it's clear: script_fu_old_photo _destroys_ the layer that is > passed in. Using the drawable after that was a bug in your (original) code > (this is a very common bug). True. Still, I fixed that bug and still needed a delay to prevent crashing. And the delay had to be at least 2 seconds - 1 second delays caused strange results. > The problem seems to be that old_photo calls flatten, and this might > change a lot of internal structures. the right fix would be to make > old-photo return the newly created layer/image/whatever, but AFAIK > script-fu is unable to return anything to the caller (scirpt-fu was never > designed to be called from the outside, obviously). This would be better, but it still doesn't account for what I see happen - which is the second plug-in getting called before the first has finished. > This is highly unlikely. the current set of perl plug-ins call a lot of > other plug-ins (including pelr ones) without a problem. I am quite certain > it's either an uncommon operation or yet another script-fu-breakage, for > example, script-fu is the only plug-in that stays in memory all the time, > even if not used, and uses temporary pdb functions instead of normally > registered calls (that's why it's so slow on startup). This could be the > key... I tried this test with perl-fu and C plug-in calls but couldn't reproduce it. It may be limited to calls to Script-Fu plug-ins. I'm not positive of this because few of the perl-fu and C plug-ins 1) take very long to process *and* 2) generate additional layers in the manner of Old Photo. In any case, the problem is pretty consistant with Script-Fu scripts. I tried a number of them. -- Michael J. Hammel | The Graphics Muse | If ignorance is bliss, why aren't more [EMAIL PROTECTED] | people happy? http://www.graphics-muse.com
Re: calling script-fu from perl script
On Sun, Sep 10, 2000 at 10:39:26PM -0500, "Michael J. Hammel"
<[EMAIL PROTECTED]> wrote:
> > Not in the current architecture. The caller is blocked until the called
> > plug-in has finished.
>
> That would be the preferred design, but my tests don't seem to bear this
> out. Again, I could be misinterpreting the results, though I'm fairly
> certain I'm not.
You must, since if this were true we could expect a lot more breakage, but to
the contrary it's only script-fu. Also, the API for plug-ins looks like this:
function run_callback()
{
... parse agruments
... execute script
... create result values
return;
}
Only when the plug-in returns results values are passed back. There
is currently no way for a plug-in to both return from the call AND do
something.
>script_fu_old_photo($drawable, 0, 1, 1, 1, 0);
Ah, now it's clear: script_fu_old_photo _destroys_ the layer that is
passed in. Using the drawable after that was a bug in your (original) code
(this is a very common bug).
## $drawable no longer valid
>$drawable = gimp_image_get_active_layer($img);
## $drawable valid again
> If I remove the sleep() call then Gimp crashes
The bug here is that Gimp crashes while it shouldn't, but this is more
a cosmetic problem (it's still easy to crash the gimp using illegal pdb
calls, unfortunately).
> only 1 second, various results occur. If I don't use the call to
> gimp_image_get_active_layer(), with or without the delay, then Gimp crashes.
The problem seems to be that old_photo calls flatten, and this might
change a lot of internal structures. the right fix would be to make
old-photo return the newly created layer/image/whatever, but AFAIK
script-fu is unable to return anything to the caller (scirpt-fu was never
designed to be called from the outside, obviously).
> tells me that the blocking you mention isn't happening. In fact, I can
> watch part of the drop shadow actually being performed on the image *before*
> any visible results from old_photo happen - all before Gimp crashes. Weird,
> but that's what I'm seeing.
I doubt that this has something to do with the plug-in API. Most probably
some pdb function only starts the rendering (AFAIK there was some
semi-recent change to push some long-running-ops into the background, so I
guess some locking there is missing).
> True. Still, my misuse of a valid drawable was unexpected for the Gimp. There
> may be some error checking that could be done to prevent the crash,
Well, it's not as if a the developers didn't put a lot of effort into
argument checking. It is definitely much more difficult to crash the gimp
now than half a year ago ;)
> this can't be addressed before 1.2 is released) to make a note that
> serializing of calls to plug-ins from plug-ins is not guaranteed.
This is highly unlikely. the current set of perl plug-ins call a lot of
other plug-ins (including pelr ones) without a problem. I am quite certain
it's either an uncommon operation or yet another script-fu-breakage, for
example, script-fu is the only plug-in that stays in memory all the time,
even if not used, and uses temporary pdb functions instead of normally
registered calls (that's why it's so slow on startup). This could be the
key...
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: calling script-fu from perl script
On Mon, Sep 11, 2000 at 10:32:42AM +0100, Austin Donnelly <[EMAIL PROTECTED]> wrote: > From your evidence with sleep() it does sound like the call to the > plugin is not blocking until the plugin returns. Yes, but this is impossible to _program_ using the current API. The only way to return to the caller is by returning form the plug-in. > I'm not sure whether the call goes via the main application, or if the call goes >directly. Always through the main gimp process. > Again, this is where per-image locks would help sort these kinds of > problems out. I am afraid per-image-locks are an orthogonal concept: Either per-image-locks are per-function-call (which leads into the next alternative) or the called plug-in has to inherit all locks somehow, which would mean locks wouldn't help. > a) make calls to plugins from other plugins block properly, as you, > Marc and presumably others expect. This is the current state: remember that it is only script-fu that makes problems, and script-fu could *never* be called properly form other plug-ins, so I guess the problem really is script-fu. Especially since all other plug-ins work fine (some perl-plug-ins even call other perl plug-ins through the pdb with no problems). If this were a common issue much more things would break. > when it should be used. But, it might be easier to do than a). I > don't know, I haven't looked at the code. Since a) is currently implemented, I at the moment think that some of the original diagnosis was wrong, i.e. the code just happened to run by chance due to the sleep, and the real bug was to re-use a layer that does not really exist as previous anymore. The only other thing I could think of is that some core (in-gimp) pdb call returned before the appropriate action was carried out, but this is unlikely. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: calling script-fu from perl script
On Sunday, 10 Sep 2000, Michael J. Hammel wrote: > Thus spoke Marc Lehmann > > Not in the current architecture. The caller is blocked until the called > > plug-in has finished. > > That would be the preferred design, but my tests don't seem to bear this > out. Again, I could be misinterpreting the results, though I'm fairly > certain I'm not. >From your evidence with sleep() it does sound like the call to the plugin is not blocking until the plugin returns. I'm not sure whether the call goes via the main application, or if the call goes directly. Again, this is where per-image locks would help sort these kinds of problems out. I can see two solutions, discounting image locking ones: a) make calls to plugins from other plugins block properly, as you, Marc and presumably others expect. or b) add an explicit gimp_wait_for_plugin() call which blocks until there are no outstanding operations on the image. I don't particularly like b) since it's not obvious to a script writer when it should be used. But, it might be easier to do than a). I don't know, I haven't looked at the code. Austin
Re: calling script-fu from perl script
Thus spoke Marc Lehmann > Not in the current architecture. The caller is blocked until the called > plug-in has finished. That would be the preferred design, but my tests don't seem to bear this out. Again, I could be misinterpreting the results, though I'm fairly certain I'm not. > However, are you sure that the layer you used to calldrop-shadow is still > valid after drop-shadow returns? If not, then this would explain why the > example above works (and this would be the right fix). The basic code looks like this: script_fu_old_photo($drawable, 0, 1, 1, 1, 0); sleep(2); $drawable = gimp_image_get_active_layer($img); script_fu_drop_shadow($drawable, "8", "8", "15", [0,0,0], "100.0", 1); If I remove the sleep() call then Gimp crashes. If I make the sleep() call only 1 second, various results occur. If I don't use the call to gimp_image_get_active_layer(), with or without the delay, then Gimp crashes. The call to gimp_image_get_active_layer() makes sense - script_fu_old_photo() probably updates the image in a way that the drawable ID for the flattened image has changed. The need for the 2 second delay tells me that the blocking you mention isn't happening. In fact, I can watch part of the drop shadow actually being performed on the image *before* any visible results from old_photo happen - all before Gimp crashes. Weird, but that's what I'm seeing. If I change the sleep() to 1 second, I get results that pretty much prove the issue: The rest of my script (which you've not seen yet and I only added after I found that the delay workaround actually worked) copies in a tile that it pastes into the main image, moves to the bottom layer and then flattens the whole thing. With a 1 second delay all of this pasting, moving and flattening actually occurs - but *before* the shadow layer from drop_shadow is placed in the image. You can see this by looking at the layers dialog after the script completes. It has the flattend old photo/tile bg image layer over a black shadow layer. Two layers, in an image that my script flattened, and no errors are produced. So, I'm fairly certain the blocking is not happening. > Could it be that the whole problem was just your script re-uzsing a drawable > id that didn't exist after drop-shadow returns? i.e. does drop-shadow really > lave the layer alone or does it create a new one? It was partially, but the delay (via sleep(2)) does seem to be mandatory. Blocking does not appear to be happening. > (Iny case, gimp shouldn't crash) True. Still, my misuse of a valid drawable was unexpected for the Gimp. There may be some error checking that could be done to prevent the crash, I suppose. My bigger concern in this particular case is the serializing of the calls. I can work around this issue with the delay, but it might be necessary (if this can't be addressed before 1.2 is released) to make a note that serializing of calls to plug-ins from plug-ins is not guaranteed. BTW, if anyone wants a copy of the script I'm using that shows this let me know. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Everything should be made as simple as possible. But not simpler. -- Albert Einstein.
Re: calling script-fu from perl script
On Sun, Sep 10, 2000 at 02:56:07PM -0500, "Michael J. Hammel" <[EMAIL PROTECTED]> wrote: > plug-ins from another plug-in. Since the plug-ins run as separate > processes, the calling plug-in continues running after each call to another > plug-in. Not in the current architecture. The caller is blocked until the called plug-in has finished. However, are you sure that the layer you used to calldrop-shadow is still valid after drop-shadow returns? If not, then this would explain why the example above works (and this would be the right fix). > I don't see how you can "fix" this problem with the Gimp and maintain the Could it be that the whole problem was just your script re-uzsing a drawable id that didn't exist after drop-shadow returns? i.e. does drop-shadow really lave the layer alone or does it create a new one? (Iny case, gimp shouldn't crash) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: calling script-fu from perl script
> Highly interesting indeed. Now, what gimp-perl does (when you pass in a > drawable instead of both image and drawable) is this: > > if (sv_derived_from (sv, PKG_DRAWABLE)) > arg->data.d_image = gimp_drawable_image_id(unbless(sv, PKG_DRAWABLE, >croak_str)); > > i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id > etc..) to get the image, which in turn calls the the pdb function > gimp_drawable_image without any caches. This means that, temporarily, gimp > returns "-1" as the image id and later the correct one. I did some more experimenting today and found that the following code works: # Apply an "old photo" look to it. The sleep() is a delay to allow the # script to finish before we try to run any other plug-ins on it. script_fu_old_photo($drawable, 0, 1, 1, 1, 0); sleep(2); $drawable = gimp_image_get_active_layer($img); # Apply the Drop Shadow filter to it. script_fu_drop_shadow($drawable, "8", "8", "15", [0,0,0], "100.0", 1); What this tells me is that the problem has to do with calling multiple plug-ins from another plug-in. Since the plug-ins run as separate processes, the calling plug-in continues running after each call to another plug-in. The first called plug-in can change the make up of the image drawables *after* the second plug-in is called. That, understandably, is a bad thing and unexpected results are likely. So plug-ins which call other plug-ins - especially plug-ins that add or delete layers from an image - need to pause for those plug-ins to complete and then make sure they have the current active drawable for the image being worked on before calling the next plug-in. I don't see how you can "fix" this problem with the Gimp and maintain the ability for interactive users to work on multiple images while plug-ins are running. The only possible option is to add some sort of "serialize plug-ins" feature that can be turned on and off from within a plug-in. Doesn't sound easy. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Memory is a Net - Oliver Wendell Holmes, Sr.
Re: calling script-fu from perl script
On Sun, Sep 10, 2000 at 01:23:31PM -0500, "Michael J. Hammel"
<[EMAIL PROTECTED]> wrote:
Hmm, a serialization issue is unlikely, since all the other plug-ins seem
to work, and script-fu never could be called reliably. If this, however,
is indeed the case than this change is probably quite new (maybe somebody
hacked locking lately?)
> > drawable instead of both image and drawable) is this:
>
> Is there a way to pass in the image id?
Just pass it in at the usual position.
> I tried, but I get error messages
Did you pass in a valid image, or did you try to pass in a number? The latter
might not work reliably. You can also try to use the all-explicit syntax,
i.e.
(RUN_INTERACTIVE, $image, $drawable, ...
> when I try to pass the image id as the first parameter. Do you pass the
> image id and drawable id's as a list?
No, you pass them "as usual".
>
> > i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id
> > etc..) to get the image, which in turn calls the the pdb function
> > gimp_drawable_image without any caches. This means that, temporarily, gimp
> > returns "-1" as the image id and later the correct one.
>
> Ick. If this is true then there is a timing issue here where plug-ins
> can't call other plug-ins.
you could check this hypothesis by doing something like this:
for (0..29) {
print "IMAGE ID: ", ${$drawable->image}, "\n";
select undef, undef, undef, 0.1;
}
this (untested) snippet prints out the image id of your drawable ten times
a second. Just insert it after the call to drop_shadow (i.e. where you
formerly added the delay).
When the image id changes from -1 to something else we have found the
problem.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: calling script-fu from perl script
Thus spoke Marc Lehmann > Thanks for the reply ;) I posted it to gimp-developer because i seems this > is a generic gimp bug and hope somebody else can add more. It does sound like a problem with how Script-Fu (and maybe plug-ins in general) are serialized. > > Looks like the image id gets changed somehow. Ideas? > > Highly interesting indeed. Now, what gimp-perl does (when you pass in a > drawable instead of both image and drawable) is this: Is there a way to pass in the image id? I tried, but I get error messages when I try to pass the image id as the first parameter. Do you pass the image id and drawable id's as a list? > i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id > etc..) to get the image, which in turn calls the the pdb function > gimp_drawable_image without any caches. This means that, temporarily, gimp > returns "-1" as the image id and later the correct one. Ick. If this is true then there is a timing issue here where plug-ins can't call other plug-ins. > Here I have to give up and hope this rings a bell for somebody more tied > to the internals of gimp id management. I'm going to try calling C plug-ins instead of Script-Fu, and variations on the same, to see if there is one specific area where this happens. Thanks for looking into this, Mark. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Try again. Fail again. Fail better. -- Thomas Beckett
Re: calling script-fu from perl script
On Sat, Sep 09, 2000 at 11:18:49AM -0500, "Michael J. Hammel" <[EMAIL PROTECTED]> wrote: Thanks for the reply ;) I posted it to gimp-developer because i seems this is a generic gimp bug and hope somebody else can add more. > gimp. I suspect (but it's a guess) that the second one causes a change to the > drawable id's for the image (which starts with a single layer when > old_photo gets to it). If the script-fu-drop-sahdow does change the darwable id (creates a new one and deleted the old one) then your code is buggy: you simply mustn't call gimp functiosn on drawables that do not exist. In this case this would also be a gimp-bug, however, since gimp is not supposed to crash when you feed it nonexistant drawable id's. > If this is the problem, perhaps setting a delay of some kind between the > two would work. No, it wouldn't. A delay wouldn't change the drawable id. A delay would help if script-fu would return to the gimp before it finished its work (unlikely, but definitely not impossible), or gimp would do something after it has forwared the results to perl. > script_fu_drop_shadow( > INT32 run_mode=1"Interactive, non-interactive" > IMAGE image=-1 "Image" > DRAWABLE drawable=2 "Drawable" > > Without the sleep() call, the last entry looks like this: > > script_fu_drop_shadow( > INT32 run_mode=1"Interactive, non-interactive" > IMAGE image=0 "Image" > DRAWABLE drawable=2 "Drawable" > Looks like the image id gets changed somehow. Ideas? Highly interesting indeed. Now, what gimp-perl does (when you pass in a drawable instead of both image and drawable) is this: if (sv_derived_from (sv, PKG_DRAWABLE)) arg->data.d_image = gimp_drawable_image_id(unbless(sv, PKG_DRAWABLE, croak_str)); i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id etc..) to get the image, which in turn calls the the pdb function gimp_drawable_image without any caches. This means that, temporarily, gimp returns "-1" as the image id and later the correct one. Here I have to give up and hope this rings a bell for somebody more tied to the internals of gimp id management. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: calling script-fu from perl script
On Fri, Sep 08, 2000 at 07:04:04PM -0500, "Michael J. Hammel"
<[EMAIL PROTECTED]> wrote:
> $drawable->script_fu_drop_shadow("8", "8", "15", [0, 0, 0], "0", 1);
AFAICS, this should work.
> interactively. I've also tried without the quotes (those are supposed to
> be STRINGS according to the PDB)
Which shouldn't matter, either (all the same for perl).
> gets resized) but immediately after making a selection around the current
> layer Gimp crashes.
gimp or script-fu? script-fu could never be called via the pdb, despite a lot
of effort to fix that, so script-fu breaking is not unexpected - gimp should
however, not really crash.
Could you add the following call before the call to drop_shadow:
Gimp::set_trace(-1);
and post the resulting trace output? This will help us find out what,
actually, is getting passed to script-fu (this is helpful in any case as
it shows wether you passed the arguments in correctly).
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
calling script-fu from perl script
I'm trying to call the Drop Shadow filter from a Gimp Perl script. I've
tried it a number of different ways and it crashes each time. I think the
right format is:
$drawable->script_fu_drop_shadow("8", "8", "15", [0, 0, 0], "0", 1);
which should be exactly the same as using the defaults when you run it
interactively. I've also tried without the quotes (those are supposed to
be STRINGS according to the PDB). Am I passing the color argument
incorrectly? The drop shadow script does appear to start (the image window
gets resized) but immediately after making a selection around the current
layer Gimp crashes.
Any ideas?
--
Michael J. Hammel The Graphics Muse
[EMAIL PROTECTED] http://www.graphics-muse.com
--
Truth is stranger than fiction, but fiction is cheaper and faster than truth.
Script-fu: "Burn-In" V1.9 is out
First, let me say thanks to all people who gave me feedback and sent me bug reports the last days. This helps alot (and keeps me on working ;-) Now for the news: I've just released Script-Fu "Burn-In" V1.9 for Gimp 1.0.X. You can now use your own background-layer and create fascinating text animations for the web. Please note that this version is considered as pre2.0 and therefore still "beta". It works, but I didn't have the time to do extensive testing. :-/ (Burn-In V1.0 was already announced by Xach some days ago (thanks!) For download & demos please see http://fuchur.leute.server.de/burn_in/ Roland
script fu: writing to a text file.
Hi I want to make an export plugin from a multilayer gimp image to my game. My idea is to separate each layers as pngs files (to use transparency and compression) and then to write a text file like this: layer1 : image1.png layer2 : image2.png layer3 : image3.png ... I manage to export each layers on separate layers, but not to find the function to write to a text file.. For the moment, this is a script fu, but I don't know scheme... So, I would prefer C, but I didn't find any example of C plugin doing this kind of stuff... Any help would be welcom... Mandor [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
script-fu behaving strangely ...
Hi all, I've done a script-fu in scheme, which works well in the console, but not so well when runing it. The script is simply apply a (plug-in-gauss-rle 1 image drawable 5 1 1) followed by (gimp-brightness-contrast image drawable -90 123) on an animation. Simple, isn't it ? But the fact is that the brightness-contrast doesn't apply at all !!! If I remove the blur it work !!! But then I had to run 2 scripts instead of one ! I though scripting was made to make life easier ;) Anyone can help ? I'm using Gimp 1.0.4 on Irix 6.5. Thank Fly Chapron P.S: Hope it's not a post for the user ML ;)
Re: Perl-fu - transparent colour
On Wed, May 31, 2000 at 03:48:14PM +0530, Gunjan Kapoor <[EMAIL PROTECTED]> wrote: > colour for the entire image. Is that possible with Perl-fu. e.g: specify > white as the transparent colour. What do you want to do? Do you want to replace white by transparency? This is easy (not only in perl-fu, btw), just use plug_in_colortoalpha, e.g.: $layer->colortoalpha(WHITE); If you just want to replace a specific colour index (e.g. in an indexed image) you can also use select_by_color and selection_clear. > I've tried adding an alpha channel programmatically but perhaps did not > know the proper procedure and the desired results were not achieved. This usually suffices: "$layer->add_alpha". -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Perl-fu - transparent colour
Hi, Could someone help me out with this. I need to specify a transparent colour for the entire image. Is that possible with Perl-fu. e.g: specify white as the transparent colour. Additionally, I need to make the background transparent for a programmatically generated image. The image contains only one drawable. I've tried adding an alpha channel programmatically but perhaps did not know the proper procedure and the desired results were not achieved. TIA Gunjan
Re: Perl-Fu plug-ins in 1.1.21
On Mon, May 08, 2000 at 12:47:27AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > The order of menus was determined by the order of installation. The code > in plug-in.c uses readdir(). On most systems this will give you the plug-ins > in the order the inodes were created. I doubt it. But the usual order in directorirs comes close indeed. This expalins why perl plug-ins were grouped together. > more or less unpredictable, I have checked in some code today that orders > the plug-ins and script-fu scripts alphabetically according to their > translated menu-entries. Very good! > I have however noticed that perl i18n is totally broken at the moment (at > least on my box) and I couldn't figure out why. I checked in a patch yesterday (or the day before) that should fix the ".gmo files not created properly" problem. > passed to menus_create_item...() correctly. Later I found out why this > does not work: gimp-perl sets the domain-path to "/usr/share/locale". > As the po build system in gimp-perl is definitely messed up since no > gmo files are build ever, I can not determine if this is intentional. I'll check (unfortunately, the drive with the sources just stopped working, so I couldn't check it). > I suggest that perl installs its message catalogs under the prefix > however (which is /usr/local/ here) and uses gimp_plugin_domain_add() > instead of gimp_plugin_domain_add_with_path(). Is it guarenteed that .mo files end up in "prefix"/share/locale/? configure does not export the path that gettext uses (so rather than trying to second-guess, I used the same prefix gimp-perl uses). However, if gimp_plugin_domain_add_with_path works as advertised(?), fixing the build process should suffice. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl-Fu plug-ins in 1.1.21
Hi, myself wrote: > I have however noticed that perl i18n is totally broken at the moment (at > least on my box) and I couldn't figure out why. This was broken before my > changes and I have double-checked that the gimp-perl text-domain gets > passed to menus_create_item...() correctly. Later I found out why this > does not work: gimp-perl sets the domain-path to "/usr/share/locale". > As the po build system in gimp-perl is definitely messed up since no > gmo files are build ever, I can not determine if this is intentional. > I suggest that perl installs its message catalogs under the prefix > however (which is /usr/local/ here) and uses gimp_plugin_domain_add() > instead of gimp_plugin_domain_add_with_path(). Actually running autogen.sh in the toplevel gimp source dir solved the problem Salut, Sven
Re: Perl-Fu plug-ins in 1.1.21
Hi, > For 1.2, the solution should be clear: find out why perl plug-ins get > specialcased (maybe because menus.c doesn't know about them but about the > c-plug-ins? or maybe because the i18n code handles them differently?) and > sort everything alphabetically (source language, e.g. english). The order of menus was determined by the order of installation. The code in plug-in.c uses readdir(). On most systems this will give you the plug-ins in the order the inodes were created. This means that the order of menus was more or less unpredictable, I have checked in some code today that orders the plug-ins and script-fu scripts alphabetically according to their translated menu-entries. I have however noticed that perl i18n is totally broken at the moment (at least on my box) and I couldn't figure out why. This was broken before my changes and I have double-checked that the gimp-perl text-domain gets passed to menus_create_item...() correctly. Later I found out why this does not work: gimp-perl sets the domain-path to "/usr/share/locale". As the po build system in gimp-perl is definitely messed up since no gmo files are build ever, I can not determine if this is intentional. I suggest that perl installs its message catalogs under the prefix however (which is /usr/local/ here) and uses gimp_plugin_domain_add() instead of gimp_plugin_domain_add_with_path(). Salut, Sven Salut, Sven
Re: Perl-Fu plug-ins in 1.1.21
On Fri, May 05, 2000 at 01:22:48PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > entries? Sort them according to their original name (easy) or according > to the translated one? I fear that the latter will be difficult and it > would lead to different menu orders depending on what language you > started gimp with. > > I'm undecided. What do you think ? For 1.2, the solution should be clear: find out why perl plug-ins get specialcased (maybe because menus.c doesn't know about them but about the c-plug-ins? or maybe because the i18n code handles them differently?) and sort everything alphabetically (source language, e.g. english). Sorting them alphabetically is not right, either, so maybe we should get 1.2 out and working instead of trying some nasty tricks to still not get it right. (== my opinion, if this was a poll ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl-Fu plug-ins in 1.1.21
On Wed, May 03, 2000 at 03:20:19PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > That's why I am surprised to get this problem: I double-checked that I > had no old files in the plug-ins directory before reporting this > strange bug. The only files that are in the plug-in-path came from a > fresh install of 1.1.21. I also re-did a "make" and "make install" in > the source tree to be sure that I was not dreaming. :-) Maybe you have an old gimp-perl installation? You could check the configure output for messages to that extend (gimp-perl _tries_ to chekc for old, incompatible installations). > > If you give me a log-in on your machine I could fix it ;) > > home. But if you want to come and say hello, I can give you my work > address and a roadmap of the area. ;-) Uh ;-> Cool, but I guess it might be a bit *too* far for a casual visit ;) (You could also send me the output of configure + make + make install) > > (that were reinstalled) registered below the existing plug-ins and the > > perl-plug-ins (which you haven't reinstalled) moved to the top. > > register again before the C plug-ins. This appears to be new, > although I do not know when this behavior was introduced because the Hmm.. I just recompiled my tree (cvs last night), nuked ~/.gimp, but I can't see the same behaviour. The scripts seem to be scattered around quite randomly in the menus. Sinc eI do not know wether gimp cares at all about menu-order (ot might be that app/menus.c does something), I shouldn't comment anyway ;) > > a seperate menu hierarchy hardly makes sense. > > The same arguments apply to Script-Fu as well, however there is still > a separate menu hierarchy for these scripts. But maybe a separate > menu hierarchy is not the best solution... This is a (IMnsHO) very nice conclusion ;) From a GUI POV, seperating similar functionality into different menus does not make sense. It only adds work for the user who needs to memorize that a given Filter (say, unsharpen-warp) is not in the Filters menu, but in the Script-Fu menu. It is also hard to explain to new users that "Add Dust" would be found in a "Perl" submenu and not in "Filters", especially since most people do not know what "Perl" is (or Script-Fu). > care too much about the Perl-Fu scripts and do not even test them. I > am sure that I am not the only one who is worried about the overall > consistency of the user interface, but I am surprised by the lack of > comments about Perl-Fu I got some comments to the extent of "perl-fu does not follow gimp-gui standards", but I was never able to find out what that means (i.e. what the gimp-gui standard is, and what must be changed to be more compliant). As for consistency, most perl-scripts use the Gimp::Fu module to create their dialog, which ensures overall consistency between 97% of all perl-scripts. It would also make it quite easy to fix any layout problems since the dialog code is in a central location. After 1.2 is released, that code will change a lot, to make it possible to add internionalized descriptions in an easier way and allow even more customization (people do not like to write their own dialog-code, it seems). > Where are the "many eyeballs" that ensure that "all bugs are shallow"? Oh, the situation has improved a lot. Quite a few gimp-developers do build perl now, and a few even test it. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl-Fu plug-ins in 1.1.21
Hi, Raphael wrote: > But I also noticed that something else has changed in the Perl-Fu > scripts: in the previous versions that I tried (under Solaris), these > scripts were always registered at the bottom of the menus, instead of > being mixed with the C plug-ins. Now it seems to be the contrary: the > Perl-Fu scripts are listed first in each menu, followed by the usual C > plug-ins. This is very distracting. > > Would it be possible to avoid this? I would prefer to have the > Perl-Fu scripts separated from the C plug-ins. Either by adding a > separator in the menus, by adding a little mark next to their names, > or by creating a separate Perl-Fu menu similar to the Script-Fu menu. I'm not sure that seperating the Perl scripts from the C plug-ins makes sense, but the menu order is definitely distracting. I have just done a complete new installation and did note the following: - perl scripts are always at top and appear in random order (well, most probably it's not random, but I can not figure out if there is some sort of order, it's definitely not alphabetic). - C plug-ins are sorted more or less alphabetic. This is however not because we sort them that way, but only because for most plug-ins the menu entries match the binary names quite good. This leads to some strange effects however. In Filters->Distorts for example "Video" appears before "Value Propagate" only because "video" is before "vpropagate" on disk. I guess that with another filesystem we might get totally different results. A possible solution would be to sort the plugin menus alphabetically. I'm not really looking forward to touch menus.c again, but there is already some code in there that reorders menu entries (moving submenus to the top for example), so it should be possible to hook that in there somewhere. So far, so good. But what do we want to do about translated menu entries? Sort them according to their original name (easy) or according to the translated one? I fear that the latter will be difficult and it would lead to different menu orders depending on what language you started gimp with. I'm undecided. What do you think ? Salut, Sven
Re: Perl-Fu plug-ins in 1.1.21
On Wed, 3 May 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> On Tue, May 02, 2000 at 08:15:44PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> > I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of
> > them abort with the following error displayed on the console:
> >
> > ** ERROR (recursed) **: could not find handler for message: 65536
> > aborting...
>
> This happens to any plug-in that doesn't get recompiled when a protocol
> bump occurs. Recompiling the perl plug-in would fix that.
Well, for some reason it didn't, that's why I reported the bug.
I extracted gimp-1.1.21.tar.gz in a new directory and built everything
from there. Then I removed everything from the previous installation
of the Gimp in ${prefix}/lib/gimp and ${prefix}/share/gimp and I did a
"make install".
That's why I am surprised to get this problem: I double-checked that I
had no old files in the plug-ins directory before reporting this
strange bug. The only files that are in the plug-in-path came from a
fresh install of 1.1.21. I also re-did a "make" and "make install" in
the source tree to be sure that I was not dreaming. :-)
> > Marc, I suppose that you are aware of this and that you can fix it?
>
> If you give me a log-in on your machine I could fix it ;)
I could give you a username and password, but that would not help you
because the firewall blocks everything. :-) Even I cannot log in from
home. But if you want to come and say hello, I can give you my work
address and a roadmap of the area. ;-)
Err... Seriously, do you or anybody on this list have any idea of
what could be causing this strange problem? Can anyone report a
successful or unsuccessful installation of 1.1.21 with Perl enabled?
My setup is:
Solaris 2.6
perl5.005_03
PDL-2.003
Parse-RecDescent-1.70
Gtk-Perl-0.6123
glib-1.2.7
gtk+-1.2.7
gimp-1.1.21
> > being mixed with the C plug-ins. Now it seems to be the contrary: the
> > Perl-Fu scripts are listed first in each menu, followed by the usual C
> > plug-ins. This is very distracting.
>
> Hmm... I wonder how the order in the menus is being worked out by the
> Gimp? Registration order? Alphabetical? Being able to control the sort
> order in some sensible way is highly desirable indeed, but will definitely
> not happen in 1.2 (IMHO it's very difficult).
>
> What happened in your case might have been that all the C-plug-ins
> (that were reinstalled) registered below the existing plug-ins and the
> perl-plug-ins (which you haven't reinstalled) moved to the top.
Unfortunately, this is not what happened. As I said, all the plug-ins
and scripts came from the new 1.1.21 package. I just checked a second
time by deleting my ~/.gimp-1.1/pluginrc and the Perl-Fu scripts
register again before the C plug-ins. This appears to be new,
although I do not know when this behavior was introduced because the
previous version (1.1.20) had another problem with the Perl-Fu scripts
and they crashed before registering.
> > a menu is mapped to a C or Perl plug-in. They behave slightly
> > differently (e.g. undo is not always supported, there is a delay of a
> > couple of seconds before the plug-in starts)
>
> This describe the behaviour of a subclass of all perl scripts. _Some_ C
> plug-ins behave the same, btw, as well.
>
> If you look at earlier discussions of this and related points you'll see that
> a seperate menu hierarchy hardly makes sense.
The same arguments apply to Script-Fu as well, however there is still
a separate menu hierarchy for these scripts. But maybe a separate
menu hierarchy is not the best solution...
> OTOH, I'd be all for some visible indication in the menus itself (although
> I am not 100% of wether that makes sense ;) It does not have any
> drawbacks, however).
I don't know if it makes sense, but I would like to have some kind of
indication before 1.2 is released. I was hoping that some people on
this list could reply with good suggestions...
> > for a vote or anything like that, but I would like to hear some
> > opinions... (no flames please)
>
> This has been discussed many times on this list already...
I know, but the final release of 1.2 is just around the corner now and
several things have changed since the last time these things were
discussed.
Also, I have the feeling that many people (not you, of course) do not
care too much about the Perl-Fu scripts and do not even test them. I
am sure that I am not the only one who is worried about the overall
consistency of the user interface, but I am surprised by the lack of
comments about Perl-Fu... Where are the "many eyeballs" that ensure
that "all bugs are shallow"?
-Raphael
Re: Perl-Fu plug-ins in 1.1.21
On Tue, May 02, 2000 at 08:15:44PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of > them abort with the following error displayed on the console: > > ** ERROR (recursed) **: could not find handler for message: 65536 > aborting... This happens to any plug-in that doesn't get recompiled when a protocol bump occurs. Recompiling the perl plug-in would fix that. > Marc, I suppose that you are aware of this and that you can fix it? If you give me a log-in on your machine I could fix it ;) > being mixed with the C plug-ins. Now it seems to be the contrary: the > Perl-Fu scripts are listed first in each menu, followed by the usual C > plug-ins. This is very distracting. Hmm... I wonder how the order in the menus is being worked out by the Gimp? Registration order? Alphabetical? Being able to control the sort order in some sensible way is highly desirable indeed, but will definitely not happen in 1.2 (IMHO it's very difficult). What happened in your case might have been that all the C-plug-ins (that were reinstalled) registered below the existing plug-ins and the perl-plug-ins (which you haven't reinstalled) moved to the top. > a menu is mapped to a C or Perl plug-in. They behave slightly > differently (e.g. undo is not always supported, there is a delay of a > couple of seconds before the plug-in starts) This describe the behaviour of a subclass of all perl scripts. _Some_ C plug-ins behave the same, btw, as well. If you look at earlier discussions of this and related points you'll see that a seperate menu hierarchy hardly makes sense. OTOH, I'd be all for some visible indication in the menus itself (although I am not 100% of wether that makes sense ;) It does not have any drawbacks, however). > for a vote or anything like that, but I would like to hear some > opinions... (no flames please) This has been discussed many times on this list already... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl-Fu plug-ins in 1.1.21
>While we are on it, could someone please check that all Perl scripts >register menu names with trailing dots if, and only if, they open a >dialog. Not a Perl script, but the About... menu entry shouldn't have the ellipsis, according to most GUI standards, since in this case opening a dialog is an end itself, not an intermediate step before the operation is performed.
Re: Perl-Fu plug-ins in 1.1.21
Hi, > But I also noticed that something else has changed in the Perl-Fu > scripts: in the previous versions that I tried (under Solaris), these > scripts were always registered at the bottom of the menus, instead of > being mixed with the C plug-ins. Now it seems to be the contrary: the > Perl-Fu scripts are listed first in each menu, followed by the usual C > plug-ins. This is very distracting. > > Would it be possible to avoid this? I would prefer to have the > Perl-Fu scripts separated from the C plug-ins. Either by adding a > separator in the menus, by adding a little mark next to their names, > or by creating a separate Perl-Fu menu similar to the Script-Fu menu. While we are on it, could someone please check that all Perl scripts register menu names with trailing dots if, and only if, they open a dialog. Salut, Sven
Perl-Fu plug-ins in 1.1.21
I tried to use the Perl-Fu scripts in 1.1.21 and I saw that all of them abort with the following error displayed on the console: ** ERROR (recursed) **: could not find handler for message: 65536 aborting... And this message is displayed in a pop-up box: [/path/to/script]: the gimp is using a newer version of the plug-in protocol than this plug-in. Marc, I suppose that you are aware of this and that you can fix it? I suppose that this was a consequence of the recent changes in the wire protocol. Hi Mitch! ;-) But I also noticed that something else has changed in the Perl-Fu scripts: in the previous versions that I tried (under Solaris), these scripts were always registered at the bottom of the menus, instead of being mixed with the C plug-ins. Now it seems to be the contrary: the Perl-Fu scripts are listed first in each menu, followed by the usual C plug-ins. This is very distracting. Would it be possible to avoid this? I would prefer to have the Perl-Fu scripts separated from the C plug-ins. Either by adding a separator in the menus, by adding a little mark next to their names, or by creating a separate Perl-Fu menu similar to the Script-Fu menu. I am asking for this on the list because I expect that many developers have different opinions about the placement of Perl-Fu scripts (or Python-Fu). I think that the Perl-Fu scripts "feel" different from the C plug-ins and it would be nice to know beforehand if an entry in a menu is mapped to a C or Perl plug-in. They behave slightly differently (e.g. undo is not always supported, there is a delay of a couple of seconds before the plug-in starts) and their parameters dialog have a different layout compared to most C plug-ins. I suppose that some of these differences (e.g. the Gimp-Perl logo in the dialogs) were introduced on purpose to make these scripts stand out from the others, but then why should they be mixed? I'm not asking for a vote or anything like that, but I would like to hear some opinions... (no flames please) -Raphael
Re: Query regarding my Gradient-Fu Patch
> BTW, the display of the cursor coordinates doesn't work well when using > pixmap themes. With Theme Engines (including the default theme) it works > OK. Does anybody knows what is the source of this problem and how to fix it? Upgrading gtk-engines to version >= 0.10 should fix this problem. Salut, Sven
Query regarding my Gradient-Fu Patch
Hi! Not long ago I wrote a patch to expose the functionality of the gradient editor to Script-Fu and Gimp::Fu scripts. The patch is available on my homepage (URL below). My question is if anybody commited this patch into the main development gimp source. If not, one should do it, because I'd like that functionality to be available in gimp version 1.2. So, what is the status of this patch? Regards, Shlomi Fish BTW, the display of the cursor coordinates doesn't work well when using pixmap themes. With Theme Engines (including the default theme) it works OK. Does anybody knows what is the source of this problem and how to fix it? -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ I don't believe in fairies. Oops! A fairy died. I don't believe in fairies. Oops! Another fairy died.
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
[snip] > I have just send a better bug report to the bugtracker, hoping that it > will help you to fix the bugs in the scripts. However, I see that the > form on Xach's site wraps the text in a very ugly way, so my nicely > formatted bug report is now very difficult to read (#7732). I will > send a copy of the bug report to you by private e-mail. I just changed it so it doesn't wrap at all. [snip] > > Well, I still think that I understood the situation quite well. ;-) > The difference between you and me is mostly a matter of opinion. I > consider that running the Perl-Fu scripts with the default values when > there is no Gtk is a bad thing (because of the warning box, because it > is difficult to guess what the script will do without seeing its > parameters, because there is no help, because some scripts disable the > undo on the image and because of the crashes that will hopefully be > fixed). So that's why I consider that installing these scripts when > Gtk is not present is a bug, or at least a disservice to the user. I > understand that you disagree and you would prefer to install them > anyway. Well, we can at least agree to disagree... I stuck a simple poll up regarding this a few days ago for the #gimp channel. Participation was rather light. Maybe with some exposure from the list, a more meaningful result could be determined: http://www.moviegroups.org/poll/one-poll.tcl?poll_id=22 Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Sun, 19 Mar 2000, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Mon, Mar 13, 2000 at 05:01:56PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: [...] > > So the current situation is: if you do not install the required Perl > > modules (especially Gtk.pm), most of the scripts do not produce any > > useful results. > > This is a bug that was easily fixed once I was told about it. If you had > filed a bug report on the gnome bugtracker, you would have been more than > right to complain (I cannot read it as often as I wished), but as it seems > you kept quiet until lately. OK, I should have used the bugtracker. Actually, I had a quick look at it some days ago (before sending my previous message) and I saw a few open bugs that were related to Perl scripts. I did not look at them (my connection was much too slow) and I though that they were reporting errors similar to the ones I saw, so I assumed that the problems were "well known". Well, I guess that I should double-check before I assume some things... [...] > > You could of course try to fix these crashes, because some of them > > look like real bugs in the scripts, but my message was not intended as > > a bug report.. > > I saw that, and I think this was very unfortunate :( OK. I should have spent a bit more time to make a complete bug report out of my message, instead of simply including the output from the crashes as an example. I spent some time testing all Perl-Fu scripts yesterday, so now I can send you a better bug report. [...] > I would guess reporting bugs in any way (I'd prefer mail on > gimp-developers or personal, to not clutter the list, but I understand the > need to scan the gnome bugtracker very well!) would help the situation > much more than asking for removing of plug-ins from the installation. Just > let the maintainer decide wether he can fix it, or wether the script > should be disabled, and bring the topic up when the maintaier (for > whatever reasons) does not do it. For example, when I was away and a > release needs to be made, disabling most or all of gimp-perl would be very > viable :) I have just send a better bug report to the bugtracker, hoping that it will help you to fix the bugs in the scripts. However, I see that the form on Xach's site wraps the text in a very ugly way, so my nicely formatted bug report is now very difficult to read (#7732). I will send a copy of the bug report to you by private e-mail. > > ... when this is clearly not true. I believe that I understand the > > situation very well and I thought that my previous message contained > > enough explanations to make this clear. > > However, I still don't believe you... ;) I didn't meant to insult you in > any way, I just wrote what I thought (and mostly still think). This is my > opinion. If I wrote it in an insulting way, let me apologize. It was not > what I intended. Well, I still think that I understood the situation quite well. ;-) The difference between you and me is mostly a matter of opinion. I consider that running the Perl-Fu scripts with the default values when there is no Gtk is a bad thing (because of the warning box, because it is difficult to guess what the script will do without seeing its parameters, because there is no help, because some scripts disable the undo on the image and because of the crashes that will hopefully be fixed). So that's why I consider that installing these scripts when Gtk is not present is a bug, or at least a disservice to the user. I understand that you disagree and you would prefer to install them anyway. Well, we can at least agree to disagree... > > Please, read my message again. This is _not_ what I suggested and I > > think that Sven and the others understood my message correctly. > > You did wrote this, whatever you really meant to write. And since you also > wrote verbosely about your reasoning (which was based on "facts" which were > wrong), I came to the conclusion that you lack a good enough understanding of > the situation. Well, I still don't understand why you think that my message was based on incorrect facts. I just re-read the first message that I posted in this thread, and I don't see any incorrect facts. You may think that the _conclusion_ is incorrect because I suggest to disable the installation of the scripts using some optional modules (e.g. Gtk) when these modules have not been downloaded from CPAN (even if the scripts can run with some default values when Gtk is not there). You may also think that it was wrong for me to suggest to disable the installation of "any (or most of the) Perl-Fu scripts" if the required modules are missing, but this is because most modules use Gtk (and, as I wrote before, they should be considered as requiring Gtk
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
not start this kind of action-reaction pattern. What makes it so bad is that I won't let FUD spread, regardless of what people might think of me. > that there are some problems. Whether these problems are technical, > philosophical or purely imaginary does not matter: the discussions I would guess reporting bugs in any way (I'd prefer mail on gimp-developers or personal, to not clutter the list, but I understand the need to scan the gnome bugtracker very well!) would help the situation much more than asking for removing of plug-ins from the installation. Just let the maintainer decide wether he can fix it, or wether the script should be disabled, and bring the topic up when the maintaier (for whatever reasons) does not do it. For example, when I was away and a release needs to be made, disabling most or all of gimp-perl would be very viable :) > To start with, it would be nice if you would not say something like the > following... > > > I do not mind if some people (like Raphael) make suggestions based on > > a wrong understanding of the situation. I am, however, astonished that > > even people like Sven, who _does_ _know_ _better_ takes it so lightly: > > ... when this is clearly not true. I believe that I understand the > situation very well and I thought that my previous message contained > enough explanations to make this clear. However, I still don't believe you... ;) I didn't meant to insult you in any way, I just wrote what I thought (and mostly still think). This is my opinion. If I wrote it in an insulting way, let me apologize. It was not what I intended. > Please, read my message again. This is _not_ what I suggested and I > think that Sven and the others understood my message correctly. You did wrote this, whatever you really meant to write. And since you also wrote verbosely about your reasoning (which was based on "facts" which were wrong), I came to the conclusion that you lack a good enough understanding of the situation. Even when we all know now your real intentions now, I don't see what not telling you about my conclusions would have helped: You posted something (which was wrong), and I posted what I think needed corrections. > why I wrote that "most" of them should be disabled. By "most", I mean What you actually wrote was this: "the configure script should skip the installation of the Perl-Fu scripts when...". You also wrote (later): "For these reasons, I think that it would be better to use the "safe" method: do not install any (or most of the) Perl-Fu scripts if..." What you might have wanted to write, and what you actually wrote, are two different things. "most" was mentioned as an alternative. I am sure that you didn't do this deliberately: _really_ (I mean, why should you? I do not always believe in the worst ;). Nevertheless what you write was wrong, and the conclusions very unfortunate and not very sensible. Your mail just reassures me that you were not intending what you wrote, but it does not really change what you very actually _did_ wrote. > all those that depend on a module that is not present. And as I wrote > above, a module that uses Gtk (even if it is optional) should be > considered as requiring it. This is fine. Now we all know it ;) Raphael, you didn't write this in your first mail, and there is nothing wrong with it: I just posted a correction, that's why this forum exists. I don't think there is anything to worry for you :( > For example, I do not have the AAlib on my PC. All I got is _one_ > warning during the "configure" step and then I never had to bother > with this again. Same with the MPEG library. I am probably missing Your comparison is flawed: most of the plug-ins I wrote, for example, do very sensible things in their default configurations (simple effects for example). The plug-ins you mentioned, however, do not even compile without the library. > > In any case, I would suggest to ignore Raphael's suggestion and > > concentrate on fixing existing bugs. > > Back to the facts: currently, anyone installing the Gimp on a "normal" > UNIX system (i.e. from any major Linux distribution, or Solaris, and > so on, that has perl but not the optional modules from CPAN) gets a > version of the Gimp in which a large number of options do not work. I > consider that as a serious bug. Well, then allow me the question of why you haven't bothered to treat it as such, and tell people so it can be fixed? What you did was asking for the respective plug-ins (actually, all of them) to be disabled, and, as a fortunate side-effect, you also posted something like a bug-report (with some wrong conclusions, but I take what I get). > Perl modules from CPAN (no Internet connection, no administrative > rights, wha
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Mon, Mar 13, 2000 at 05:47:37PM +0100, Uwe Koloska <[EMAIL PROTECTED]> wrote: > What about making an extra package with all perl-modules required to run Gimp Making packages is very much a distribution-only thing. So far, the most what gimp does is support making a single source tarball, and it also has a "sometimes-updated" gimp.specs file for makingrpm packages, maybe soon to be complemented wiht a suse version that has support for seperate python/perl etc.. packages. > the whole power of Gimp. Some addition to the ./configure could lead to a > message "You don't seem to have some important perl packages installed. If you Already happens. What was needed was a change of definition of "needed", after which everything becomes clear :) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
tile allocation and script-fu
Dear developers. I have two topics. 1. I was testing the data size limit in gimp-1.1.18. When I made 4100x4100 size layer and duplicated it for 64 times, I got the following error and GIMP had quited uncontrollably. ** WARNING **: cache: unable to find room for a tile ** WARNING **: cache: unable to find room for a tile GLib-ERROR **: could not allocate 16384 bytes aborting... /usr/local/gimp11/bin/gimp terminated: sigabrt caught This is because the file size of Linux-2.x is limited to 2G bytes. So that I cannot have a larger tile space than 2G (swap file size ) + 128MBytes (core memory) in my home PC. I wish I could get some notice window before quiting. It is much better that even in this case GIMP keeps alive and let me save other images (if any). Actually, I've got a notice window but I could not read it before the GIMP disappears. 2. In script-fu (I'm wearing a white belt) (gimp-layer-delete some-Layer) (gimp-displays-flush) evaluating these lines crashes the GIMP (1.1.18) immediately. with regards. FUJITA Yuji [EMAIL PROTECTED] http://www.wl.me.titech.ac.jp/~yuji/yuji-pubkey.asc
Re: fu ?
Dear developers. I thank all of you for quick reply to my questions. "fu" is from "kung-fu", which I never come to think of it. But now I see very well that a master of "something-fu" can wear a black belt. > http://film.gimp.org/ Thank you also for let me know about this project. I never minded about plug-ins. Now I see this is really a hard work... regards. FUJITA Yuji [EMAIL PROTECTED] http://www.wl.me.titech.ac.jp/~yuji/yuji-pubkey.asc
Re: fu ?
Raphael Quinet said... | |On Tue, 14 Mar 2000, FUJITA Yuji <[EMAIL PROTECTED]> wrote: |> 1. Does anyone know what "fu" is ? | |I think that it was a pun on "kung-fu". Not sure, though. It was. -Miles
Re: fu ?
On Tue, 14 Mar 2000, FUJITA Yuji <[EMAIL PROTECTED]> wrote:
> 1. Does anyone know what "fu" is ?
> I mean "script-fu", "perl-fu" or some kind of these names.
I think that it was a pun on "kung-fu". Not sure, though.
> 2. What is the biggest barriar to support 16bit depth in the GIMP ?
> I'm just reading xcf.c or tile.c and their related stuff and
> am in distress.
Many parts of the code assume that an image channel has exactly 8 bits.
For example, all paint operations (brushes, bucket fill, transforms...)
work on 8 bits. Changing that is already a huge amount of work. But
this also applies to all plug-ins: they will have to be re-written in
order to take several bit depths into account.
Maybe you should have a look at Gimp16 project ("Hollywood"). I do not
know the current status of the project (it looks like nothing happened
recently) but the Gimp16 homepage is at:
http://film.gimp.org/
-Raphael
fu ?
Hi, dear developers. I have two questions, maybe one of them is trifling. 1. Does anyone know what "fu" is ? I mean "script-fu", "perl-fu" or some kind of these names. 2. What is the biggest barriar to support 16bit depth in the GIMP ? I'm just reading xcf.c or tile.c and their related stuff and am in distress. regards. FUJITA Yuji [EMAIL PROTECTED] http://www.wl.me.titech.ac.jp/~yuji/yuji-pubkey.asc
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Raphael wrote on Mon, 13 Mär 2000: > >As an end-user, I prefer a stable application that may have less >features than another that has more features but that crashes or >complains that my system is not correctly configured. > Hey, this is, why the most of us don't use Windoze, I think ;-))) >Back to the facts: currently, anyone installing the Gimp on a "normal" >UNIX system (i.e. from any major Linux distribution, or Solaris, and >so on, that has perl but not the optional modules from CPAN) gets a >version of the Gimp in which a large number of options do not work. I >consider that as a serious bug. > >If a user does not have the opportunity to download and install the >Perl modules from CPAN (no Internet connection, no administrative >rights, whatever) then the best workaround for the moment is "make >uninstall ; configure --disable-perl ; make ; make install". This is >not a good solution. Yes, this is really not a good solution!!! What about making an extra package with all perl-modules required to run Gimp with all powerfull features? Someone (not me, because I don't even understand what happens while perl installs some package:-(() can package all needed Perl packages, make a simple but nice configuration (only install those packages not present) and give any user (not only the perl wizards) the possibility to use the whole power of Gimp. Some addition to the ./configure could lead to a message "You don't seem to have some important perl packages installed. If you wish to use Gimp with all it's power, grab 'gimp-perl-packages.tar.gz' and install it. Then run configure again." And (don't take this seriously ;))) this can solve a lot of documenation updates! Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
t it would be
better to skip the installation of those scripts if they cannot have a
user interface (besides the warning box). Without any user interface,
it is hard for a newcomer to know what the script is supposed to do
and what its parameters are. So even if this means reducing the
number of cool features available to the user, I prefer to skip the
installation of anything that appears to be obsure or confusing.
Especially because the user interface becomes a bit unpredictable: the
novice user does not know in advance which entry in the menu will
generate a warning and which one will work fine, because the Perl
scripts install themselves in many locations.
> I don't think that any other part of gimp got attacked in these ways so
> often than gimp-perl. I already have the feeling that gimp-perl bashing is
> some kind of sports.
Please, stop taking this personally! Maybe gimp-perl has been
discussed so often because of the way you reply to some messages and
because several people on this list tend to loose their temper a bit
to easily. If this is a hot topic, this indicates that there are some
problems. Whether these problems are technical, philosophical or
purely imaginary does not matter: the discussions indicate that some
people disagree and we should all (not only you) try to solve these
problems in the best possible way.
To start with, it would be nice if you would not say something like the
following...
> I do not mind if some people (like Raphael) make suggestions based on
> a wrong understanding of the situation. I am, however, astonished that
> even people like Sven, who _does_ _know_ _better_ takes it so lightly:
... when this is clearly not true. I believe that I understand the
situation very well and I thought that my previous message contained
enough explanations to make this clear. If not, I hope that this
message will help.
> On Wed, Mar 08, 2000 at 06:29:18PM +0100, Sven Neumann <[EMAIL PROTECTED]>
>wrote:
> > I second this suggestion.
>
> Sven, how can you second the suggestion to disable all perl scripts? I
> would think it would be quite insane to disable all plug-ins, just because
> configure found out that one of them does not run on this system?
Please, read my message again. This is _not_ what I suggested and I
think that Sven and the others understood my message correctly.
Although an easy solution to the problems with Perl-Fu scripts could
be to disable all of them, this solution is a bit extreme and that's
why I wrote that "most" of them should be disabled. By "most", I mean
all those that depend on a module that is not present. And as I wrote
above, a module that uses Gtk (even if it is optional) should be
considered as requiring it.
This is where we disagree. You seem to consider that providing these
scripts that can only run with the default values is a service to the
user (and as a bonus, it would encourage them to install the missing
Perl modules). I disagree because I think that they will confuse the
user and give them a bad opinion of the Gimp ("half-broken").
Especially when the user is not the one who installed the software.
For example, I do not have the AAlib on my PC. All I got is _one_
warning during the "configure" step and then I never had to bother
with this again. Same with the MPEG library. I am probably missing
some great features, but at least I have something that works well and
that does not remind me at run-time that I should install some missing
libraries.
As an end-user, I prefer a stable application that may have less
features than another that has more features but that crashes or
complains that my system is not correctly configured.
[... big snip ...]
> In any case, I would suggest to ignore Raphael's suggestion and
> concentrate on fixing existing bugs.
Back to the facts: currently, anyone installing the Gimp on a "normal"
UNIX system (i.e. from any major Linux distribution, or Solaris, and
so on, that has perl but not the optional modules from CPAN) gets a
version of the Gimp in which a large number of options do not work. I
consider that as a serious bug.
If a user does not have the opportunity to download and install the
Perl modules from CPAN (no Internet connection, no administrative
rights, whatever) then the best workaround for the moment is "make
uninstall ; configure --disable-perl ; make ; make install". This is
not a good solution. I was suggesting something else that would be
nicer for the user. Please do not dismiss this solution by claiming
(more or less) that I do not know what I am talking about. Ignoring
the problem and criticizing those who report it is not a good way to
solve it.
After we solve the installation problem, we could also solve the other
bugs that I detected (the fact that most scripts cannot run, even with
the default values). As I said, my previous message
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Hi, > I do not mind if some people (like Raphael) make suggestions based on a wrong > understanding of the situation. I am, however, astonished that even people > like Sven, who _does_ _know_ _better_ takes it so lightly: > > On Wed, Mar 08, 2000 at 06:29:18PM +0100, Sven Neumann <[EMAIL PROTECTED]> >wrote: > > I second this suggestion. > > Sven, how can you second the suggestion to disable all perl scripts? I > would think it would be quite insane to disable all plug-ins, just because > configure found out that one of them does not run on this system? I didn't second to disable installation of _all_ scripts. I just aggreed that scripts that are not working due to unfulfilled dependencies should not be installed. IMHO the lack of Perl-GTK is such a reason. > I'd say the current situation, i.e. install the plug-ins that _do_ work and > leave out the ones who don't work, should be fine. If this is the current situation, then I did not knew this. I must admit that in the last months I haven't tried to install gimp on systems that do not have all the necessary parts installed. If I did, I disabled Perl on configure. My experiences are probably not reflecting the current situation. Please excuse. Salut, Sven
Re: Suggestion: disabling Perl-Fu installation
FWIW I agree with Raphael, installing "scripts" which actually just blow up when run is pointless, if it can't at least manage to register itself with Gimp's PDB we shouldn't install it. Similarly, even if they did have "sensible defaults" the GUI scripts are not functional enough to be installed by default without Gtk.pm, last time I saw them they mostly defaulted to "do nothing" or only slightly better "do something visible but not very useful". Nick.
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Marc Lehmann wrote: > > Disabling all perl-plug-ins because somebody didn't want to check the > facts is, for me, a very big decision that should not be made lightly. I would be pleased if there were a message after ./configure that said... Some errors occured during ./configure. If you would like to use the perl plugins you will need to upgrade the following packages from the CPAN archive package1 package2 package etc... Then provide the URL to the CPAN site so folks who don't know what is can find it. Might also be cool to list the command for configuring without the perl stuff that way the user has a choice. I'm the type who will go and find the modules and install them to get the full power of the GIMP. -- Jon Winters visit the Obscura Lounge in OpenVerse http://www.openverse.org/
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
I just wanted to note that the suggestion of Raphael is based on assumptions that were either never true, or were true many months ago. Before all of you second his suggestions I would really appreciate it if people looked at the current situation. (I mean: think first!) Disabling all perl-plug-ins because somebody didn't want to check the facts is, for me, a very big decision that should not be made lightly. On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: > of all Perl-Fu scripts if any of the required modules (Gtk, PDL, No script will show up in the menu if it depends on something not installed. For PDL, the scripts won't be installed in the first place. Ok, povray is an exception, but since I didn't have time to work on it'll be better to disable it in 1.2 anyway. And, maybe, some script slipped through this. If that is the case just pretend it's a bug. 1. If PDL is missing, no scripts depending on it will be installed. I don't see why all the majority of scripts not using PDL should also be disabled. 2. If Data::Dumper is missing, some(!) scripts loose the ability to "RUN_WITH_LAST_VALS". I don't see why they should be disabled because of that. After all, perl5.004 is dead and I think it works extraordinarily good with that version despite that. 3. No plug-in depends on Parse::RecDescent. The installation of scm2perl (the only user) should be disabled - this is on my TODO. 4. Gtk is a major problem. I feel that an effect running with (sane) default arguments is better then no script at all. It costs just the same mouse-clicks to use these scripts. If people disagree then this is the place to discuss it. > Note that I am not criticizing the Gimp-Perl plug-in itself, only the > way the Perl-Fu scripts are installed. Yes, this is fine. I am still angry, for the following reasons: In the past it has happened very often that somebody suggest to disable gimp-perl in various ways, for reasons that ranged from "Marc isn't fast enough in fixing" over "Marc doesn't fix the bugs that were never reported" over "Perl is an ugly language" over "I am neglecting the situation and spread FUD" to "well, there are real problems not being addressed". The latter reason was rare, however :( I don't think that any other part of gimp got attacked in these ways so often than gimp-perl. I already have the feeling that gimp-perl bashing is some kind of sports. I do not mind if some people (like Raphael) make suggestions based on a wrong understanding of the situation. I am, however, astonished that even people like Sven, who _does_ _know_ _better_ takes it so lightly: On Wed, Mar 08, 2000 at 06:29:18PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > I second this suggestion. Sven, how can you second the suggestion to disable all perl scripts? I would think it would be quite insane to disable all plug-ins, just because configure found out that one of them does not run on this system? According to this logic, the lack of perl5.004 or higher should definitely result in NO plug-ins installed AT ALL. I'd say the current situation, i.e. install the plug-ins that _do_ work and leave out the ones who don't work, should be fine. > (because the user did not download them from CPAN), the Perl-Fu > scripts crash when the Gimp is started or when they are accessed from > the menus. This is indeed very bad. And I am absolutely determined to fix those bugs. However, are you _sure_ that these scripts are no left-overs from previous installations? In any case, I'd suggest reporting these problems: You can't expect problems to get fixed without notice. > - All other plug-ins take the "safe" approach of not installing > themselves if any dependency is not satisfied. gimp-perl _does_ this. Everything else is a bug, and two of these bugs (povray and scm2perl) are on my TODO. > As far as I know, the Perl plug-in is the only one that tries to What you "know" directly clashes with what I "know". > it is only some modules). So there is no reason to force the > installation of the Perl-Fu scripts if they could easily be > installed later, after having installed the missing modules. That's why the current situation (some scripts do not register themselves) will be addressed (again, look at my TODO). > - The Gimp takes 5 to 6 seconds longer to start if the required Perl > modules are missing, because some Perl-Fu scripts crash during > start-up and are queried again every time. See the first example This is a gimp bug, which I have reported a few times already (yes, also using the bug tracker(s!)). > Can't locate Gtk.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i586-linux >/usr/lib/perl5/5.00503 /usr/lib
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Hi, > Why can't those scripts just _not_register_themselves_ if the required > modules are not available? gimpmagick does this and the only problem > is that it has to be re-probed every time the GIMP starts. The only > reason I can think of to not install these scripts is to avoid the > delay at startup. The delay at startup for probing the scripts would IMHO be very annoying. I don't see why people wouldn't prefer to reinstall the perl parts after they installed missing packages. That's how it works for all other plug-ins (jpeg, tiff, ...). Salut, Sven
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Raphael Quinet wrote: > This has been suggested before, but I would like to bring it up > again... I think that it would be better to disable the installation > of all Perl-Fu scripts if any of the required modules (Gtk, PDL, > Data::Dumper, Parse::RecDescent) are not detected by the configure > script or, more exactly, by Makefile.PL. Oh yes, please. I'm fairly sure that a working gimp-perl installation is wonderful, but I can vouch that a semi-disabled installation is definitely hair-rippingly more painful than a completely-disabled one. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "Due to recently uncovered copyright restrictions, Bucketheadland is no longer able to employ the man dressed in the Leatherface costume. If you see him in the park please contact Bucketheadland security immediately."
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Hi, > This has been suggested before, but I would like to bring it up > again... I think that it would be better to disable the installation > of all Perl-Fu scripts if any of the required modules (Gtk, PDL, > Data::Dumper, Parse::RecDescent) are not detected by the configure > script or, more exactly, by Makefile.PL. I second this suggestion. Salut, Sven
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Wed, 8 Mar 2000, Tom Rathborne <[EMAIL PROTECTED]> wrote: > Why can't those scripts just _not_register_themselves_ if the required > modules are not available? gimpmagick does this and the only problem > is that it has to be re-probed every time the GIMP starts. The only > reason I can think of to not install these scripts is to avoid the > delay at startup. Yes, and this "only reason" is quite significant for me. On a multi-user system that mounts all Gimp files over NFS, querying all plug-ins and scripts at startup takes more than 40 seconds (depending on the network and server load) with a default installation of 1.1.18. This is much too slow, but fortunately this is a one-time thing and after that everything runs smoothly. After the first run, the Gimp starts in about 10 seconds (5 of these are taken by Script-Fu). If more scripts would be queried every time at startup, the delay in starting the Gimp would be unacceptable. Fortunately the situation is a bit better on a single-user system or a system which has all files on a local disk, but I think that any additional delays during startup should be avoided. This means that it is better to skip the installation of a script or plug-in that has some unsatisfied dependencies than to install it anyway at the expense of some additional startup delays. -Raphael
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Wed, Mar 08, 2000 at 05:40:44PM +0100, Raphael Quinet wrote: > On Wed, 8 Mar 2000, Seth Burgess <[EMAIL PROTECTED]> wrote: > > As far as PDL and Gtk goes, I'm in agreement that it shouldn't > > install those scripts with those dependencies uless those packages > > are detected. gimptool should be able to install them later for > > users wishing to upgrade later - its the way everything else in > > gimp works. > > I'm glad to see that someone agrees... :-) Why can't those scripts just _not_register_themselves_ if the required modules are not available? gimpmagick does this and the only problem is that it has to be re-probed every time the GIMP starts. The only reason I can think of to not install these scripts is to avoid the delay at startup. Regards, Tom -- --Tom Rathborne[EMAIL PROTECTED] -- http://www.aceldama.com/~tomr/ --"All that glitters is not gold; all that wander are not lost."
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet wrote: > This has been suggested before, but I would like to bring it up > again... I think that it would be better to disable the installation > of all Perl-Fu scripts if any of the required modules (Gtk, PDL, > Data::Dumper, Parse::RecDescent) are not detected by the configure > script or, more exactly, by Makefile.PL. Parse::RecDescent is used only by the script-fu to perl-fu converter, AFIAK. I get Data::Dumper installed as part of perl-base. If there's a perl distro without that, it probably won't be terribly useful for developing perl based scripts (guessing). In any case, if Parse::RecDescent is affecting running of any plug-ins, I'd call that a bug. As far as PDL and Gtk goes, I'm in agreement that it shouldn't install those scripts with those dependencies uless those packages are detected. gimptool should be able to install them later for users wishing to upgrade later - its the way everything else in gimp works. > perlotine: the gtk perl module is required to open a dialog > window, running with default values (perl_fu_perlotine) > perlotine: No horizontal or vertical guides found. Aborted. at >/usr/lib/gimp/1.1/plug-ins/perlotine line 176. (ERROR) This error anyway is legit - you need guides to run perlotine! It would tell you so in a dialog box, but its not availble for lack of Gtk. In this case, I think the commandline is pretty clear. Were the color related PDB errors pre or post Gimp-Edit-Fill changes? Seth Burgess [EMAIL PROTECTED]
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Wed, 8 Mar 2000, Seth Burgess <[EMAIL PROTECTED]> wrote: > On Wed, Mar 08, 2000 at 01:07:52PM +0100, Raphael Quinet wrote: > > This has been suggested before, but I would like to bring it up > > again... I think that it would be better to disable the installation > > of all Perl-Fu scripts if any of the required modules (Gtk, PDL, > > Data::Dumper, Parse::RecDescent) are not detected by the configure > > script or, more exactly, by Makefile.PL. > > Parse::RecDescent is used only by the script-fu to perl-fu converter, > AFIAK. I get Data::Dumper installed as part of perl-base. If there's > a perl distro without that, it probably won't be terribly useful for > developing perl based scripts (guessing). In any case, if > Parse::RecDescent is affecting running of any plug-ins, I'd call that > a bug. If Parse::RecDescent is not needed for "normal users", i.e. those who do not have to use scm2perl or scm2scm, then maybe the Makefile.PL should not complain about it. The Gimp configure script does not complain if perl is missing, although it is required for developers who want to use the pdbgen. But this is a minor issue. As for Data::Dumper, it is indeed part of the default perl installation, but I think that some versions older than 5.005 had it as an option only. I do not know which versions exactly, but I know that I had to install the Gimp on some systems that had an old (and probably buggy) version of perl without Data::Dumper. > As far as PDL and Gtk goes, I'm in agreement that it shouldn't > install those scripts with those dependencies uless those packages are > detected. gimptool should be able to install them later for users > wishing to upgrade later - its the way everything else in gimp works. I'm glad to see that someone agrees... :-) > > perlotine: the gtk perl module is required to open a dialog > > window, running with default values (perl_fu_perlotine) > > perlotine: No horizontal or vertical guides found. Aborted. at >/usr/lib/gimp/1.1/plug-ins/perlotine line 176. (ERROR) > > This error anyway is legit - you need guides to run perlotine! It would > tell you so in a dialog box, but its not availble for lack of Gtk. In > this case, I think the commandline is pretty clear. That's right. Sorry, that was a bad example. I should try that script again with some guides defined. > Were the color related PDB errors pre or post Gimp-Edit-Fill changes? > I captured most of these errors yesterday just after installing gimp-1.1.18 and before re-applying my gimp_edit_fill() patches. So these come from an unmodified 1.1.18 distribution. -Raphael
Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
This has been suggested before, but I would like to bring it up again... I think that it would be better to disable the installation of all Perl-Fu scripts if any of the required modules (Gtk, PDL, Data::Dumper, Parse::RecDescent) are not detected by the configure script or, more exactly, by Makefile.PL. The argument for installing the scripts anyway is that the user can install the missing modules later. However, I think that it currently does more harm than good. Note that I am not criticizing the Gimp-Perl plug-in itself, only the way the Perl-Fu scripts are installed. I have installed the Gimp on many systems (Linux and Solaris) and the Perl-Fu scripts are working fine on the systems that have perl and all the required modules. But on the systems that do not have perl (it comes with all Linux distros but it is optional) or those that do not have the required modules (because the user did not download them from CPAN), the Perl-Fu scripts crash when the Gimp is started or when they are accessed from the menus. This makes a bad impression and the best solution is usually to uninstall everything, then re-configure with --disable-perl, re-compile and re-install. This extra hassle should not be necessary. Here are a few reasons why I think that the configure script should skip the installation of the Perl-Fu scripts if any of the required modules is missing: - All other plug-ins take the "safe" approach of not installing themselves if any dependency is not satisfied. As far as I know, the Perl plug-in is the only one that tries to install everything and hope that the user will install the missing things later. - I think that most users are updating the Gimp (re-compiling, re-installing) more frequently than they are updating Perl (even if it is only some modules). So there is no reason to force the installation of the Perl-Fu scripts if they could easily be installed later, after having installed the missing modules. One reason for updating the Gimp more frequently is that it is easier to get a single tar file for the Gimp than to have to search for separate modules on CPAN, especially on a computer that has no direct connection to the Internet. Another example: on a multi-user system, the user may not have the required priviledges for installing the Perl modules in the system directories (although the modules could be installed in a private directory if the users take care of modifying their environment.) - The Gimp takes 5 to 6 seconds longer to start if the required Perl modules are missing, because some Perl-Fu scripts crash during start-up and are queried again every time. See the first example included below. Besides, these crashes are not very informative for the user if he is not the one who installed the software and who knows what these messages mean. - The modules that do not crash during start-up will fail anyway when they are used. Except for some things such as the Perl Server, I haven't found a script that was usable without Gtk-Perl. When I attempted to use these scripts, they all started by popping up a dialog box that warns about the missing module, then start some operations and crash before producing any result (which brings another dialog box for reporting the error). Again, for a user who is not the installer, it only makes the Gimp look bad because the menus are cluttered with unusable entries that do nothing else than popping up error boxes. See the second example below. For these reasons, I think that it would be better to use the "safe" method: do not install any (or most of the) Perl-Fu scripts if the required modules are missing during the "configure" phase. And rely on the fact that the person who installed the Gimp will re-install it easily if the Perl modules are installed later. -Raphael -- Example 1 -- Here are the messages that are displayed every time the Gimp starts, taking 5-6 seconds on a Linux PC that has perl but does not have the required modules from CPAN: Can't locate Gtk.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i586-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i586-linux /usr/lib/perl5/site_perl/5.005 .) at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/gimp/1.1/plug-ins/avi line 10. ** WARNING **: wire_read: unexpected EOF (plug-in crashed?) Can't locate Gtk.pm in @INC (@INC contains: /usr/lib/perl5/5.00503/i586-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i586-linux /usr/lib/perl5/site_perl/5.005 .) at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.005/i586-linux/Gimp/UI.pm line 5. BEGIN failed--compilation aborted at /usr/lib/gi
Some Python-fu Plugins fail with a nonstandard python installation. Fix attached.
[This should go to [EMAIL PROTECTED], but this complained about a missing Package-header. Can't the tracking System handle Mime-Mails?] Package: gimp Version: CVS from 19.2.2000 2 Python scripts fail to start with a nonstandard python installation since the path to /usr/bin/python is hardcoded there. The attached patch fixes this by using "#!/usr/bin/env python" (as usual). The diff was created in $GIMPSRC/plug-ins/pygimp/plug-ins/ Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ Index: pdbbrowse.py === RCS file: /cvs/gnome/gimp/plug-ins/pygimp/plug-ins/pdbbrowse.py,v retrieving revision 1.1 diff -r1.1 pdbbrowse.py 1c1 < #!/usr/bin/python --- > #!/usr/bin/env python Index: sphere.py === RCS file: /cvs/gnome/gimp/plug-ins/pygimp/plug-ins/sphere.py,v retrieving revision 1.1 diff -r1.1 sphere.py 1c1 < #!/usr/bin/python --- > #!/usr/bin/env python
Re: What should I change in Script-Fu scripts? (Summary)
Sorry, busy ending exams, now processing postponed things: > A3) Add a new parameter to the dialog box so that the color has to > be specified explicitely. >Almost everybody supports A3) so I will implement that. Everybody + 1. > B3) Add a "flatten image?" option to all scripts, defaults to FALSE. > B4) Never flatten, but rely on the Export mechanism (it works well). >For this, I got mixed opinions. Several people support B3, but I >also received two suggestions to use B4. More opinions are needed... If it works really well, use the Export mechanism. More buttons if you can do at save time (after changing things), no thanks. > C2) Use "The Gimp" as the default text in all scripts > C2b)Use "The Gimp" and adjust the font size so that all scripts > generate an image of comparable size when run with the default > parameters. > C3) Use the script name. >Here, this is a 50%-50% match between C1 and C2 (or C2b). More >opinions are needed... C2 with same font size, so you get the idea about how big a font is (damn font sizes... there could be a standard, no?). >My personal opinion (in order to bias the votes towards C2b :-)) is >that the first thing that most users will do when they want to produce >a logo is to change the text (of course!) and some of the other >parameters. But before creating a real logo with these scripts, it is >useful to run all of them quickly with the default parameters in order >to get an idea of what these scripts are doing. Running them quickly >means not having to change the defaults. It is much easier to compare >the results if the images have similar sizes and contain more or less >the same text. Currently, this is not easy because you have the >"Textured" logo using the default string "The GIMP" at 200 pixels >while the "Bovinated" logo uses the longer string "Fear the Cow" at 80 >pixels and the "Comic" logo uses the short string "Moo" at 85 pixels. I see you point, another C2b, "The Gimp" with same pixel size. > D2) Add the "padding" parameter to the scripts that create a > textured background. >Most people seem to support D2, so I will implement that. Most people + 1. GSR
Re: What should I change in Script-Fu scripts?
On Thu, 17 Feb 2000, Sven Neumann wrote: > The idea to have another menu entry is IMHO a good one and better then > adding a new preferences option. But please do not use a script or > another weird hack that changes the fg/bg for the fill, then restores > it later. Better add a fill_type parameter to the internal edit_fill() > function and default to FOREGROUND_FILL for the PDB call. I like this, but as I proposed before, I believe leaving Ctrl-. bound to fill-with-bg would be a good idea (since I don't know of anybody going to the menu option on a regular basis...). It would be intuitive (IMHO) to bind Ctrl-, to fill-with-fg; it occurrs to me that being able to do both easily might be useful, without swapping colors. --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Re: What should I change in Script-Fu scripts?
On Thursday, 17 Feb 2000, Raphael Quinet wrote: > My 0.02 Euro: I would like to change the Edit->Fill behaviour globally > and at the same time provide a three-lines script (or code in the > core) that would register itself as "Edit->Fill with BG" and would > swap the colors, call gimp-edit-fill and restore the colors again. So > those who prefer the current behaviour could bind Ctrl-. to it. Yes. Austin
Re: What should I change in Script-Fu scripts? (Summary)
I received several replies to my opinion poll, by private e-mail or on this list. Here is a summary of what I got so far: About changing the scripts that call gimp-edit-fill without setting the colors first (thus taking the current color in use): A1) No change to the scripts (they would then use the fg color) A2) Swap foreground and background A3) Add a new parameter to the dialog box so that the color has to be specified explicitely. Almost everybody supports A3) so I will implement that. About flattening the image or not: B1) No change to the scripts B2) Add a "flatten image?" option to all scripts, defaults to TRUE. B3) Add a "flatten image?" option to all scripts, defaults to FALSE. B4) Never flatten, but rely on the Export mechanism (it works well). For this, I got mixed opinions. Several people support B3, but I also received two suggestions to use B4. More opinions are needed... About the default text string in the logo scripts: C1) No change to the scripts C2) Use "The Gimp" as the default text in all scripts C2b)Use "The Gimp" and adjust the font size so that all scripts generate an image of comparable size when run with the default parameters. C3) Use the script name. Here, this is a 50%-50% match between C1 and C2 (or C2b). More opinions are needed... My personal opinion (in order to bias the votes towards C2b :-)) is that the first thing that most users will do when they want to produce a logo is to change the text (of course!) and some of the other parameters. But before creating a real logo with these scripts, it is useful to run all of them quickly with the default parameters in order to get an idea of what these scripts are doing. Running them quickly means not having to change the defaults. It is much easier to compare the results if the images have similar sizes and contain more or less the same text. Currently, this is not easy because you have the "Textured" logo using the default string "The GIMP" at 200 pixels while the "Bovinated" logo uses the longer string "Fear the Cow" at 80 pixels and the "Comic" logo uses the short string "Moo" at 85 pixels. About adding a "padding" parameter to the scripts: D1) No change to the scripts D2) Add the "padding" parameter to the scripts that create a textured background. Most people seem to support D2, so I will implement that. -Raphael
Re: What should I change in Script-Fu scripts?
> My 0.02 Euro: I would like to change the Edit->Fill behaviour globally > and at the same time provide a three-lines script (or code in the > core) that would register itself as "Edit->Fill with BG" and would > swap the colors, call gimp-edit-fill and restore the colors again. So > those who prefer the current behaviour could bind Ctrl-. to it. The idea to have another menu entry is IMHO a good one and better then adding a new preferences option. But please do not use a script or another weird hack that changes the fg/bg for the fill, then restores it later. Better add a fill_type parameter to the internal edit_fill() function and default to FOREGROUND_FILL for the PDB call. Salut, Sven
Re: What should I change in Script-Fu scripts?
On Wed, 16 Feb 2000, Glyph Lefkowitz <[EMAIL PROTECTED]> wrote: > Why are you bothering to change this behavior (edit/fill) when it makes > sense to 1/2 of the people who use GIMP, it's a historical precedent in > terms of the UI, and it's a huge amount of work to get to function > correctly? Are there not enough bugs in the gimp that need to be > fixed that more twiddling like this needs to be done? The "fill with background" behaviour is a historical precedent in terms of the _Gimp_ UI. But most of the other programs that I tried are using the foreground color. So although some of the old users who use Ctrl-. frequently might be confused if the Gimp starts to behave like other programs, this should be a good thing for most of the new users. Besides, why should we have a Fill Tool that fills with the foreground color by default and an Edit->Fill menu that fills with the background color? Even if we end up making this option configurable, I would like the defaults to be consistent. Regarding the "huge amount of work", I would say that this is a tedious task but it is not hard to get it to function correctly. On the other hand, this allowed me to see that some scripts had a number of bugs that had not been reported yet: for example the "3D Truchet" script does not restore the colors correctly upon exit. Another script (I forgot which one) creates a layer, fills it with the current color, and then "forgets" to use it in the image. On Thu, 17 Feb 2000, Sven Neumann <[EMAIL PROTECTED]> wrote: > > Sven, thanks for clearing that up. > > Well, it's not yet cleared up since we'll first have to agree if we want > to change the Edit->Fill behaviour globally or not. My 0.02 Euro: I would like to change the Edit->Fill behaviour globally and at the same time provide a three-lines script (or code in the core) that would register itself as "Edit->Fill with BG" and would swap the colors, call gimp-edit-fill and restore the colors again. So those who prefer the current behaviour could bind Ctrl-. to it. -Raphael
Re: What should I change in Script-Fu scripts?
> > Cleaning up the scripts and providing a more consistent set of parameters > > looks like a very important job to me and I'm glad that Raphael wants to > > take it. I'm not yet convinced that changing the Edit->Fill behaviour is > > really useful. Probably we should keep the current behaviour as it will > > keep us from introducing more bugs and add another Preferences option that > > only affects the GUI... > > Okay I can understand that. I guess I must have misunderstood the > implication of changing the parameters that scripts execute. And yes, > thank you, Raphael, for taking a menial job that most people wouldn't want > to do and handling it =) > > Sven, thanks for clearing that up. Well, it's not yet cleared up since we'll first have to agree if we want to change the Edit->Fill behaviour globally or not. Salut, Sven
Re: What should I change in Script-Fu scripts?
On Wed, 16 Feb 2000, Sven Neumann wrote: > Glyph Lefkowitz send this message privately, but I'd like to move > the discussion back onto the list. I hope that OK with him... Yep, it's fine with me... [snip personal complaining] > Cleaning up the scripts and providing a more consistent set of parameters > looks like a very important job to me and I'm glad that Raphael wants to > take it. I'm not yet convinced that changing the Edit->Fill behaviour is > really useful. Probably we should keep the current behaviour as it will > keep us from introducing more bugs and add another Preferences option that > only affects the GUI... Okay I can understand that. I guess I must have misunderstood the implication of changing the parameters that scripts execute. And yes, thank you, Raphael, for taking a menial job that most people wouldn't want to do and handling it =) Sven, thanks for clearing that up. --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Re: What should I change in Script-Fu scripts?
Glyph Lefkowitz send this message privately, but I'd like to move the discussion back onto the list. I hope that OK with him... > Why are you bothering to change this behavior (edit/fill) when it makes > sense to 1/2 of the people who use GIMP, it's a historical precedent in > terms of the UI, and it's a huge amount of work to get to function > correctly? Are there not enough bugs in the gimp that need to be > fixed that more twiddling like this needs to be done? > > In case you couldn't tell, :-) I am personally bothered by the change, > since I typically use a foreground paint-tool, such as the airbrush, and > fill areas with Ctrl-. in a different color. This will result in an extra > keystroke, and I'm sure it will confuse me for months to come, as it will > other gimp users who are used to the old behaviour... so the work to > change all these script calls seems not only generally wasteful, it is > actually harmful in some cases... is there some technical reason why this > way would be better... Cleaning up the scripts and providing a more consistent set of parameters looks like a very important job to me and I'm glad that Raphael wants to take it. I'm not yet convinced that changing the Edit->Fill behaviour is really useful. Probably we should keep the current behaviour as it will keep us from introducing more bugs and add another Preferences option that only affects the GUI... Salut, Sven
Re: What should I change in Script-Fu scripts?
On Wed, 16 Feb 2000, Sven Neumann <[EMAIL PROTECTED]> wrote: [...] > > B2) Add a "flatten image?" option in all scripts, with the default > > value set to TRUE. > > B3) Add a "flatten image?" option in all scripts, with the default > > value set to FALSE. > > B4) Remove all calls to gimp-image-flatten as well as the option to > > flatten the image in the scripts that already have it, because it > > is not so important to have this option anymore. [...] > B2 or B3. I'm not sure if Flatten=TRUE is a reasonable default. Why hide > the beauty of layers and masks? OK. I'll go for B3 then. > > C1) Leave all scripts as they are. Diversity is fun. Besides, who > > am I to decide what the default text should be? Each author has > > the right to decide what is best. > > C2) Change all logo scripts to use "The Gimp" as the default text (or > > only "GIMP" for those such as "Alien Glow" that look better in all > > caps). [...] > C1. I don't see why you would want to change the default text the > script author has choosen. Using the same string all over the place > doesn't give any real advantage. Well, I think that it does have two advantages: you can easily compare the effects of several scripts on the same string, and that string contains a reasonable mix of letters (e.g. you could check if anything strange happens near the descender in the "p"). Hmmm... On the other hand, in order to make the comparison between scripts even better, maybe I should also change the default font size. Changing the font itself is not a good idea (many scripts produce much better logos with their default font because they were designed for it) but changing the default font size might be good. My goal would be that a user could try a script with the default values, then switch to another script and get something that is comparable: same text and same overall size. Currently, the user has to change the default values in most scripts in order to be able to compare them side-by-side. OK, so let's see who likes this new option: C2b) Change all logo scripts to use "The Gimp" as the default text and to use a font size such that the resulting images would have comparable sizes (of course the font size to use for each script would depend on some features of the default font, which would not be changed) -Raphael
Re: What should I change in Script-Fu scripts?
Raphael Quinet wrote:
>
> There are several ways to fix these scripts, and I would like to get
> your opinions about this:
>
>
> A3) Add a new parameter ("background color") to the script so that it
> uses the value specified in the dialog box instead of using the
> current colors.
>
> B3) Add a "flatten image?" option in all scripts, with the default
> value set to FALSE.
There was recent discussion about a script user who wanted to
do subsequent modifications, but was faced with the tricky
prospect of making an intricate mask; advise to the user was
"edit the script to eliminate final flattening step." This should
reduce the liklihood of that.
> C2) Change all logo scripts to use "The Gimp" as the default text (or
> only "GIMP" for those such as "Alien Glow" that look better in all
> caps).
Literally "The Gimp" provides a l/c ascender, "h" a descender, "p"
and capital letters "T,G" so something is touching on the cap height,
ascender, and descender horizontals. That, I think, would be a good
set of visual cues for planning layouts.
>
> D2) Add a "padding" parameter to these scripts, so that it is possible
> to specify a number of padding pixels around the text.
>
> P.S.: Hmmm... I think that I spent more time writing this message than
> I would have spent making these changes to the code without
> asking...
Ah, but consider how you sharpened your mind while considering
all the design issues...;)
Be good, be well
Garry Osgood
Re: What should I change in Script-Fu scripts?
Hi,
> A1) Do not change anything in these calls to gimp-edit-fill, which
> means that these scripts would now create a background layer
> that is filled with the current foreground color.
> A2) Keep the current behavior by adding something like
> (gimp-palette-set-foreground (car (gimp-palette-get-background)))
> before filling the layer, or by changing the layer creation mode
> so that it is directly created with the current background color
> instead of being created transparent and then filled later.
> A3) Add a new parameter ("background color") to the script so that it
> uses the value specified in the dialog box instead of using the
> current colors.
A3. If you have to do something like A2, please remember to reset the
colors you changed when the script is done.
> B1) Leave the scripts as they are now, even if there are some
> inconsistencies.
> B2) Add a "flatten image?" option in all scripts, with the default
> value set to TRUE.
> B3) Add a "flatten image?" option in all scripts, with the default
> value set to FALSE.
> B4) Remove all calls to gimp-image-flatten as well as the option to
> flatten the image in the scripts that already have it, because it
> is not so important to have this option anymore. In previous
> versions of the Gimp, it was useful for the scripts to flatten the
> image so that the users would not have to remember to do it (and
> risk loosing part of their work) before saving the result as a GIF
> or JPEG image. But the current version will automatically ask if
> the image has to be flattened before saving it, so the risk of
> saving the wrong layer and loosing some data is greatly reduced.
> So maybe we could remove the flatten option from the scripts?
B2 or B3. I'm not sure if Flatten=TRUE is a reasonable default. Why hide
the beauty of layers and masks?
> C1) Leave all scripts as they are. Diversity is fun. Besides, who
> am I to decide what the default text should be? Each author has
> the right to decide what is best.
> C2) Change all logo scripts to use "The Gimp" as the default text (or
> only "GIMP" for those such as "Alien Glow" that look better in all
> caps).
> C3) Change all scripts to use their name (or a part of it) as the
> default text.
> C4) Change all scripts to use "Moo!".
> C5) Or maybe "SCRIPT-FU" as in the "Basic II" script?
C1. I don't see why you would want to change the default text the
script author has choosen. Using the same string all over the place
doesn't give any real advantage.
> And finally, some scripts such as "Carved" or "Textured" are using a
> background texture that cannot be easily extended if the logo has to
> be integrated in a larger image. So you have to take the background
> as it is, or do a lot of hand-editing if you want the background
> texture to cover a larger area. Although this is a new feature, I was
> thinking about adding a "padding" option to some of these scripts.
> This would allow you to specify some extra padding around the text, so
> that you could have a larger background if necessary. Do you think
> that I should:
>
> D1) Forget this idea and leave the scripts as they are.
> D2) Add a "padding" parameter to these scripts, so that it is possible
> to specify a number of padding pixels around the text.
D2. If it works, go for it.
Salut, Sven
What should I change in Script-Fu scripts?
Yesterday evening, I started to edit the Script-Fu scripts so that
they fill with the foreground color instead of the background color.
There are 215 calls to gimp-edit-fill in the scripts delivered with
Gimp 1.1.17, and most of them are preceded by a call to
gimp-palette-set-background, which can easily be replaced by
gimp-palette-set-foreground in order to get the correct behavior.
However, I found a couple of logo scripts that are filling the
selection without setting the color first; they take the background
color that is currently in use when the script is run. You can see
this effect with the "Bovination" and "Comic Book" script, for
example: set the background color to pink or something easily visible,
then run the scripts and look at the results.
There are several ways to fix these scripts, and I would like to get
your opinions about this:
A1) Do not change anything in these calls to gimp-edit-fill, which
means that these scripts would now create a background layer
that is filled with the current foreground color.
A2) Keep the current behavior by adding something like
(gimp-palette-set-foreground (car (gimp-palette-get-background)))
before filling the layer, or by changing the layer creation mode
so that it is directly created with the current background color
instead of being created transparent and then filled later.
A3) Add a new parameter ("background color") to the script so that it
uses the value specified in the dialog box instead of using the
current colors.
I think that the last solution is the best one, but of course it
changes the interface.
And if I am changing the interface, there is another thing that might
be worth changing in the logo scripts: should they flatten the final
image or not? Some scripts silently flatten (parts of) the final
image, some others provide this as an option (a "flatten image?" check
box), and some others always leave all layers in the final image. I
would like to make them a bit more consistent. Again, there are
several options:
B1) Leave the scripts as they are now, even if there are some
inconsistencies.
B2) Add a "flatten image?" option in all scripts, with the default
value set to TRUE.
B3) Add a "flatten image?" option in all scripts, with the default
value set to FALSE.
B4) Remove all calls to gimp-image-flatten as well as the option to
flatten the image in the scripts that already have it, because it
is not so important to have this option anymore. In previous
versions of the Gimp, it was useful for the scripts to flatten the
image so that the users would not have to remember to do it (and
risk loosing part of their work) before saving the result as a GIF
or JPEG image. But the current version will automatically ask if
the image has to be flattened before saving it, so the risk of
saving the wrong layer and loosing some data is greatly reduced.
So maybe we could remove the flatten option from the scripts?
There are some other inconsistencies in the logo scripts: they use
different values for the default text string to be used in the logo.
Ten of them use "The GIMP" or "The Gimp" as the default text; five of
them use "Hello world!" some of them use some text related to the name
or function of the script (e.g. "Alien Glow" uses "ALIEN", "Carved"
uses "Marble") and the others use something unrelated to the name of
the script (e.g. "Comic Book" and "Gradient Bevel" use "Moo"). If I
have to change all scrips anyway, maybe I could make them more
consistent? Time for another opinion poll...
C1) Leave all scripts as they are. Diversity is fun. Besides, who
am I to decide what the default text should be? Each author has
the right to decide what is best.
C2) Change all logo scripts to use "The Gimp" as the default text (or
only "GIMP" for those such as "Alien Glow" that look better in all
caps).
C3) Change all scripts to use their name (or a part of it) as the
default text.
C4) Change all scripts to use "Moo!".
C5) Or maybe "SCRIPT-FU" as in the "Basic II" script?
And finally, some scripts such as "Carved" or "Textured" are using a
background texture that cannot be easily extended if the logo has to
be integrated in a larger image. So you have to take the background
as it is, or do a lot of hand-editing if you want the background
texture to cover a larger area. Although this is a new feature, I was
thinking about adding a "padding" option to some of these scripts.
This would allow you to specify some extra padding around the text, so
that you could have a larger background if necessary. Do you think
that I should:
D1) Forget this idea and leave the scripts as they are.
D2) Add a "paddi
Gradient-Fu Patch for The Gimp v. 1.1.x
I prepared a version of my Gradient-Fu patch that is compatible with version 1.1.x of the GIMP. As a reminder, Gradient-Fu adds PDB procedures that can manipulate gradients, so scripts and plug-ins can create and modify gradients. The patch can be downloaded from my homepage at the following URL: http://t2.technion.ac.il/~shlomif/ Read the instructions in the README file. I ask that someone with write access to the GIMP's CVS server to apply those patches to his source tree, check that everything is working, and permanently add them to the GIMP's source. Regards, Shlomi Fish -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.
script-fu maintained?
Is script-fu still maintained? Many people complain that script-fu can't be called via the pdb (** WARNING **: unexpected proc return message received (should not happen)). This has been the case since 1.0. It worked for a very short time, but most of the time it was broken in different ways. May I "officially" declare script-fu as not scriptable to those who ask, or should I tell them to wait until this is fixed (I mean, if it is before 2002). TIA, Marc -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Bug in script-fu (patch)
Parameters passed to gtk_init is not initialized and lead to crash. Related to gimp versions: 1.1.11, 1.1.12; - ptr diff -r gimp-1.1.12/plug-ins/script-fu/script-fu-scripts.c gimp-1.1.12.old/plug-ins/script-fu/script-fu-scripts.c 1078a1079,1080 > gchar **argv; > gint argc; 1091c1093 < gtk_init (0,0); --- > gtk_init (&argc, &argv);
Re: Script-Fu Error
On Fri, 22 Oct 99 19:33:20, Asbjoern Pettersen wrote:
>>
>>I 'cvs update'd again, recompiled, and everything works fine now. I can
>>even run plugins which use fonts! However, clicking twice on the font
>>button will still crash script-fu, although selecting a font and running
>>the script will not crash until the script is finished running and script
>>fu cleans up its widgets. This makes script-fu functional for me again,
>>even if I have to restart the Gimp every time I run a script that uses a
>>fontselector :)
>
>I've been debug on OS/2 version and it crash when the font dialog is destroyed.
>
>It's in function script_fu_cleanup_widgets()
>
> case SF_FONT:
> if (script->arg_values[i].sfa_font.dialog != NULL)
> {
>/* crash HERE !!*/
> gtk_widget_destroy (script->arg_values[i].sfa_font.dialog);
> script->arg_values[i].sfa_font.dialog = NULL;
> break;
>
>The dialog pointer is correct so there can be a bug in gtk_widget_destroy()
>for GTK 1.2.5/1.2.6
>
>If you comment the destroy call out it works normally!
>
>So far so good.
>
>Asbjoern
Dowload all software and compiled an IRIX version of gimp.
The bug is in GLIB's 1.2.6 gcache.c ! node is NULL !?
My patch is inside #if 1.
void
g_cache_remove (GCache *cache,
gpointer value)
{
GRealCache *rcache;
GCacheNode *node;
gpointer key;
g_return_if_fail (cache != NULL);
rcache = (GRealCache*) cache;
key = g_hash_table_lookup (rcache->value_table, value);
node = g_hash_table_lookup (rcache->key_table, key);
#if 1
/* patch for removing GIMP scrip-fu crash */
if (node == NULL)
return;
#endif
node->ref_count -= 1;
if (node->ref_count == 0)
{
g_hash_table_remove (rcache->value_table, value);
g_hash_table_remove (rcache->key_table, key);
(* rcache->key_destroy_func) (key);
(* rcache->value_destroy_func) (node->value);
g_cache_node_destroy (node);
}
}
***
* Asbjørn Pettersen Phone work: +47 77 66 08 91 *
* Kongsberg Spacetec a.s Phone home: +47 77674022 *
* Telefax:+47 77 65 58 59 *
* Prestvannveien 38 www:http://www.spacetec.no *
* N-9005 Tromsoe, Norway email:[EMAIL PROTECTED] *
***
Re: Script-Fu Error
On Fri, 22 Oct 1999 12:14:29 -0400 (EDT), Glyph Lefkowitz wrote:
>You are correct.
>
>I 'cvs update'd again, recompiled, and everything works fine now. I can
>even run plugins which use fonts! However, clicking twice on the font
>button will still crash script-fu, although selecting a font and running
>the script will not crash until the script is finished running and script
>fu cleans up its widgets. This makes script-fu functional for me again,
>even if I have to restart the Gimp every time I run a script that uses a
>fontselector :)
I've been debug on OS/2 version and it crash when the font dialog is destroyed.
It's in function script_fu_cleanup_widgets()
case SF_FONT:
if (script->arg_values[i].sfa_font.dialog != NULL)
{
/* crash HERE !!*/
gtk_widget_destroy (script->arg_values[i].sfa_font.dialog);
script->arg_values[i].sfa_font.dialog = NULL;
break;
The dialog pointer is correct so there can be a bug in gtk_widget_destroy()
for GTK 1.2.5/1.2.6
If you comment the destroy call out it works normally!
So far so good.
Asbjoern
***
* Asbjørn Pettersen Phone work: +47 77 66 08 91 *
* Kongsberg Spacetec a.s Phone home: +47 77674022 *
* Telefax:+47 77 65 58 59 *
* Prestvannveien 38 www:http://www.spacetec.no *
* N-9005 Tromsoe, Norway email:[EMAIL PROTECTED] *
***
Re: Script-Fu Error
You are correct. I 'cvs update'd again, recompiled, and everything works fine now. I can even run plugins which use fonts! However, clicking twice on the font button will still crash script-fu, although selecting a font and running the script will not crash until the script is finished running and script fu cleans up its widgets. This makes script-fu functional for me again, even if I have to restart the Gimp every time I run a script that uses a fontselector :) The Tao is like a glob pattern: It is masked but always present. used but never used up. I don't know who built to it. It is like the extern void: It came before the first kernel. filled with infinite possibilities. [[EMAIL PROTECTED]] On Fri, 22 Oct 1999, Sven Neumann wrote: > You haven't correctly recompiled and installed the CVS version. Lots of PDB > calls have changed and it seems you are running new scripts with an old > version of libgimp. > > > Salut, Sven >
Re: Script-Fu Error
On Fri, 22 Oct 1999 15:26:00 +0200 (MET DST), Sven Neumann wrote: > >> >> "ERROR: unbound variable (errobj gimp-image-undo-disable) >> >> If this happens while running a logo script, >> you might not have the font it wants installed on your system" >> >> As of tonight's CVS update, ever single script-fu script is doing this >> when I attempt to execute any of them. >> > >You haven't correctly recompiled and installed the CVS version. Lots of PDB >calls have changed and it seems you are running new scripts with an old >version of libgimp. > > >Salut, Sven Got the same "undo" error for the OS/2 CVS version . Copied all the scripts\*.scmand the "undo" error dissapear. So far so good, but is still crash in a normal manner at the end of the script. On OS/2 is seems the GDK isn't initialized for script-fu. Asbjoern Petteren *** * Asbjørn Pettersen Phone work: +47 77 66 08 91 * * Kongsberg Spacetec a.s Phone home: +47 77674022 * * Telefax:+47 77 65 58 59 * * Prestvannveien 38 www:http://www.spacetec.no * * N-9005 Tromsoe, Norway email:[EMAIL PROTECTED] * ***
Re: Script-Fu Error
Hi, > > "ERROR: unbound variable (errobj gimp-image-undo-disable) > > If this happens while running a logo script, > you might not have the font it wants installed on your system" > > As of tonight's CVS update, ever single script-fu script is doing this > when I attempt to execute any of them. > You haven't correctly recompiled and installed the CVS version. Lots of PDB calls have changed and it seems you are running new scripts with an old version of libgimp. Salut, Sven
Script-Fu Error
"ERROR: unbound variable (errobj gimp-image-undo-disable) If this happens while running a logo script, you might not have the font it wants installed on your system" As of tonight's CVS update, ever single script-fu script is doing this when I attempt to execute any of them. The Tao is like a glob pattern: It is masked but always present. used but never used up. I don't know who built to it. It is like the extern void: It came before the first kernel. filled with infinite possibilities. [[EMAIL PROTECTED]]
script-fu: gimp-convert-indexed
Hi all, I encountered some problems when I tried to update my script-fu script to run on gimp 1.1.10. In the former script I used "(gimp-convert-indexed image TRUE 256)" to convert an image from rgb-mode to indexed. To do the same thing with gimp 1.1.10 I tried: (gimp-convert-indexed img 0 0 256 0) ...and several derivations of that with more or less options. It didn't work! The scripts that came with the full archive of gimp 1.1.10 contain some scripts that use this function and they do not work either: gimp-headers.scm, gimp-labels.scm, spinning_globe.scm. Has anyone got a hint or even a working script? I really don't want to "fallback" to a gimp version < 1.1.! Patrik
Script-Fu not working properly?
Hi all! I discovered a strange behaviour of Script-Fu: When I start GIMP from Bash, let script-fu render a logo (doesn't matter which one) Script-fu segfault at his try to close the parameter window of the script. When I start it from enlightenment it manages to close the window but kills the whole GIMP as soon as I try to render another one?!? Unfortunately it doesn't seem very simple to track this down because a stacktrace doesn't show anything useful (at least for me). It seems that this crash is related to some UI function (probably in libgimpui) but I don't have any clue where... Maybe someone who made a related change could give me a hint -- Servus, Daniel
