[Pythonmac-SIG] Why is Framework build of Python needed

[Christopher Barker]

Brian Granger wrote:
> Some people I am working with feel that doing a framework build is a
> bit of a hassle.  It means they/we have to support custom build logic
> on OS X compared to linux/unix, which I agree is a pain.

no matter how you slice, it you will have to do some custom support for 
OS-X if you want anything resembling a native Mac app. I suspect the 
framework build will be the least of it. You may not have to build your 
own Python anyway, and as was pointed out, extensions should be built 
with distutils, which will work the same on all platforms.

The far bigger hassles come from trying to support Universal binaries, 
if you need to do that, and depend on other libs not supplied by Apple.


Bill Janssen wrote:
> But there's no pressing reason Python has to supply that bundle.


> could build your own app using PyObjC to access the Cocoa GUI, using
> Python without a Python app bundle.

Can you? Isn't a PyObjC app using the Python executable as the "main" 
app, just like any other python program? You could write a ObjC app, and 
embed python, if that's what you mean, but that's harder, too.

>  The two things are logically
> separate, aren't they?  You can have a framework build of Python without
> having a Python application bundle.

yes, they are, but I think if you do a standard unix build, you don't 
get the application bundle -- not that you couldn't' create it yourself 
somehow, but the point here was to make it easier, no harder....

> I suspect that the default build of PyObjC assumes that Python is a
> framework build, too.

I'm not sure it's relevant, but it won't work without out it. I'm no 
PyObjC expert, but, for instance, you can run wxPython with the 
non-bundle python, it just won't work (the point being that there is no 
difference in wxPython itself). That's why there used to be two pythons: 
"python" and "pythonw", "pythonw" being required for GUI access.

Ned Deily wrote:
> FWIW, fink uses a "unix shared" library build rather than a framework 
> build for its pythons (at least the 2.5 version I have) and has PyObjC 
> packages for them.  I haven't tried to install them and have no idea how 
> well they work.

A few years back, you could only do X11 GUIs with fink python -- maybe 
they have changed that?

Bill Janssen wrote:
> I think this depends on what you think the "native Mac GUI" is, and what
> you want to do with it.  For instance, a non-framework build, combined
> with Xlib (http://python-xlib.sourceforge.net/) works quite well with
> the Apple X11 server, which in turn uses the native Mac GUI.

That's because it's the X11 server that is accessing the "native Mac 
GUI", not your app directly. But I don't think anyone is thinking X when 
they say "native" Mac GUI -- in fact, I think the entire point of using 
the term native is to distinguish between X and Carbon/Cocoa.

Ronald Oussoren wrote:
> And to be honest, I even have doubts about a toolkit such as Tk which 
> uses native widgets but has a rather un-mac feeling

I don't think TK does use native widgets -- it certainly didn't used to. 
It was originally built for X11, and got ported to other platforms by 
emulating the X11 drawing calls, still drawing its own widgets. I know 
they've added support for native standard dialogs, like the file dialog, 
but I think a great deal is still self drawn.

As opposed to wx, that does use the native widgets wherever possible.

> doesn't even ship with all components that are needed to get a proper 
> native L&F with Tkinter.

I think a proper native L&F is simple impossible with Tk

Kevin Walzer wrote:
> You've done terrific work getting IDLE to work with OS X. A lot of the 
> work that needs to be done with IDLE modernizing its interface simply 
> can't be done at a platform-specific level.

but wouldn't making it more OS-Xish require platform specific 
modification? Or do you mean the the toolkit itself has to support that 
level of platform customization?

Anyway, it's nice to see TK getting attention, particularly on the Mac.

Bill Janssen wrote:
> Yes, I agree with all that -- anything non-Cocoa isn't "real".

I think Carbon is still real -- though it is on its way out...


-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov