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 mjhammel@xxxxxxxxxxxxxxxxx http://www.graphics-muse.com ------------------------------------------------------------------------------ Everything should be made as simple as possible. But not simpler. -- Albert Einstein.
