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

Reply via email to