RSS/Atom feed Twitter
Site is read-only, email is disabled

"Cancel" function and plugins

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

7 of 7 messages available
Toggle history

Please log in to manage your subscriptions.

"Cancel" function and plugins Toby Speight 07 Jun 12:07
  "Cancel" function and plugins Nathan Summers 07 Jun 15:19
   "Cancel" function and plugins Toby Speight 07 Jun 18:36
    "Cancel" function and plugins Sven Neumann 07 Jun 19:54
     "Cancel" function and plugins Michael Natterer 07 Jun 21:29
     "Cancel" function and plugins Toby Speight 08 Jun 10:36
      "Cancel" function and plugins Sven Neumann 15 Jun 22:14
Toby Speight
2006-06-07 12:07:13 UTC (almost 18 years ago)

"Cancel" function and plugins

(Delurk: I'm a sporadic developer of plugins, some of which are almost good enough to shove in the registry, and I've watched this list for a few months)

One of my current projects is a multifrequency blend tool (inspired by, but not based on, the enblend program), and as part of its operation, it invokes a couple of other plugins (I don't see the point in reinventing wheels!).

One thing that's not covered in any of the "how to write a plugin" guides is how to poll for cancel. Of course, the plugin could have its own cancel button, but then the user would have to know which sub-plugin is running and find the correct cancel button! (I'm happy to deal with the call to the sub-plugin returning GIMP_PDB_CANCEL).

So - how does a plugin poll the Gimp's cancel button? I couldn't find any examples in the src/plug-ins directory...

Nathan Summers
2006-06-07 15:19:31 UTC (almost 18 years ago)

"Cancel" function and plugins

On 6/7/06, Toby Speight wrote:

(Delurk: I'm a sporadic developer of plugins, some of which are almost good enough to shove in the registry, and I've watched this list for a few months)

One of my current projects is a multifrequency blend tool (inspired by, but not based on, the enblend program), and as part of its operation, it invokes a couple of other plugins (I don't see the point in reinventing wheels!).

One thing that's not covered in any of the "how to write a plugin" guides is how to poll for cancel. Of course, the plugin could have its own cancel button, but then the user would have to know which sub-plugin is running and find the correct cancel button! (I'm happy to deal with the call to the sub-plugin returning GIMP_PDB_CANCEL).

So - how does a plugin poll the Gimp's cancel button? I couldn't find any examples in the src/plug-ins directory...

"Cancelling" a plugin kills it unconditionally. It's been a few months since I looked at that code, but I'm fairly sure that there is no way for a plug-in to catch that it's been cancelled.

You really should check the value of each pdb call you make and make sure that the return value is GIMP_PDB_SUCCESS. There is almost certainly code out there that doesn't check the return value and just assumes nothing wrong happened, but that doesn't mean it's the right thing to do. :)

Which gives me an idea for a simple macro that causes the function to return GIMP_EXECUTION_ERROR when given an error status, and does nothing otherwise.

Rockwalrus

Toby Speight
2006-06-07 18:36:56 UTC (almost 18 years ago)

"Cancel" function and plugins

0> In article ,
0> Nathan Summers ("Nathan") wrote:

Nathan> "Cancelling" a plugin kills it unconditionally. It's been a Nathan> few months since I looked at that code, but I'm fairly sure Nathan> that there is no way for a plug-in to catch that it's been Nathan> cancelled.

Thanks for the insight; hunting around a bit more, I've found comments to the effect that "cancel" signals the plug-in process with SIGKILL (in a Unix world, which is where I'm comfortable). So there's nothing I need to do to have Cancel work as expected, as long as I ensure that I check all PDB calls and treat failures appropriately?

While we're on this subject - obviously the plug-in process has no chance to clear up if it's killed outright, so what happens to e.g. undo stack in this case? Is it all just left hanging as it was, or is there some attempt by Gimp to "roll-back" the effect of the plugin? I know, I know - UTSL! In plug-in.c, I find code in plug_in_close() that unregisters temporary procedures and closes dialogs, but that appears to be it. :-( Correct?

Sven Neumann
2006-06-07 19:54:04 UTC (almost 18 years ago)

"Cancel" function and plugins

Hi,

On Wed, 2006-06-07 at 17:36 +0100, Toby Speight wrote:

While we're on this subject - obviously the plug-in process has no chance to clear up if it's killed outright,

Well, in theory it could catch the signal and clean up before it exits.

so what happens to e.g. undo stack in this case? Is it all just left hanging as it was, or is there some attempt by Gimp to "roll-back" the effect of the plugin?

GIMP tries to establish a sane state. IIRC, it pops the context the plug-in was running in and makes sure that undo groups are closed.

Sven

Michael Natterer
2006-06-07 21:29:57 UTC (almost 18 years ago)

"Cancel" function and plugins

On Wed, 2006-06-07 at 19:54 +0200, Sven Neumann wrote:

Hi,

On Wed, 2006-06-07 at 17:36 +0100, Toby Speight wrote:

While we're on this subject - obviously the plug-in process has no chance to clear up if it's killed outright,

Well, in theory it could catch the signal and clean up before it exits.

so what happens to e.g. undo stack in this case? Is it all just left hanging as it was, or is there some attempt by Gimp to "roll-back" the effect of the plugin?

GIMP tries to establish a sane state. IIRC, it pops the context the plug-in was running in and makes sure that undo groups are closed.

Um, no :( Load plug-ins do that. Unfortunately any other plug-in can still crash the core by leaving undo groups open. I have some half-finished code but gave up because the approach was apparently wrong (it became way too complicated).

ciao, --mitch

Toby Speight
2006-06-08 10:36:11 UTC (almost 18 years ago)

"Cancel" function and plugins

0> In article ,
0> Sven Neumann ("Sven") wrote:

Sven> On Wed, 2006-06-07 at 17:36 +0100, Toby Speight wrote:

While we're on this subject - obviously the plug-in process has no chance to clear up if it's killed outright,

Sven> Well, in theory it could catch the signal and clean up before it Sven> exits.

No, SIGKILL can't be caught by a process.

so what happens to e.g. undo stack in this case? Is it all just left hanging as it was, or is there some attempt by Gimp to "roll-back" the effect of the plugin?

Sven> GIMP tries to establish a sane state. IIRC, it pops the context Sven> the plug-in was running in and makes sure that undo groups are Sven> closed.

Thanks - I didn't find this in the code (perhaps the closing of undo groups is part of popping the context?). It certainly seems better-behaved than when a plug-in crashes (on 2.2, anyway).

I seem to have solved the problem I was having with the GTS library (I was using gts_delaunay_refine() rather than gts_delaunay_conform(), and it wasn't happy), so I should be able to make more progress on my plug-in over the next few weeks (or whenever I have free time).

Thanks for the help on this.

Sven Neumann
2006-06-15 22:14:47 UTC (almost 18 years ago)

"Cancel" function and plugins

Hi,

On Thu, 2006-06-08 at 09:36 +0100, Toby Speight wrote:

Sven> Well, in theory it could catch the signal and clean up before it Sven> exits.

No, SIGKILL can't be caught by a process.

The plug-in receives a QUIT message on the wire before it is being killed. Probably not trivial to do the right thing in response to that message, but it could be done.

Sven