bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::


From: Alexander Malmberg
Subject: Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Date: Tue, 02 Mar 2004 22:02:44 +0100

Fred Kiefer wrote:
> We should give the correct Cocoa values to the constants
> NSRunStoppedResponse, NSRunAbortedResponse and  NSRunContinuesResponse.
> With these there will no longer be a conflict to the values of
> NSCancelButton and NSOKButton.

Relying on two separate enums having distinct values for their constants
is wrong unless there is explicit documentation stating that the two
enums are disjoint wrt values. There isn't currently, afaict, any such
documentation in GNUstep or OpenStep, and I think it'd be a hack to add
this for just two specific enums.

Instead, if we want to have useful support for passing arbitrary values
to -stopModalWithCode:, I think we should do the following (which
somewhat overlaps changes to the handling of -abortModal discussed
recently):


a. Unify handling of -stopModal... and -abortModal (by making all of
them equivalent to calling -stopModalWithCode: with the right constant).
This will require some changes in the way timers are handled in
NSRunLoop to be really useful, but those changes are also needed for
other reasons, so I think that's appropriate. I've used those changes
locally for a fairly long time, and it hasn't broken anything (and it
has fixed some minor issues). I'll send the patch to the list soon, I
hope.

This does change the semantics of -abortModal. Currently, it raises an
exception and never returns. However, this is ugly, causes problems with
exception handlers between -abortModal and the run loop, and can't be
extended to work across threads. The new behavior would be just like
-stopModal's. This is consistent with OpenStep (and, I think Cocoa), but
not OPENSTEP. I don't think compatibility will be an issue; all uses in
my collection of GNUstep apps are already written as if -abortModal
would return.


b. Remove all semantic meaning from all NSRun.*Response except
NSRunContinuesResponse (which needs to be special in -runModalSession:).
Thus, NSRunStoppedResponse and NSRunAbortedResponse are just convenience
values for -stopModal and -abortModal. This is actually already the
case, so it just needs to be documented.


c. Give NSRunContinuesResponse a well-defined, documented value. Since
NSRunContinuesResponse has special semantics, apps must avoid using that
specific value. This is necessary to make it safe to pass in arbitrary
values.

To make it easy to use other enums as codes, we should avoid typical
enum values, so the current value (-1002) is probably as good as it
gets. It's arbitrary, but non-arbitrary values have a greater risk of
colliding with other constants.

The values of the other NSRun.*Response don't matter (they have no
special meaning). Thus, this amounts to documenting the actual value of
NSRunContinuesResponse.

(Another reason to keep -1002 is that changing the values of these
constants breaks binary compatibility. GNUMail and MusicBox users will
want to recompile or there'll be odd issues with modal windows; this may
have been the cause of some recent bug reports.)


Anyway, with these changes, it would be possible for anyone to use any
enum or set of constants as codes in -stopModalWithCode: as long as they
stay away from the explicitly documented -1002, which seems like a good
thing. :) Thoughts?

- Alexander Malmberg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]