Re: Creating Cocoa Windows from Command Line Apps
Re: Creating Cocoa Windows from Command Line Apps
- Subject: Re: Creating Cocoa Windows from Command Line Apps
- From: Raffael Cavallaro <email@hidden>
- Date: Thu, 20 Jan 2005 21:11:45 -0500
On Jan 20, 2005, at 7:04 PM, The Karl Adam wrote:
You guys do know that in Panther you can go right into an application
bundle and start these applications directly? They work fine.
I'll second this. I do this with lisp command line tools. As long as your command line executable, inside the bundle, calls the following sequence:
[NSApplication sharedApplication]; // initializes your application and creates the global singleton variable NSapp to point to it.
[NSBundle loadNibNamed:@"MainMenu" owner:NSapp]; // loads your nib - obviously this can be a different name, different path.
[NSApp run]; // starts your NSapp running.
The above is documented at: <http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSApplication.html>
Basically, this is how the compilers for all non-Objective-C/non-Java languages provide a Cocoa UI (the Java-Cocoa bridge is probably done similarly too - I haven't checked). They bridge to the Cocoa runtime as documented here:
<http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html> or in pdf:
<http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/ObjCRuntimeRef.pdf>
Then they call the above using their Cocoa bridge from an executable located at the right place in the .app bundle. Building the bridge is far harder than using it to start a GUI application. In LispWorks for example, its just these 3 lines above, called from lisp like this:
(setf ns-app (objc:invoke "NSApplication" "sharedApplication"))
(objc:invoke "NSBundle" "loadNibNamed:owner:" "MainMenu" ns-app )
(objc:invoke ns-app "run")
Getting your NSapp to communicate properly with your non-Objective-C executable also requires some effort; it is a matter of reading the somewhat scattered, but fairly thorough Apple documentation, and doing what it says. The above 3 lines assume that your nib is already wired to a set of classes created from inside your non-Objective-C environment. If your app keeps a terminal or listener open, or has a socket connection you can connect a terminal to, you can continue to modify functionality, reload nibs, etc., while the app is still running. This is how dynamic languages, such as lisp, do Cocoa GUIs.
regards,
Ralph
Raffael Cavallaro, Ph.D.
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