[Openmcl-devel] openGL

Tue Dec 17 10:17:10 PST 2002

Here are my notes on building a new objc tool for openmcl, raw as they 
are. For an example you ought to be able to look at the inspector's nib 
file in the openmcl.app bundle distributed with openmcl.

Warning -- Caveat emptor, your milage may vary, etc.

Also... NSOpenGLView is what you want to use I'm thinking. If I 
understand it correctly, from your lisp code (or whatever code, really 
-- it'd be the same doing it entirely in objc) you basically set a 
particular NSOpenGLView object as being the current NSOpenGLContext 
(i'm approximating -- read the docs!) and make opengl library calls as 
per usual (for more info get Ed Angel's book on opengl, and the opengl 
reference manual, and the opengl programming guid) to draw stuff in 
that context.

Hey, how about that, I'm getting all excited about making a 
cocoa-opengl example file -- but don't hold your breath. Anyway this 
should get you going, read my advice below and read the pertinent bits 
of the cocoa objc application framework documentation. (in the 
developer documentation that apple supplies).

hamilton

On Tuesday, December 17, 2002, at 10:34 AM, nik gaffney wrote:

> befor going to far down the wrong path..  i thought id ask if anyone 
> is using
> opengl sucessfully under osX ? which interfaces would you recomend?  
> are
> there any which work relatively painlessly with both apples gl, and 
> mesa on
> linux?

(in-package :ccl)

#|

OK, Here's a first cut at documenting the process of building a cocoa
window utility for OpenMCL.  Square brackets are for stuff I think I
did but am not sure whether is really super-advisable or not.

I'm going to assume, first of all, that the application itself is a
general-purpose thunk of a bundle whose only purpose is to make sure
that there's a place for the NIB files and set up the few things
necessary to allow OpenMCL and Objective C to really get acquainted,
and that your utility consists of one kind of window that may be
created multiple times but with each standing alone. Extrapolating
from these instructions to build a utility that uses multiple kinds of
windows or has windows interacting shouldn't be too hard.

Tweaking the parent bundle

If you're just adding to the OpenMCL bundle provided with openmcl, you
won't have to worry about this, but in any case it's reasonably
straightforward.  In Project Builder, pick the "Targets" tab (on the
left, with Files, Classes, etc.) and select your project target.  Then
pick the "Application Settings" tab on the right and scroll down to
the "Cocoa-Specific" section. Here, change the "Principle class" to
"lispapplication" (minus the quotes) [and the "Main nib file" to
"MainMenu" (again, minus quotes) unless you will be naming it
something else]. [Then go edit the main nib file that came with the
new project, make sure it's named properly, and delete the window
instance [and the first responder instance].]

When you build this bundle, you'll need to go into the
BundleName.app/Contents/MacOS/ directory and rename the BundleName
file to dppccl by hand. I'd like to know how to do this automatically
in PB, but it may be easiest to just have the standard distributed
bundle be named dppccl and just leave it at that for now. [Actually
this may be settable -- under the PB Targets tab in Application 
Settings,
use the "Expert" settings to set up CFBundleExecutable equal to dppccl
-- actually this doesn't quite do it either]

Building everything you need in IB

Once you have a bundle all set up that will work with openmcl, you can
start making the nib file for your utility. Start Interface Builder
(IB) and select a Cocoa "Application" as your starting point. (If you
don't have passing familiarity with IB, work through a few chapters in
Learning Cocoa) For now I'm assuming that you won't be diddling with
the menu provided by the parent bundle, so select and delete the
MainMenu.

Pick a name for the custom NSWindowController that you will be using
to provide certain functions for your windows.  Under the Classes tab,
ubclass NSWindowController but don't instantiate your subclass.
Instead, return to the Instances tab, select the File's Owner
instance, and open the inspector (splat-shift-I) to look at its
attributes.  Select its class to be your subclass, and confirm the
decision to change the file owner's class.

Cross-link the File's Owner and Window instances by Ctrl-dragging from
one to the other and vice versa.  When doing so, set the Window's
delegate connection to be the File's Owner and the File's Owner's
window connection to be the Window instance.  This step will ease the
window creation and management process in lisp. [Note: it's not
entirely clear to me at the moment that you can't just blow away
File's Owner and replace it with a differently-named instance of your
window controller subclass. This may have something to do with how
memory allocation zones are set up, or tie into the way documents are
manageed, but at the moment it's black magic that just works.]  While
you're at it, select the window and uncheck the "Visible at Launch
Time" box in the Attributes.

Now use IB as you normally would, populating your window template,
making subclasses of NSObject for delegates and data sources, etc.,
etc., BUT note that you don't have to create files for any of your
subclasses of anything, because the code will be written in the lisp
world later instead. Save the IB nib file and add it to the resources
in your PB project, and build your bundle. Note that if you have your
OpenMCL bundle open in PB when you first save your nib file in IB
[maybe in other situations as well], it will ask you if you want to
add it to the project. It doesn't appear to make language-specific
chunks if you do that, so I don't know if that's the best way to add
the nib file.

|#

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel