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);
   $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
Michael J. Hammel                               The Graphics Muse 
[EMAIL PROTECTED]            
                Everything should be made as simple as possible.  
                    But not simpler.  --  Albert Einstein.

Reply via email to