Re: [Pythonmac-SIG] Why is Framework build of Python needed
On 14 May, 2009, at 1:03, Bill Janssen wrote: Christopher Barker chris.bar...@noaa.gov wrote: Brian Granger ellisonbg@gmail.com wrote: I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? Pretty much -- to access the Mac GUI, an app needs to be in a proper Mac application bundle. But there's no pressing reason Python has to supply that bundle. You could build your own app using PyObjC to access the Cocoa GUI, using Python without a Python app bundle. The two things are logically separate, aren't they? You can have a framework build of Python without having a Python application bundle. I suspect that the default build of PyObjC assumes that Python is a framework build, too. But I don't know if you could build a non-framework Python and non-framework PyObjC, and use those together to write Python programs that could access Cocoa. I suspect you could, but I also suspect it would be a lot of work. And more importantly: most other users use a framework, as well as all py2app and pyobjc developers. That means that you're more likely to run into problems using a non-framework installation of Python, and that you'll get less help when you do. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
On 14 May, 2009, at 4:31, 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. This is totally off-topic, but I don't think an X11 based UI is a native Mac GUI. Anything that's a native GUI should at least conform to the usual UI conventions of OSX, such as a per-application menu instead of per windows menu's. 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 unless the developer really knows what he's doing. That explains why IDLE looks ugly on OSX, I don't know what I'm doing w.r.t. Tk on OSX, and AFAIK Python's stdlib doesn't even ship with all components that are needed to get a proper native LF with Tkinter. Ronald Bill Brian Granger ellisonbg@gmail.com wrote: Hi, I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? If so, is this requirement documented somewhere? Thanks! Brian ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
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 unless the developer really knows what he's doing. That explains why IDLE looks ugly on OSX, I don't know what I'm doing w.r.t. Tk on OSX, and AFAIK Python's stdlib doesn't even ship with all components that are needed to get a proper native LF with Tkinter. Ronald, 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. There are two interesting developments that will affect Tkinter in the near future: 1. The ttk themed widgets will now be part of the Python standard library starting with 2.7 and 3.1 (http://gpolo.ath.cx:81/projects/pyttk/). Guilherme Polo did this as a GSoC project. I believe IDLE will be using the new widgets as well. That will help a great deal. 2. A port of Tk to run on top of Cocoa instead of Carbon by Tk-Aqua's maintainer, Daniel Steffen (with support from Apple), is now substantially complete: see http://github.com/das/tcltk/tree/de-carbon-8-5. It's still currently a fork/branch of the main Tk development, and probably won't be committed to the main line until later (perhaps Tk 8.6, which may not be out for another year), but it works beautifully. I'm currently testing a four-way universal build of Python and Tk-Cocoa. IDLE looks a bit weird because of some menu layout issues (there are a few differences between Tk-Carbon and Tk-Cocoa), but those can be adjusted with some patches--I may work some up at the appropriate time. Thanks, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
Ronald Oussoren ronaldousso...@mac.com wrote: On 14 May, 2009, at 4:31, 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. This is totally off-topic, but I don't think an X11 based UI is a native Mac GUI. Anything that's a native GUI should at least conform to the usual UI conventions of OSX, such as a per-application menu instead of per windows menu's. 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 unless the developer really knows what he's doing. That explains why IDLE looks ugly on OSX, I don't know what I'm doing w.r.t. Tk on OSX, and AFAIK Python's stdlib doesn't even ship with all components that are needed to get a proper native LF with Tkinter. Yes, I agree with all that -- anything non-Cocoa isn't real. I was just wondering what the OP meant by native Mac GUI. Though we could have lots of fun arguing about whether the X11 server provides access to the native Mac GUI... :-). Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
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 LF with Tkinter. I think a proper native LF 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/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
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
Re: [Pythonmac-SIG] Why is Framework build of Python needed
Christopher Barker wrote: 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. Tk does use an X11 emulation layer for things like window management, drawing of graphics (such as polygons on the canvas widget), keyboard events, etc., but these functions are all mapped to native API's (CoreGraphics, Carbon, etc.). As well, core widgets such as the menu, buttons, scrollbars, etc. are mapped to native API's. In some cases, widgets are composites, using platform-native drawing primitives for their components but having their behavior implemented at the script level. doesn't even ship with all components that are needed to get a proper native LF with Tkinter. I think a proper native LF is simple impossible with Tk I disagree with this, but it's partly a matter of opinion and partly a matter of how much attention the developer pays to platform specifics. It's true that out-of-the-box, Tk doesn't look especially native, especially if it's an application that has been ported from Windows or other Unix platforms. However, with some attention to platform details, such as spacing, colors, icons, etc., I think Tk can look pretty good. Certainly my own application with a *lot* of Mac-specific tweaking, strive to meet platform-specific conventions. To a lesser degree, this is true of any cross-platform toolkit. I've seen some wxPython apps that look awful on the Mac, and some wxWidgets wrappings of Mac widgets--such as a combox--don't look correct at all. On the other hand, a wxPython app like Editra, which really pays attention to the way it's implemented on the Mac, looks great. 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? Some of both. The awful notebook widget that IDLE uses in its preferences window could be swapped out with the more modern themed notebook widget that uses Mac-native tabs on OS X. That's toolkit-level customization, and it's what Guillhereme has added with his port of ttk to the standard library. Platform-specific customization is the kind of stuff that Ronald's done with keyboard shortcuts, placement of items in the menu, etc. Anyway, it's nice to see TK getting attention, particularly on the Mac. I strongly agree here. I was beginning to look around at different toolkits, but when I discovered Tk was being ported to Cocoa, I stopped. It means that Tk remains viable on the Mac. I've posted a bit more about Tk-Cocoa here: http://www.codebykevin.com/blosxom.cgi/2009/03/07#tk-cocoa-at-last 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... I agree with Chris here. If Carbon isn't real, then the Finder isn't real, iTunes, etcbut it is definitely on the way out. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Why is Framework build of Python needed
Hi, I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? If so, is this requirement documented somewhere? Thanks! Brian ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
The Mac comes with a Framework build of Python pre-installed (and with PyObjC pre-installed, which you also need). Just use /usr/bin/python, and you'll be fine. It's the default way that Python builds on a Mac, too. Bill Brian Granger ellisonbg@gmail.com wrote: Hi, I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? If so, is this requirement documented somewhere? Thanks! Brian ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
Brian Granger ellisonbg@gmail.com wrote: I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? Pretty much -- to access the Mac GUI, an app needs to be in a proper Mac application bundle. The Framework build supplies that. Technically, the use of a framework is independent for this requirement, but using a Framework build is the easiest way to satisfy it. Do you have a reason for not wanting to use a Framework build? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
Pretty much -- to access the Mac GUI, an app needs to be in a proper Mac application bundle. The Framework build supplies that. Technically, the use of a framework is independent for this requirement, but using a Framework build is the easiest way to satisfy it. OK. Do you have a reason for not wanting to use a Framework build? 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. But there are no fundamental reasons we are opposed to a Framework build. Just a bit more work for us. Cheers, Brian ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
Christopher Barker chris.bar...@noaa.gov wrote: Brian Granger ellisonbg@gmail.com wrote: I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? Pretty much -- to access the Mac GUI, an app needs to be in a proper Mac application bundle. But there's no pressing reason Python has to supply that bundle. You could build your own app using PyObjC to access the Cocoa GUI, using Python without a Python app bundle. The two things are logically separate, aren't they? You can have a framework build of Python without having a Python application bundle. I suspect that the default build of PyObjC assumes that Python is a framework build, too. But I don't know if you could build a non-framework Python and non-framework PyObjC, and use those together to write Python programs that could access Cocoa. I suspect you could, but I also suspect it would be a lot of work. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
In article 6ce0ac130905131523m7c4002e9i18816fd6dad37...@mail.gmail.com, Brian Granger ellisonbg@gmail.com wrote: Do you have a reason for not wanting to use a Framework build? 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. But there are no fundamental reasons we are opposed to a Framework build. Just a bit more work for us. FWIW, if you are building and installing python modules and/or C extensions, distutils or setuptools should generally be able to transparently handle the framework-specific details for you. -- Ned Deily, n...@acm.org ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
In article 15498.1242255...@parc.com, Bill Janssen jans...@parc.com wrote: I suspect that the default build of PyObjC assumes that Python is a framework build, too. But I don't know if you could build a non-framework Python and non-framework PyObjC, and use those together to write Python programs that could access Cocoa. I suspect you could, but I also suspect it would be a lot of work. 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. -- Ned Deily, n...@acm.org ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
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. Bill Brian Granger ellisonbg@gmail.com wrote: Hi, I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? If so, is this requirement documented somewhere? Thanks! Brian ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
