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
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 d
Alexander Malmberg wrote:
Fred Kiefer wrote:
Alexander Malmberg wrote:
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
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" docu
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
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 enum
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 va
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 c
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 gener
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 exis
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 *)contex
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 th
12 matches
Mail list logo
