[Pythonmac-SIG] Guidance, please?

[Kent Quirk]

Thank you for the reply.

> Well, Carbon is perfectly native.. if it has issues, then you're doing 
> something wrong.  However, Carbon is a pain, and I would never 
> recommend it for new code -- especially if you don't know your way 
> around.

I'm beginning to believe that. :-) 


> >  This is what I've come up with so far:
> >
> > Build a Python and NIB-based application similar to the OpenGLDemo 
> > application found in PyOpenGL. Basically, we construct a NIB and a 
> > driver module that doesn't do a whole lot more than instantiate an 
> > NSOpenGLView.  The startup Python code for the app creates that window 
> > and has a bunch of handlers in place for all the user and window 
> > events. The aglContext object is retrieved from the NSOpenGLView and 
> > passed in to the C++ code for use in rendering.  The handlers dispatch 
> > their various events as needed within the application structure. In 
> > most cases, they will be able to stay in python, but in some cases 
> > (resize, for example) the information will have to get passed in to 
> > the C++ code.
>
> Ok, just to clarify here, you're talking about PyObjC, not PyOpenGL.  
> There is nothing Mac specific in PyOpenGL, especially NIB-related.

Sorry, you're correct, of course. 

> > A few questions:
> >
> > a)     Is this a reasonable architecture? Please understand that 
> > rewriting our entire application to be more "Mac-ish" is not an option 
> > in this release.
>
> It's unclear how you're doing these "handlers" to capture events.  
> Unless mainloop() pumps the NSRunLoop in some way, you're going to have 
> some real problems...  Cocoa is designed to facilitate event driven 
> applications (and so is modern Carbon).
>
> Ideally you'd have an event driven application.  If you don't, that 
> sucks, but you can pump the events, at the expense of CPU time.  There 
> is some discussion of this at: 
> http://www.cocoadev.com/index.pl?FlushingAppEventQueue

It is in fact an event driven app on the mac. On the PC, we pump the events. Our Carbon implementation of mainloop installs a timer and then just calls RunApplicationEventLoop().

I don't mind removing the call to mainloop entirely if that's what makes sense in a Python/Cocoa implementation. 

What I meant by handlers are the methods that handle the operating system events. Currently they all come in to an event dispatcher which calls various methods in Python or C++. I'm perfectly happy to have that dispatcher be a collection of Python methods. 

I hope I've been clearer about it: is this making sense now? If not, maybe the question I should be asking is this:

	"I am porting a Python-based OpenGL application that needs to play nice on Mac OS X. What it needs is the ability to open an OpenGL context, set the cursor, get mouse and keyboard events, and have access to various platform APIs like printing and Quicktime. Given that I've never coded in Objective C, what's the best way to implement it?"

My premise here is that the answer starts with PyObjC. But I'm still struggling with how to structure it.


> My personal recommendation would be to develop on Mac OS X 
> 10.3.  10.4 support will come for free.  When you're done with 
> everything else, you can take care of getting everything compiled and 
> built on 10.2.

Thank you. That's what I needed to hear.


> > c)     PyOpenGL seems to be constructing a menu that says things like 
> > "CocoaGL". I don't know how to change it, and it's not obvious from 
> > the combination of the demo app and the documentation I've managed to 
> > absorb to date.
>
> Again, we're talking about PyObjC.  Read the documentation regarding 
> Info.plist or the plist option to py2app.  In particular, this has to 
> do with the CFBundleName (and possibly related) keys.  py2app defaults 
> to using the name of the script you give it as the CFBundleName, which 
> is usually convenient.

Ah. I haven't taken the time yet to understand py2app. Back into the pool!