I have been developing a plugin that involves users editing files and I need to be able to prompt them to save when the gimp closes.

I have tried using the quit signal in pluginInfo:

GimpPlugInInfo PLUG_IN_INFO = {
NULL,
quit,
query,
run
};

This only seems to be called, however, when the plugin closes and not the gimp.
(It is a GTK plugin with it's own window like script-fu, I get the signal when I close the plugin window, but if the user closes the gimp I have no way to clean up.)

Is this a bug or is my understanding of what this callback is supposed to do flawed?
Is there another way to do what I am trying to accomplish?

Thank you for your time, Soren Berg

I have been thinking about this and it does seem to be a somewhat thorny issue.

One possible solution would be to call the quit functions of the plugins but have a timeout set
so that you could pop up a dialog if they did not quit after a second or two asking if the user wanted
to terminate the plugin. But this seems messy.

Another thought:

If a plugin has a quit function that hangs or takes a long time, won't that affect the gimp when
the quit function is normally called (on closing of plugin)? If so, the gimp is already exposed to the problem of poorly written plugins, and it might as well call the quit functions of active plugins when it exits.

Or does the gimp have some way of protecting against this issue that wouldn't work if it was closing?

Thank you for your assistance, -Soren Berg

On Sun, Feb 1, 2009 at 12:49 PM, Sven Neumann wrote:

I am not entirely sure how plug-ins are quit by the core when the GIMP core exits. It would probably make sense to make sure that the plug-in's quit function is called. On the other hand we don't want the application to hang there waiting for plug-ins to quit. If you want to investigate this further, we could try to help you to fix this issue.

Sven

Thank you for the link to that thread, it was very informative.

I have yet to find any sort of workaround. I tried trapping all the TERM type signals but no luck there.

Is doing a non blocking wait still under discussion? Actually, for my purposes it doesn't matter whether the wait is blocking, because I just need to
run a gedit style "Save changes?" dialog. Or, if I only had a second, just save some sort of backup.

It seems like several different plugins could take advantage of that because they make temporary images.
(or would this still be only on plugin quit and not gimp quit?)

Thanks again for your continued assistance, -Soren Berg

On Tue, Feb 3, 2009 at 12:47 PM, Sven Neumann wrote:

I very much doubt that any real-world plug-in is actually using the quit function. I tried to use it once in a patch attached to http://bugzilla.gnome.org/show_bug.cgi?id=8141#c7

Sven

On Thu, Feb 5, 2009 at 3:12 PM, Sven Neumann wrote:

I think it would make sense to call the quit method in all running plug-ins when the core is quit. So a patch that does this would be much appreciated. We need to somehow deal with the problem of hanging plug-ins though.

Sven

I can code up a patch if we can figure out how to prevent stalling.

My approach would be to fork and call the quit method in the child, then if the child doesn't return in two seconds, pop up a dialog informing the user that a plug in is not responding and give them the option to terminate it.

I don't know how the GIMP deals with threading though, so I'm not sure that that is appropriate in this case.

Someone earlier mentioned a non-blocking wait, does the GIMP have some system in place for doing that?