Christopher Barker <chris.bar...@noaa.gov> wrote: > > 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?
Yes, using the Python executable. But if you start with Xcode, and create a Python-Cocoa application, what you get is a separate app that's composed of a shim layer in Objective-C which starts up an embedded Python interpreter and runs "main.py" in that interpreter. That's what I was talking about. > You could write a ObjC app, > and embed python, if that's what you mean, but that's harder, too. Not when Xcode does it for you. > > 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 That's right. > > 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. At the very least, you'd probably have to re-build wxPython against the non-framework Python, which seems like a lot of work. > 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. Even Carbon's not native, IMO! But X does draw on its windows using Carbon -- it's just at arm's reach :-). > 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. The Tk canvas has alway seemed to me a nice appropriation of Joel Bartlett's most excellent ezd system (http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.html). But it's really 80's technology, so far as GUI toolkits go. > 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... We could have a holy war about that :-). Bill _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
