Marc Lehmann wrote:
> On Mon, Jan 17, 2000 at 02:59:26PM +0100, Michael Natterer
><[EMAIL PROTECTED]> 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_
> > Well, none of the current return values gives gimp a hint that "Cancel"
> > 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.