Re: Programmatically setting Principle Class

FROM : Shamyl Zakariya
DATE : Sun Aug 06 22:17:19 2006

Well, I managed to pull it off, amazingly, but it has a couple 
serious bugs. I looked at the GLUT source code ( thanks for providing 
it, apple! ) and I used the recent ( and pulled ) OpenGL Game 
Template demo which is a nib-less Cocoa app as a test harness.

So anyway, instead of setting the principle class -- which I couldn't 
find a procedural way of doing -- you simply forgo NSApplicationMain 
for your own simplified version. And the very first line you call:

NSApp = [MyApplicationClass sharedApplication]

And then carry on. Here's my variant of main() from the OpenGL Game 
Template demo code:

int main(int argc, char *argv[])
{
   NSApp = [GameApp sharedApplication]; // I changed this
   
   NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
   {
       NSRect winRect = {{0, 0}, {WIDTH, HEIGHT}};
       {
           unsigned int mask = NSClosableWindowMask|
NSMiniaturizableWindowMask|NSResizableWindowMask;
           NSBackingStoreType type = NSBackingStoreBuffered;
           NSWindow *window = [[NSWindow alloc] initWithContentRect:winRect 
styleMask:mask backing:type defer:NO];        
           
           // set the title of the window
           [window setTitle:@GAME_TITLE];
           
           // attach our drawbale to the window
           [window setContentView:[[GameView alloc] initWithFrame:winRect]];
           
           // center the window on the main screen
           [window center];
           
           // set the focus on the window and bring it to the front
           [window makeKeyAndOrderFront:window];
       }
   }
   [pool release];
   
   // enter the application main event loop
   [NSApp run];
   
   return 0;
}

This works -- in that my application subclass is init-ed and becomes 
the NSApplication singleton instance. In the case of a .app 
application, this seems to work correctly. But in the case of a 
command-line app there are a couple obvious bugs. First, no menu 
appears. Second, keyboard input goes to the console, rather than the 
app's even loop.

What I also learned is that GLUT.framework includes a nib and uses 
it, even for command-line apps. This makes sense. All I want is a 
simple framework so that I can write simple one-off OpenGL 
prototyping apps but with a richer environment than GLUT environment 
and which suits my needs. It'd be nice for these apps to be command 
line, but I guess it's not really that important.



<email_removed>
   "shaking fist at indifferent cosmos"


On Aug 4, 2006, at 1:49 PM, Shamyl Zakariya wrote:

> That's a shame. That said, I'm going to see how GLUT does it, since 
> it does do it. Thanks,
>
>
> <email_removed>
>    "the electrodes of progress on the nipples of ignorance"
>        -- Dr. Rick Solomon
>
>
> On Aug 4, 2006, at 1:09 PM, Nick Zitzmann wrote:
>

>>
>> On Aug 4, 2006, at 8:54 AM, Shamyl Zakariya wrote:
>>

>>> But the problem here is that I want this to be usable from 
>>> command-line C++ apps -- like GLUT does. I can't set the 
>>> principle class in an info.plist when the app's not a .app bundle.

>>
>> I don't think that using the AppKit in a non-bundled application 
>> is a supported operation.
>>
>> Nick Zitzmann
>> <http://www.chronosnet.com/>
>>
>>
>>
>>

>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>