在 Python 世界中有个非常有趣 [anygui] 项目它已经进入了早期开发阶段[anygui] 项目打算作为许多主要图形工具箱下层 API旦完全开发成功Python 员就可以个公共 [anygui] ― 例如为创建个窗口 ― 可由“最适当好用”工具箱来完成这项工作在 Windows 上可以使用到 Win32 API(或者 wxWindows)；在 MacOS 上可能本机；在 BeOS 上使用 Bethon；在 Linux 上使用 TKer 或者 GTK；在 Telnet 屏幕上使用 ncurses ― 所有这些都取决于给定机器上安装和可用软件Software本文讨论了 [anygui] 当前开发状态以及该项目要达到目标

　　编写次到处显示！

　　许多年前当 Java 刚出现时它个重要承诺就是实现代码“编写次随处运行”想法起先主要考虑将 Java 用户界面作为 applet嵌入到 Web 浏览器中段时间后独立 AWT 应用成为更流行概念接下来AWT 通常被 Swing 所取代Swing 又变成了 Bean(构建在 Swing 上但有另外要求)这样依次下来Swing 类从 Java 版本中添加、删减不断来回变化着

　　有关 Java 个很流行笑话是“编写次到处 调试”至少可以确定是您不可能编写了个 Java 应用后非常自信地认为它可以运行在您应用每个用户机器上 ― 除非您愿意要求每个用户做相当多工作来获取 Java 版本和配置使它们完全符合您特定应用应用是否运行取决于 Java 版本以及甚至特定供应商和安装 Java 虚拟机(JVM)平台

　　就大多数方面而言如 Python、Perl 和 Tcl 这样脚本语言要比 Java 具有更好可移植性例如对于大多数 Python 脚本员感到十分自信是发送到多个用户脚本在每台目标机器上都将正确和完全致地运行(可能有最低版本要求 ― 这要比 Java 上要求简单得多、可靠得多)当然Java 除了不完美移植性外它也有许多优势:静态输入(许多人想要它)、庞大类库、卓越文档、细心设计选择但是有关那些语言注意事项并不是我在这里感兴趣话题

　　Python 脚本可移植性中有个地方比 Java 差很多那就是在用户界面中对于个命令行工具这点不成问题但当您希望复杂用户交互时 ― 特别专门针对图形界面时 ― Python 实际上什么也不能提供对于所有小故障和小Java 通常确实为每个带 JVM 平台提供了 Swing 和 AWT 这些基本 GUI相反Python 完全没有任何“标准” GUI 库

　　许多人都表示他们期望有标准 Python GUI Tker 恰在这时到来 ― 它有 Windows 和 UNIX/X Window 系统稳定版本并且有个过得去 MacOS 版本但您还需要在系统上安装 TCL 和 TK以及被忽略“非主流”平台如 BeOS 和 OS/2各类倡导者建议采用些其它库／绑定将会是个更好选择(有许多库可以进行选择；请参阅 参考资料)而每个库／绑定支持个期望平台子集；并且最重要是没有个库／绑定被致地接受(因此没有个成为标准而随 Python 分发版起发行)我们无法编写带用户界面应用并且无法确保实际 用户可以和它进行相互操作

　　重新考虑这个问题

　　Java 思想创建了每个 JVM 必须实现能力个标准集合Java GUI 是根据规定而存在Python 式思路方法可能来自个区别角度不再命令每台机器遵从某个确定 API取而代的是只是确定给定机器 可以做什么然后从那里开始工作API 仅作为底层平台所完成工作包装器

　　旦以 Python 方式考虑问题时 anygui 做了您确实希望做事情从 anydbm 模块中取出它名字和相关介绍说明在运行时找到“最适当可用”数据库后端 anygui 在自身应用正在运行系统上会找到最适当可用 GUI 后端 anygui 强调提供个可以和每个后端起工作 实用界面元素集合；特定后端可能自己能够提供更高级界面但 anygui 提供是它们公共界面

　　写本文时候 anygui 还是个 alpha 级项目对个目标后端子集 anygui 已经做得非常好但由于目标是建立个(接近于)通用包装器只有个子集在工作显然是不够最终如果 anygui 达到了它目标则在每个 Python 分发版中 anygui 都将作为标准 Python 包包含在其中那才是有意义(就如同不管什么依赖于系统后端Python 分发版中都包括了 anydbm 或者 xml.sax )毕竟这点才能确保每个用户都拥有了它顺便提下 anygui 是纯 Python；它本身不需要 C/C 或者其他较低级语言任何东西(当然如果有用 anygui 应该找些支持 GUI 库)

　　台和图片

　　为了写本文我快速研究了大多数工作后端还有几个后端没有实现或者只实现了部分功能已经实现有 Tker 、Java Swing、 win32all 、 PyGTK 和 wxPython BeOS 本机(带 Bethon)只实现了部分功能但可能每天都构建次进行新改进PyQT 和 MacOS 本机已经编制了规划并且已经进行了开发还没有创建这些包装器实现；当然随着时间推移这些都可能发生变化有关直接 xlib 后端也直有些讨论但目前没有人自愿负责这项工作

　　上面所有图形工具箱以种非常相似方式工作或将以种非常相似方式工作我承认我在大多数后端工具箱方面知识很有限 ― 但从我理解 anygui API 在很大程度上和 Tker 相似本质上这个策略是创建带回调串窗口小部件然后进入个主事件循环

　　将来还可能会有些其它后端它们会打破这个“标准” GUI 工具箱模型在某些方面它们看起来似乎最有趣或者至少很新颖个已经规划好后端被期望由我来负责 ― 但是在开发最初版本时我有点懈怠希望在您读本文时这会有所改进我自己开发小型后端是 ncurses 如果它最终实现则这开创了甚至在文本模式终端(譬如SSH/telnet 会话)或者只是在纯 UNIX 机器(不带 X Window 系统)上运行 anygui 应用可能性

　　按照 curses 后端风格 anygui 项目负责人 Magnus Lie Hetland 已经建议了纯面向行界面(似乎有点倒退)它可以使用 readlines 支持在这个方案中菜单将简化成提示符接着是选项选择再接着是反馈或者结果等等假想中 anygui.backends.textgui 只需要 STDIN 和 STDOUT 来工作这对于来说是令人感兴趣它所需要最少否则该可能(点未变动)运行在复杂图形化、事件驱动和 WIMP 界面(窗口、图标、鼠标指针)当然到目前为止它还只是个想法

　　还有个古怪想法也同样有趣每人都有个 Web 浏览器(几乎)即使那个浏览器碰巧是 lynx 或者是 links Python 标准 webbrowser 模块允许以种和 anygui 以及和 anygui 具有相似功能软件Software方式灵活地启动个“最适当可用” Web 浏览器如果那个浏览器和某类 LOCALHOST 服务器通信那么所有您想要基本界面设备都完全在 Web 浏览器内(按钮、输入域、文本区域、图形等等)这个后端也处于规划阶段

　　幅图片抵得上用千言万语来表达含义(至少有时候)由于我编辑们出于善意不希望将本专题出版为万字巨著所以就让我们看几幅屏幕快照为了介绍说明需要使用了个小玩具应用有些按钮并且启用了几个不活动性按钮(它源代码显示如下)其中还包含了几个文本标签其它窗口小部件举例包含在 anygui 分发版 test 目录中

　　首先值得看我们可能认为是作为“默认缺省值”后端 Tker 这个版本看上去和使用起来就和它应该做到完全致但是 win.destroy 就有点好笑 ― 它没有立即破坏窗口(并且关闭应用)而是旦当窗口受到足够注意(比如移动窗口)它就将窗口变为个会消失鬼怪如同我说我们还停留在 alpha 阶段这个举例在 Win98 下运行:

　　Tker 下按钮应用(在 Win98 上)

　　win.add(hi)
win.show
app.run



　　应用主框架只由 4个步骤组成:(1)创建个应用；(2)创建个或多个窗口；(3)在窗口中添加些窗口小部件；(4) app.run 事件循环窗口小部件选项都作为命名参数传递

　　结束语

　　在目前 anygui alpha 版中已经有编写基本“获取些数据对它进行处理并且显示些结果”应用所需要切东西讨论列表中包含了许多有关更多细微差别事件处理、视图模型等有趣主题此外 anygui API 还需要正式地编制文档然而在承诺方面在很长段时间内 anygui 和我看到任何 Python 库相比更令我兴奋几乎很难想象在 Python 自身运行地方它能够透明地获取复杂用户界面这是多么方便 ― 根本不需要为平台细节方面更改行代码