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

2004-03-13 Thread Fred Kiefer
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

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

2004-03-13 Thread Alexander Malmberg
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

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

2004-03-12 Thread Alexander Malmberg
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:

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

2004-03-11 Thread Alexander Malmberg
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

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

2004-03-06 Thread Fred Kiefer
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

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

2004-03-02 Thread Kazunobu Kuriyama
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

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

2004-03-02 Thread Alexander Malmberg
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

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

2004-02-28 Thread Kazunobu Kuriyama
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

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

2004-02-28 Thread Fred Kiefer
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;

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

2004-02-28 Thread Kazunobu Kuriyama
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

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

2004-02-28 Thread Fred Kiefer
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