Thanks Serg - sorry for the *huge* delay in answering. My fault. Please don't get upset by myself being slow. :-)
> NP> About the remaining warnings, > NP> > NP> NSOpenGLContext.m: In function `+[NSOpenGLContext currentContext]': > NP> NSOpenGLContext.m:67: warning: multiple declarations for method > NP> `currentContext'../Headers/AppKit/NSOpenGL.h:95: warning: using > NP> `+(NSOpenGLContext *)currentCont ext' > NP> ../Headers/AppKit/NSGraphicsContext.h:163: warning: also found > NP> `+(NSGraphicsCont ext *)currentContext' > NP> > NP> I think this is an error in the API. -currentContext should return > NP> 'id', for the same reason that -init returns 'id'. > > In the attached patch this is fixed. NS*Context entries are changed to > id. I see no harm in such changes. Thanks - your patch is good - there is a small harm that the method types would be different from Apple's one ... we might get complains for that from users in the future - we usually do - and users' complains are more serious than compilers' ones :-) Hmmm. I'm not sure what to do, I don't have clear views on this one - the best thing would be to avoid the warning via a compiler cast, but the cast we need (a generic Class pointer casted to a NSOpenGLContext subclass class pointer) is not supported by the compiler. If anyone has any brilliant idea on how to remove the warning, it's appreciated. Else, I'm sort of confused about what's best to do in practice, don't see any way of avoiding the warning without changing the types of methods in the public API, and would leave it as it is. :-) > NP> NSPrintOperation.m: In function `-[NSPrintOperation > NP> _printOperationDidRun:succes s:contextInfo:]': > NP> NSPrintOperation.m:585: warning: passing arg 2 of > NP> `performSelector:withObject:wi thObject:' makes pointer from integer > NP> without a cast > NP> > NP> While this is an error in the code. 'success' is a BOOL, and can't > NP> be passed as argument as if it were an object.ess] > > I've changed [delegate performSelector:withObject:withObject:] to > calling of didRunSelector IMP. It seems to be correct but needs > checking. Thanks Serg - good - applied. :-) _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
