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.
