Re: Programmatically setting Principle Class
Re: Programmatically setting Principle Class
- Subject: Re: Programmatically setting Principle Class
- From: Shamyl Zakariya <email@hidden>
- Date: Sun, 6 Aug 2006 16:17:19 -0400
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@hidden
"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@hidden
"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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden