Steven Noonan to sdl While trying to build the SDLMain.m included with SDL 1.2.14, with #define SDL_USE_NIB_FILE 1: /Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m: In function '-[SDLMain fixMenu:withAppName:]': /Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:122: warning: 'sizeToFit' is deprecated (declared at /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSMenu.h:281) /Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m: In function 'main': /Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:376: warning: 'poseAsClass:' is deprecated (declared at /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:127) /Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:376: error: 'poseAsClass:' is unavailable (declared at /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:127) /Users/steven/Development/darwinia/targets/macosx/Darwinia/SDLMain.m:377: warning: passing argument 2 of 'NSApplicationMain' from incompatible pointer type Eric Wing to Sam I don't have time today to look at this in detail, but the problem is definitely the poseAsClass: method. This was deprecated in Obj-C 2.0 and not retained in 64-bit. I've never used this method and it has always been limited to esoteric uses. I think this is why Apple wanted to dump it (among complicating some other things they do). I have read about others getting bit by this when migrating. Long story short, there really isn't a migration path for this method. The question that then must be asked is why are we using it (what does it accomplish), and then figure out the 'proper' way of accomplishing that. Glancing at SDLMain.m, it's not obvious to me why it is there or what it is really accomplishing. My only speculation is that NSApplicationMain hardcodes something to look for NSApplication and a subclass (SDLApplication) fails for some reason (assuming that the original coder did this for good reason). Three thoughts come to mind. 1) The Info.plist has properties to control things related to the startup class and nib. NSPrincipalClass, NSMainNibFile Maybe principle class needs to be SDLApplication and we can delete the poseAs 2) I was told that 10.6 introduced new APIs to make programatic NIB wrangling and avoidance easier. Unfortunately, I don't know the specifics. 3) Instead of subclassing NSApplication in SDLMain.m, maybe we can just add a category. It looks like the following is the only thing that is done (quick glance): @interface SDLApplication : NSApplication @end @implementation SDLApplication /* Invoked from the Quit menu item */ - (void)terminate:(id)sender { /* Post a SDL_QUIT event */ SDL_Event event; event.type = SDL_QUIT; SDL_PushEvent(&event); } @end So instead, we change this to: (warning written in mail and untested) @interface NSApplication (SDLApplication) - (void) terminate:(id)sender; @end @implementation NSApplication (SDLApplication) /* Invoked from the Quit menu item */ - (void)terminate:(id)sender { /* Post a SDL_QUIT event */ SDL_Event event; event.type = SDL_QUIT; SDL_PushEvent(&event); } @end Then everywhere SDLApplication is used, we change it to NSApplication (and remove the poseAsClass line). Perhaps you could ask the bug reporter to try this solution (#3). And if that fails, maybe try #1. -Eric Steven Noonan to Sam The suggested change (diff below) seems to work fine. - Steven

.TH "SDL_AddTimer" "3" "Tue 11 Sep 2001, 23:01" "SDL" "SDL API Reference" 
.SH "NAME"
SDL_AddTimer \- Add a timer which will call a callback after the specified number of milliseconds has elapsed\&.
.SH "SYNOPSIS"
.PP
\fB#include "SDL\&.h"
.sp
\fBSDL_TimerID \fBSDL_AddTimer\fP\fR(\fBUint32 interval, SDL_NewTimerCallback callback, void *param\fR);
.SH "CALLBACK"
.PP
.nf
\f(CW/* type definition for the "new" timer callback function */
typedef Uint32 (*SDL_NewTimerCallback)(Uint32 interval, void *param);\fR
.fi
.PP
.SH "DESCRIPTION"
.PP
Adds a callback function to be run after the specified number of milliseconds has elapsed\&. The callback function is passed the current timer interval and the user supplied parameter from the \fBSDL_AddTimer\fP call and returns the next timer interval\&. If the returned value from the callback is the same as the one passed in, the periodic alarm continues, otherwise a new alarm is scheduled\&.
.PP
To cancel a currently running timer call \fISDL_RemoveTimer\fR with the timer ID returned from \fBSDL_AddTimer\fP\&.
.PP
The timer callback function may run in a different thread than your main program, and so shouldn\&'t call any functions from within itself\&. You may always call \fISDL_PushEvent\fR, however\&.
.PP
The granularity of the timer is platform-dependent, but you should count on it being at least 10 ms as this is the most common number\&. This means that if you request a 16 ms timer, your callback will run approximately 20 ms later on an unloaded system\&. If you wanted to set a flag signaling a frame update at 30 frames per second (every 33 ms), you might set a timer for 30 ms (see example below)\&. If you use this function, you need to pass \fBSDL_INIT_TIMER\fP to \fISDL_Init\fR\&.
.SH "RETURN VALUE"
.PP
Returns an ID value for the added timer or \fBNULL\fR if there was an error\&.
.SH "EXAMPLES"
.PP
.PP
.nf
\f(CWmy_timer_id = SDL_AddTimer((33/10)*10, my_callbackfunc, my_callback_param);\fR
.fi
.PP
.SH "SEE ALSO"
.PP
\fI\fBSDL_RemoveTimer\fP\fR, \fI\fBSDL_PushEvent\fP\fR
.\" created by instant / docbook-to-man, Tue 11 Sep 2001, 23:01