[Pythonmac-SIG] Could the MacOSX Python core be a framework?

[Steven D. Majewski]

On Sun, 24 Jun 2001, Jack Jansen wrote:

> I've been musing a bit more about what MacOSX Python should eventually
> look like, and I've come up with the following idea that I'd like some
> feedback on. I'm still pretty weak on all this framework stuff, so
> what I'd mainly like to know is whether the following is feasible, or
> whether I don't have a clue about the matter in the first place.
> 
> What I was thinking is that if we turn the core Python (based on the
> unix Python, this would basically be what is in PythonCore for
> MacPython, but then based on the unix sources) into a framework we
> could then provide two programs using this framework:
> 1. a commandline based python
> 2. a GUI-based python

Yes -- this is basically what I was thinking about in an earlier thread
when we were discussing unifying the MacPython & MacOSX-Python 
distributions. The main reason, for now, to keep two different distribs.
is CFM vs mach-o and needing a CFM version for OS8/OS9. 


 I think what we eventually want is a Python.app (GUI version) which
is a bundle which contains the python framework ( shared-lib, 
resources, Nibs and the python-lib files ) and also contains a
command line executable ( for which you'll likely want to add a
symbolic link in /usr/local/bin ) 
 Except for that symbolic link, the whole thing can be installed
by dragging the app from a .dmg image. 
 The OSX equivalent of BuildApplication would clone all of the
used files (resources,libs,etc.) into a new application bundle. 
 Applets would be similar, except for sharing the same framework
as Python.app rather than cloning one.
 We could probably have an install script to generate symbolic links and
separate applets like the IDE from the Python.app bundle/framework.

 That is a slightly different organization than you were outlining. 
  Some of this is inspired by the problems I found in making a 
  terminal based python create a GUI -- some things do work, but 
  others seem to assume that there is an Application bundle, which
  is missing from simple unix command line programs. 

 
 We can probably have both a Carbon based App shell and a Cocoa
based App shell.  I don't think there're any problems calling 
Carbon from Cocoa, but since Cocoa is a more complet framework,
there may be problems calling Cocoa from a Carbon shell: I would
think calling NSApplication.run() might block some of the Carbon
event dispatching, while going the other way, unhandled Carbon
events will just fall thru. I'm not sure about this. But we may
NEED as well as want alternate application shells. 
 

> The first one would simply be a skeleton main program that calls out
> to the main routine in the Python framework. The second would be a
> .app package with all the plist and PkgInfo and other jazz. In the
> gui-based Python you would probably lose stdin/stdout/stderr, but
> that shouldn't be too much of a problem because it would mainly be
> used during testing things that are to become applets. And maybe we
> can keep stdin/stdout/stderr, does anyone know of a way to get at
> these for Mach-O/libc-based .app packages?

stderr, at least, goes to the console.app in most GUI programs -- 
maybe stdout too by default. 

It is also possible to open a Terminal.app window with a command
for that window -- which can be a program that acts as a sort of
of terminal server to a GUI app. If you didn't want to open a 
GUI stdin/stdout command window, you could probably have the
GUI python app open up a Terminal.app window and start telnet
to localhost and a known port number on which it was already 
listening for a connection. ( I'm not that sure it's worth doing
that way, since you already seem to have GUSI carbonized, and 
ToxicEdit is a start on a Cocoa front end -- enough to show it
not hard. ) 

-- Steve Majewski

[ I haven't done much new with OSX Python as I've been back on
  trying to finish up a Lisp app before I leave for a vaction 
  at the beach in Chincoteague. ]