[Pythonmac-SIG] Guidance, please?

[Bob Ippolito]

On Apr 1, 2005, at 12:20, Kent Quirk wrote:

> I’m porting a commercial Python/C++ application from Windows to Mac, 
> and trying to preserve 95% of the code base as completely cross 
> platform. It’s an OpenGL application that constructs its own GUI in 
> the window, so I don’t need ANY UI widgets. At all.
>
> I should warn you that this is my first experience coding for the Mac, 
> though I have written code for a variety of platforms.
>
> The way it works on the PC side is that Python code calls a 
> createWindow function in our app to manufacture the main window. This 
> creates and initializes an OpenGL context. It then calls a mainloop() 
> function that only returns when the app closes. The mainloop() knows 
> about the GL context and can manipulate it.
>
> Our first pass at the port attempts to use Carbon to do the same 
> thing. Everything has compiled and the app basically runs, but there 
> are definitely issues, and in many ways the world would be made much 
> nicer if we did something more appropriately “native” to the Mac 
> platform.

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.

>  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.

> 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

>  b)     The intent is to create a single application that will run on 
> as wide a range of OS X machines as possible. We’ve been developing on 
> 10.3 and messing about with 10.4, and that’s cool, but first blush 
> seems to indicate that supporting 10.2 is much more problematic than 
> 10.3. Am I correct about that? How much work is it to support both? Is 
> it worth the trouble? I don’t care about developing on 10.2, only 
> about delivering on it.

It is simply not really possible to build on 10.3+ and have it work on 
10.2.  You must build on the lowest common denominator platform, or 
build entirely from components built on the lowest common denominator 
platform.  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.

> 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.

-bob