Eric Peyton was kind enough to forward this email to me. I'm
responding to you and the lists-- hoping that the moderators approve the
message [hoping that it will be valuable enough to do so].
On Tuesday, March 19, 2002, at 10:56 AM, Eric Peyton wrote:
From: Kevin Ollivier <email@hidden>
Date: Mon Mar 18, 2002 10:55:52 PM US/Central
To: email@hidden
Cc: email@hidden
Subject: Porting wxPython to Mac
Hi all,
I've been helping out with an initiative to port wxPython
(http://www.wxpython.org) to the Mac OS X platform. For those who aren't
familiar with it, wxPython is a wrapper to make wxWindows, a
cross-platform (Win/Mac/Linux) GUI API, accessible in Python. wxWindows
itself has already been ported to Mac and is Carbonized, so it is very
close to being a working product. However, a couple of interesting
issues have arisen regarding the Python interpreter on Mac. I hope that
Apple is listening to this, because these are some tough ones! =)
1) Multiple Instances: The Python Interpreter has an app bundle version
available ("Python.app"), but this has the side effect of not allowing
multiple instances of the Interpreter to run. I know that on Macs, it is
standard behavior for only one instance of an application to run, but
since Python is a script interpreter, we'd like it to behave more like
the Mac's Java JAR launcher utility, considering each script as a
separate application. Is there anyway to get Python.app to launch a
separate instance for each script the user runs?
The Java JAR Launcher utility [unfortunately] uses private API to achieve
said functionality. To further complicate matters, the bundle role of
'Shell' doesn't seem to actually do what it is documented as supposedly
doing-- namely, causing an application to *always* launch new instances
for any given document (in this case a 'document' is a python script).
I have investigated this in the past, but can't find the message.
In any case, the answer is to write a small wrapper application-- likely
Cocoa, because it'll be the easiest/most trivial to write-- that registers
itself as a handler of files with a '.py' extension (just like JAR
launcher registers itself as a handler of 'documents' with a '.jar'
extension).
In the file open request handler, use the Launch Services API to launch a
new instance of the python interpreter [with icon] against the script that
is to be 'launched'. I.e. pass the 'kLSLaunchNewInstance' flag to the
LSOpenFSRef() function.
2) Sharing Menus: Another interesting problem is that wxPython does not
get its "own" menubar, that is, all wxPython windows and menus are
considered part of Python.app's resources. As a result, trying to create
a new menubar fails, and the only alternative we've found for OS X is to
have wxPython overwrite Python.app's menubar for its script. (At the
moment, Python.app doesn't use its menubar so this isn't a problem, but
we'd like to avoid having its contents overwritten if possible.) Is
there any way for wxPython to create its own menubar, so it won't use
Python.app's?
I'm not sure I understand.
As long as all wxPython processes are just that-- individual processes--
each should have its own menubar.
If you mean that the wxPython based app needs to overwrite Python.app's
menubar as in *replace* it, there seems to be a slight bit of magic
associated with the menu immediately to the right of the Apple-- the
application's first menu.
If anyone is so inclined, steps for building wxPython on Mac are
available at:
Cool. Thanks. I'll see if I can't make a Fink package out of all of
this. However, what is the relationship between the Python.app build and
the standard command line based python build?
Thanks in advance for your help!
_______________________________________________
unix-porting mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/unix-porting
Do not post admin requests to the list. They will be ignored.
