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
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
