Marc Lehmann wrote: > > On Mon, Jan 17, 2000 at 02:59:26PM +0100, Michael Natterer <mitschel@xxxxxxxxxxxxxxx> wrote: > > While this has no effect in normal plugins, it causes a "save failed" > > message box to appear for all save plugins. I find this really annoying, > > because pressing cancel is just a normal mode of operation, not an > > error. > > I'm not completely sure, but since there simply is no way to cleanly > "cancel" plug-ins, it really _is_ an error what is happending, and the > save definitely failed (and might leave all sorts of garbage around!). Well, STATUS_CANCEL would be a way to cleanly cancel a plugin. And pressing "Cancel" in the "Save as Whatwver" dialog of course causes the plugin to exit cleanly without leaving any garbage. And... I think "Cancel" is _not_ an error. > > Well, none of the current return values gives gimp a hint that "Cancel" > > Bad. > > > was pressed. I suggest to add "STATUS_CANCEL" to the enum which > > could be treated specially. > > And what's next, "STATUS_DISK_FULL"? That enum shouldn't be taken lightly. > Let's face it: gimp has _no_ way of communicating causes to the caller. > Instead of extending that enum with more-or-less unspecific errors, one > should better extend the system by communicating different error messages. Everything else (i.e. _real_ errors) of course return EXECUTION_ERROR) and that's exactly what I would expect. As I said before, STATUS_CANCEL would not indicate an error but a special event which does not occur in the current enum. IMHO "Cancel" is a return value which lives on the same level as "Success" or "Execution Error" and is _not_ a subtype of the somewhat unspecific "Execution Error". > An obvious extension would be to return another value describing the error > in more detail (I have written quite a bit about that topic earlier). Agree, for real errors there should indeed be an additional information. (for example the context as you suggested earlier). > > As I'm going to look at all the save plugins once more anyway, I offer > > to hack this if nobody objects. > > I do. At leats in that form, it look like yet another hack that just needs > to be removed later on. Frankly, I don't see any other clean solution except the additional enum value. But if you have a better idea, please tell me. bye, --Mitch
