Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Alexander Malmberg wrote: Fred Kiefer wrote: Alexander Malmberg wrote: [snip] I suppose you could see the headers, which do specify the integer values, as implicit documentation, but GNUstep doesn't have a the header is the documentation-tradition. This is a very strange statement, I already did reply to a previous mail from Kazu, that I don't have access to any Apple header files. Up to now I thought, that my writen word for not using any Apple headers should be enough. This sounds like a misunderstanding. I wasn't talking about apple's headers, I was talking about GNUstep's headers, and what exactly we consider part of our public API, and thus what we need to do to make sure that the integer values of the constants are a part of our public API. Ok, now I see the other way your sentence could be read and was surely meant to be understood. Sorry for reading this different. As for the technical issue, what you wanted to document, as stated in one of your previous mails, is fully suffient. There is one thing, that I really don't understand, which is why the Apple documentation make a big difference between -abortModal and all the -stopModalWithCode: calls. There must be a bit more to this. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Fred Kiefer wrote:
Alexander Malmberg wrote:
This sounds like a misunderstanding. I wasn't talking about apple's
[snip]
Ok, now I see the other way your sentence could be read and was surely
meant to be understood. Sorry for reading this different.
Sorry about the confusion. /me makes note to write clearer...
As for the technical issue, what you wanted to document, as stated in
one of your previous mails, is fully suffient.
OK. I'll go ahead and do that. :)
There is one thing, that I really don't understand, which is why the
Apple documentation make a big difference between -abortModal and all
the -stopModalWithCode: calls. There must be a bit more to this.
I think it's because of NSRunLoop quirks. Currently, GNUstep's NSRunLoop
won't start a new run loop iteration when a timer is triggered. Instead,
the timer's action runs, but the run loop continues blocking for input
without running any performers, etc.
This means that there are a bunch of things you can't reliably do in
timers. -stopModalWithCode: is one of them; the stop won't be noticed
until the next iteration, and there won't be a next iteration until
something happens to a file descriptor. -abortModal uses exceptions to
try to get around this. My guess is that cocoa/OPENSTEP has/had similar
(in their effect on timers, at least) quirks in their NSRunLoop
implementations.
(This also breaks periodic events, which is why NSTextView's
auto-scrolling is jittery. I believe that it also breaks periodic
updating of views in subtle ways, but I haven't tested that yet.)
I think the best way of fixing this is to fix timers in NSRunLoop (iow,
making them first class NSRunLoop citizens). I've attached a patch that
does this. I've been using it locally for a few months without any
problems. It makes NSTextView's auto-scrolling nice and smooth, and it
means that we don't need to treat -abortModal in any special way.
However, this is tricky stuff, so comments are welcome! :)
- Alexander MalmbergIndex: NSRunLoop.m
===
RCS file: /cvsroot/gnustep/gnustep/core/base/Source/NSRunLoop.m,v
retrieving revision 1.111
diff -u -r1.111 NSRunLoop.m
--- NSRunLoop.m 28 Oct 2003 11:10:23 - 1.111
+++ NSRunLoop.m 14 Mar 2004 00:42:49 -
@@ -1705,13 +1705,12 @@
*/
- (NSDate*) limitDateForMode: (NSString*)mode
{
- extern NSTimer *GSHousekeeper();
+ extern NSTimer *GSHousekeeper(void);
GSRunLoopCtxt*context = NSMapGet(_contextMap, mode);
NSDate *when = nil;
if (context != nil)
{
- NSTimer *min_timer = nil;
GSRunLoopWatcher *min_watcher = nil;
NSString *savedMode = _currentMode;
CREATE_AUTORELEASE_POOL(arp);
@@ -1724,7 +1723,7 @@
while (GSIArrayCount(timers) != 0)
{
- min_timer = GSIArrayItemAtIndex(timers, 0).obj;
+ NSTimer *min_timer = GSIArrayItemAtIndex(timers, 0).obj;
if (timerInvalidated(min_timer) == YES)
{
GSIArrayRemoveItemAtIndex(timers, 0);
@@ -1732,6 +1731,9 @@
continue;
}
+ if (!when)
+ when = [timerDate(min_timer) copy];
+
if ([timerDate(min_timer) timeIntervalSinceNow] 0)
{
break;
@@ -1749,7 +1751,6 @@
{
RELEASE(min_timer);
}
- min_timer = nil;
GSNotifyASAP(); /* Post notifications. */
}
@@ -1825,12 +1826,11 @@
/*
* If there is nothing being watched, and no valid timers
- * other than the housekeeper, we set min_timer to nil so
+ * other than the housekeeper, we set when to nil so
* that the housekeeper timer does not keep the runloop
* active. It's a special case set up in NSThread.m
*/
- if (min_watcher == nil min_timer != nil
-min_timer == GSHousekeeper())
+ if (min_watcher == nil when)
{
unsigned count = GSIArrayCount(timers);
@@ -1844,7 +1844,7 @@
}
if (GSIArrayCount(timers) == 1)
{
- min_timer = nil;
+ DESTROY(when);
}
}
@@ -1860,19 +1860,22 @@
RELEASE(arp);
/*
- * If there are timers - set limit date to the earliest of them.
+ * If there are timers, when is already set to the limit date of the
+ * earliest of them (and retained!).
* If there are watchers, set the limit date to that of the earliest
* watcher (or leave it as the date of the earliest timer if that is
* before the watchers limit).
*/
- if (min_timer != nil)
+ if (when)
{
- when = timerDate(min_timer);
if (min_watcher != nil
[min_watcher-_date compare:
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Fred Kiefer wrote:
Alexander Malmberg wrote:
Fred Kiefer wrote:
At least for Cocoa these enums are fully documented,
Where?
[snip wrong place to look]
Where would you expect enumerators to be documented? In the Types and
Constants section not in the Classes documentation:
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/TypesAndConstants/AppKitTypes.html#//apple_ref/doc/uid/2019/BAJGDFCH
Ah, duh. :/ Seems unfortunate that the descriptions I read doesn't link
back to this page.
[snip]
I suppose you could see the headers, which do specify the integer
values, as implicit documentation, but GNUstep doesn't have a the
header is the documentation-tradition.
This is a very strange statement, I already did reply to a previous mail
from Kazu, that I don't have access to any Apple header files. Up to now
I thought, that my writen word for not using any Apple headers should be
enough.
This sounds like a misunderstanding. I wasn't talking about apple's
headers, I was talking about GNUstep's headers, and what exactly we
consider part of our public API, and thus what we need to do to make
sure that the integer values of the constants are a part of our public
API.
To give a concrete example, in which of the following cases (in a
hypothetical GNUstep header) would you consider the fact that Foo has
the value 42 to be publically documented?
/* quux1.h */
enum
{
Foo=42
};
/* quux2.h */
/**
* This enum is used in the function -quux:, and may have the
* following values:
* Foo Does xyz.
* ...
*/
enum
{
Foo=42
};
/* quux3.h */
/**
* This enum is used in the function -quux:, and may have the
* following values:
* Foo (42) Does xyz.
* ...
*/
enum
{
Foo=42
};
In a project with a policy that the public headers are the public
documentation, I'd say that quux1.h would be enough. However, in GNUstep
we have a fair bit of private stuff in public headers, and lots of
public documentation in .m files instead of in headers, so I think we
need quux3.h to make sure that Foo==42 is clearly a part of the public
API and not just an implementation detail.
- Alexander Malmberg
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Fred Kiefer wrote: Alexander Malmberg wrote: [snip] 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. At least for Cocoa these enums are fully documented, Where? The NSRun*Response enum documentation here: http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSApplication.html contains no information about the actual integer values of the constants. Similarly, the NS*Button enum documentation here: http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSPanel.html contains no information about the actual integer values. Thus, I don't see where the documentation says or implies that it's safe to do eg. -stopModalWithCode: NSOKButton we just need to do the same for GNUstep. And what is the hack, you see here? I just don't get the meaning of the sentence. Your change relies on the fact that the actual integer value of NSRunLoopContinuesResponse is not the same as the actual integer values of any NS*Button enum. Unless there is documentation that makes this safe, I consider that an implementation detail, and relying on that is a hack. I suppose you could see the headers, which do specify the integer values, as implicit documentation, but GNUstep doesn't have a the header is the documentation-tradition. [snip] The point where I may disagree but I am not that sure, is b). What would be the result of -runModalSession: if -stopModalWithCode: gets called with NSRunStoppedResponse or NSRunAbortedResponse? If this will still be that value, things are fine for me. Yes, NSRunStoppedResponse and NSRunAbortedResponse would be returned, just as they are now. - Alexander Malmberg ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Alexander Malmberg wrote: 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. At least for Cocoa these enums are fully documented, we just need to do the same for GNUstep. And what is the hack, you see here? I just don't get the meaning of the sentence. 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. I almost fully agree to what you write. But this does not clash with anything I did change, it just complement it with regard to -abortModal and this had already been discussed before. The point where I may disagree but I am not that sure, is b). What would be the result of -runModalSession: if -stopModalWithCode: gets called with NSRunStoppedResponse or NSRunAbortedResponse? If this will still be that value, things are fine for me. 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.) Oops, this is a point I missed in my original change. Thank you for pointing this out. 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? ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Fred Kiefer wrote: It sure is easier to reply to this by actually changing the code, which is what I did. You will see, that I mostly had to remove code that was no longer needed. (There is more, that is now obsolete, we should remove this later on, when the new code is proven to work in all cases) It is surprisingly often the case, that clean code is less lines than hacks, still hack are in general easier to do. Yes. More surprisingly, it often happens to eliminate other sticky, untraceable bugs... BTW, why don't you extend the joy to other stuff? I bet that you would enjoy it further if you could take a look at NSSavePanel.m, NSPageLayout.m and NSPrintOperation.m. Bless these poor classes, too! :-) Hope this code works for you Excellent! Fred Thanks a lot. - Kazunobu Kurityama ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
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 ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
[PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Attached is a patch that corrects NSSavePanel's
- (void)beginSheetForDirectory: (NSString *)path
fileName: (NSString *)filename
modalForWindow: (NSWindow *)docWindow
modalDelegate: (id)delegate
didEndSelector: (SEL)didEndSelector
contextInfo: (void *)contextInfo;
For the case where delegate is non-nil, the current
implementation fails to work when the OK button on
the sheet is pressed.
(As delegate is set to nil mostly, this bug has
seemingly been overlooked, IMHO.)
Reason: The current implementation directly invokes
NSApplication's -beginSheet: through the global
NSApp. In the implementation of this method, we see
ret = [self runModalForWindow: arg1
relativeToWindow: arg2];
and ret is passed to didEndSelector. Since self is
NSApp, -runModalForWindow:relativeToWindow: invoked
in this case is the one implemented in NSApplication.
However, that method returns neither NSCancelButton nor
NSOKButton, which are to be passed to didEndSelector by
the specifications when NSSavePanel or NSOpenPanel is used.
Rather, when using NSSavePanel or NSOpenPanel, ret is always
set to NSRunStoppedResponse (0), which is incidentally equal
to NSCancelButton (0). This is why the sheet fails to work
when the OK button is pressed.
The patch rectifies the NSSavePanel's method so that it
can work with the OK button properly.
Recently, someone corrected the signature of didEndSelector
found in NSApplication.m, the need of which was pointed out
by my previous patch. The attached patch relies on that
correction. So use the latest CVS if you would like to
try it.
- Kazunobu Kuriyama2004-02-28 Kazunobu Kuriyama [EMAIL PROTECTED]
* Source/NSSavePanel.m: (-beginSheetForDirectory::)
Reimplemented so that didEndSelector will be invoked with either
NSCancelButton or NSOKButton as its second argument.
Index: NSSavePanel.m
===
RCS file: /cvsroot/gnustep/gnustep/core/gui/Source/NSSavePanel.m,v
retrieving revision 1.77
diff -u -r1.77 NSSavePanel.m
--- NSSavePanel.m 28 Oct 2003 20:27:54 - 1.77
+++ NSSavePanel.m 28 Feb 2004 13:42:07 -
@@ -920,12 +920,20 @@
didEndSelector: (SEL)didEndSelector
contextInfo: (void *)contextInfo
{
- [self _setupForDirectory: path file: filename];
- [NSApp beginSheet: self
-modalForWindow: docWindow
-modalDelegate: delegate
-didEndSelector: didEndSelector
-contextInfo: contextInfo];
+ int ret;
+ void (*didEnd)(id, SEL, id, int, void *);
+
+ ret = [self runModalForDirectory: path
+ file: filename
+ relativeToWindow: docWindow];
+
+ if (delegate [delegate respondsToSelector: didEndSelector])
+{
+ didEnd = (void (*)(id, SEL, id, int, void *))
+ [delegate methodForSelector: didEndSelector];
+
+ (*didEnd)(delegate, didEndSelector, self, ret, contextInfo);
+}
}
/**
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Kazunobu Kuriyama wrote: Attached is a patch that corrects NSSavePanel's - (void)beginSheetForDirectory: (NSString *)path fileName: (NSString *)filename modalForWindow: (NSWindow *)docWindow modalDelegate: (id)delegate didEndSelector: (SEL)didEndSelector contextInfo: (void *)contextInfo; For the case where delegate is non-nil, the current implementation fails to work when the OK button on the sheet is pressed. (As delegate is set to nil mostly, this bug has seemingly been overlooked, IMHO.) Reason: The current implementation directly invokes NSApplication's -beginSheet: through the global NSApp. In the implementation of this method, we see ret = [self runModalForWindow: arg1 relativeToWindow: arg2]; and ret is passed to didEndSelector. Since self is NSApp, -runModalForWindow:relativeToWindow: invoked in this case is the one implemented in NSApplication. However, that method returns neither NSCancelButton nor NSOKButton, which are to be passed to didEndSelector by the specifications when NSSavePanel or NSOpenPanel is used. Rather, when using NSSavePanel or NSOpenPanel, ret is always set to NSRunStoppedResponse (0), which is incidentally equal to NSCancelButton (0). This is why the sheet fails to work when the OK button is pressed. The patch rectifies the NSSavePanel's method so that it can work with the OK button properly. Recently, someone corrected the signature of didEndSelector found in NSApplication.m, the need of which was pointed out by my previous patch. The attached patch relies on that correction. So use the latest CVS if you would like to try it. This patch tries to add another workaround on top of all the hacks, that are already there for model and sheet handling. This doesn't look right to me, so I suggest another, hopefully cleaner, way to resolve this: 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. So we are able to undo the hack Nicola put into the save panel years ago and to use stopModalWithCode: there again, using the button constant as the code. That way everything will fall into place again and no further hacks will be needed. And perhaps somebody will in the future even donate a fully working sheet processing to GNUstep. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Fred Kiefer wrote: This patch tries to add another workaround on top of all the hacks, that are already there for model and sheet handling. This doesn't look right to me, so I suggest another, hopefully cleaner, way to resolve this: I agree with the view above as a general idea or policy; the existing code relevant to sheet somewhat looks unnatural, and hence someday it needs to be overhauled. I don't think, however, the view and the ones blow are reasonable verification strong enough to keep the bug alive. 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. Because I don't have access to the Cocoa's header files, I'm not sure how this can be done. The NSRun* enum stands for the state of a panel/sheet, whereas the NS*Button enum for the state of buttons on it. Obviously, they are conceptually/semantically different, and we can't identify the former with the latter in a natural way. It would be rather confusing if we could establish a correspondence between them. In addition, I don't think relying on the values of enums is a good programming style; it definitely constitutes buggy code. So we are able to undo the hack Nicola put into the save panel years ago and to use stopModalWithCode: there again, using the button constant as the code. Yes. But I could not do this because of lack of time, and because I found a fairly simple solution. Look, the patch I sent consists of only a few lines of code. It is completely localized in a single method and doesn't introduce any formidable dependency. You can easily remove it when you obtain a complete solution you think of. All of all, it does fix the bug, thus making GNUstep better. It's at least a good tentative solution for now. That way everything will fall into place again and no further hacks will be needed. And perhaps somebody will in the future even donate a fully working sheet processing to GNUstep. I don't understand why you seemingly try to allow GNUstep to live with the bug, which is simply fixed by a few lines of code. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Kazunobu Kuriyama wrote: Fred Kiefer wrote: This patch tries to add another workaround on top of all the hacks, that are already there for model and sheet handling. This doesn't look right to me, so I suggest another, hopefully cleaner, way to resolve this: I agree with the view above as a general idea or policy; the existing code relevant to sheet somewhat looks unnatural, and hence someday it needs to be overhauled. I don't think, however, the view and the ones blow are reasonable verification strong enough to keep the bug alive. 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. Because I don't have access to the Cocoa's header files, I'm not sure how this can be done. The NSRun* enum stands for the state of a panel/sheet, whereas the NS*Button enum for the state of buttons on it. Obviously, they are conceptually/semantically different, and we can't identify the former with the latter in a natural way. It would be rather confusing if we could establish a correspondence between them. In addition, I don't think relying on the values of enums is a good programming style; it definitely constitutes buggy code. So we are able to undo the hack Nicola put into the save panel years ago and to use stopModalWithCode: there again, using the button constant as the code. Yes. But I could not do this because of lack of time, and because I found a fairly simple solution. Look, the patch I sent consists of only a few lines of code. It is completely localized in a single method and doesn't introduce any formidable dependency. You can easily remove it when you obtain a complete solution you think of. All of all, it does fix the bug, thus making GNUstep better. It's at least a good tentative solution for now. That way everything will fall into place again and no further hacks will be needed. And perhaps somebody will in the future even donate a fully working sheet processing to GNUstep. I don't understand why you seemingly try to allow GNUstep to live with the bug, which is simply fixed by a few lines of code. It sure is easier to reply to this by actually changing the code, which is what I did. You will see, that I mostly had to remove code that was no longer needed. (There is more, that is now obsolete, we should remove this later on, when the new code is proven to work in all cases) It is surprisingly often the case, that clean code is less lines than hacks, still hack are in general easier to do. As for the new constant value, I don't have access to any Apple headers. I am just able to use the published Application Kit Reference. And as I said, there still is no sheet handling code in NSApplication, there is only that nasty workaround there, which I put in place some years ago (Flaged with lots of FIXMEs). Feel welcome to implement this cleanly. Hope this code works for you Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
