在 OS X 10.8(64 位)上运行 wxPython 2.9 [英] Running wxPython 2.9 on OS X 10.8 (64 bit)

查看:64
本文介绍了在 OS X 10.8(64 位)上运行 wxPython 2.9的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有 EPD 7.3 并通过 Enthought 存储库安装了 wxPython 2.9.我尝试运行需要 wxPython 的 winPDB 并收到此消息:

I have EPD 7.3 and have installed wxPython 2.9 through the Enthought repositories. I tried running winPDB, which requires wxPython and I got this message :

This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.

我在 Mac 上看到过来自 wxPython 的类似消息,但我还没有找到解决方案.有没有人知道这条消息?并且,有没有人让 WinPDB 在带有 wxPython 2.9 的 OS X 10.8 上工作?

I have seen similar messages from wxPython on Mac, but I haven't found a solution yet. Does anyone know about this message? And, has anyone got WinPDB to work on OS X 10.8 w/ wxPython 2.9?

推荐答案

当用于运行 wxPython 脚本的 Python 不是完整的框架构建时,会出现此错误消息.OSX 要求获得屏幕完全访问权限的应用程序从应用程序包中运行或作为框架的一部分运行.

This error message will happen when the Python used to run a wxPython script is not a full framework build. OSX requires that applications that are given full access the screen be run from an application bundle or are part of a framework.

现在通常所有 Python 都是框架构建,无需再担心这一点,但是有一种情况仍然存在问题,那就是使用 virtualenv 或类似工具.随着 virtualenv 的构建方式,那里的 Python 与它来自的框架失去了联系,因此使用它直接触发该安全机制,并且 wx 代码无法完全访问屏幕.如果您在 virtualenv 中遇到问题,那么我在这里编写了一个解决方法:http://wiki.wxpython.org/wxPythonVirtualenvOnMac

Usually all Pythons are framework builds these days and there is no need to worry about this any more, however there is one situation where it is still an issue, and that is with virtualenv or similar tools. With the way that the virtualenv is constructed the Python that is there sort of loses its connection with the framework that it comes from, and so using it directly triggers that security mechanism and the wx code is not able to get full access to the screen. If you are experiencing a problem in a virtualenv then I've written up a workaround here: http://wiki.wxpython.org/wxPythonVirtualenvOnMac

嗯...我刚去 EPD 仔细检查了一下,我发现他们提供的python"可执行文件不像正常框架构建中那样是 Python.app 二进制文件的前端,但更像是一个普通的 unixy Python.由于我现在在 Enthought,我会询问责任方这是错误还是有意为之,但与此同时,您可以通过更改正在执行的 Python 来解决此问题.例如,您可以在指向 Python.app 二进制文件的 bash shell 中创建一个pythonw"别名,如下所示:

Hmm... I just went to double-check this with EPD and I found that the "python" executable they provide is not a front-end for the Python.app binary like in normal framework builds, but is more like a normal unixy Python. Since I'm at Enthought now I'll ask the responsible parties if this is a bug or is intended, but in the meantime you can work around this by changing which Python is being executed. For example, you could create a "pythonw" alias in your bash shell that points to the Python.app binary, like this:

alias pythonw=/Library/Frameworks/EPD64.framework/Versions/7.3/Resources/Python.app/Contents/MacOS/Python

那么你应该可以通过使用 pythonw 而不是 python 来运行 WinPDB 或其他 wxPython 应用程序.

Then you should be able to run WinPDB or other wxPython applications by using pythonw instead of python.

这篇关于在 OS X 10.8(64 位)上运行 wxPython 2.9的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆