2005-4-4:
一直久仰XUL的大名,但是一直也没有机会尝试XUL的使用,碰巧有机会要做一个IM产品,于是想尝试一下XUL,XUL是否能够完成任务呢?看了看Firefox和Thunderbird,感觉一下子信心倍增。那就按着IM软件这个想法,开始XUL的学习之旅。
首先从XUL老家的教程开始http://xulplanet.com/tutorials/xultu/
IM软件的样子现在都差不多,就以POPO和MSN的样式为例,参照着实现。通过半天的学习,界面完成如下:
此主题相关图片

此主题相关图片

然后又仔细看了一下文档,界面美化优化靠CSS就可以了,而且也支持HTML标签,数据靠RDF也可以搞定,现在要解决的问题就是如何脱离Mozilla运行XUL程序。
XUL源程序如下:
此主题相关文件 111726.zip
补充一下:
为何要使用XUL?
XML User-interface Language,简称 XUL(如果您想酷一点儿,可以念作“zool”),它在 Mozilla Platform 中的地位就是 Swing 在 Java 环境中的地位,或者是 Gtk 在 X-Window 环境中的地位。它是一组 GUI 控件。这些控件适合用于具有传统的非-HTML GUI 的应用程序。有很多基于 Mozilla 的浏览器,它们的菜单、工具栏、滚动条、对话框等等都是用 XUL 文档构建的。
XUL 具有广泛的跨平台支持——Macintosh 菜单看起来就是 Macintosh 的菜单,GNOME 按钮看起来也就是 GNOME 的按钮。为了达到这样的目的,XUL 紧密依赖于当前平台的固有控件。这样的策略类似于 IBM 支持的 Eclipse 开发工具。不过这种相似性也是有限的,因为 Eclipse 最终发布的 GUI 控件是 Java 类,而 Mozilla 发布的控件是 XML 的 XUL 方言中的标签。
XUL 存在的理由何在?多半是因为 HTML 适合显示超文本文档,但是却不适合显示 GUI。传统的基于 Web 的应用程序花费了无穷无尽的力量,试图强行让 HTML 具有传统表单/菜单形式的应用程序的外观。可是 HTML 当初根本就没有打算达到那样的目的。
向 HTML 中增加表单元素(即 FORM)无非就是创建了一种新的方法,以仿照古老的 3270 终端风格实现瘦客户机块模式(block-mode)应用程序。HTML 与 3270 一样,也提供了批处理方式的表单提交机制。基于字符模式的应用程序最终发展成十分高效的用户导航系统,但是当 GUI 应用程序出现的时候,这一切就都消失了。随后,GUI 应用程序也用鼠标和控件反馈的方式,实现了自己的界面导航结构。
当 HTML 表单登上历史舞台的时候,它们模仿了块模式终端的设计,但是却没有提供紧凑的导航机制,也没有用适当的 GUI 来代替它。在 HTML 之下,用户不得不自己猜测,页面上哪一个可视元素是用户可以控制的,哪一个又仅仅是装饰。因此对于 GUI 驱动的应用程序而言,HTML并不是一个很好的起点。这也正是为什么 Java applet 刚刚出现时市场上会出现一片热烈的响应,因为 Java applet 是实现真正 GUI 的一个机会。
现在 XUL 到来了。XUL 沿袭了 HTML 的极瘦客户机模式,但稍微让它变胖了一些。除了任何极瘦客户机都会提供的几种最平常的表单元素之外,XUL 还像复杂些的客户机软件一样,提供了完整的控件组。
在过去,这样的客户机软件可能是编写成 Java 应用程序,可能是用 Tcl/Tk 或 Visual Basic 编写的。现在,更胖的客户机可以实现为一个或者多个 XUL 文档,并且可以通过 Web 传递(或者仅仅进行本地处理)。应用程序的表现形式一开始是一个文档,而不再是一组对象。一个运行着的 Mozilla 平台读取那个文档,然后显示指定的 GUI,供用户使用。
这样,XUL 就将 HTML 轻量级的优势与传统 GUI 结构化的可用性结合起来了。
一直久仰XUL的大名,但是一直也没有机会尝试XUL的使用,碰巧有机会要做一个IM产品,于是想尝试一下XUL,XUL是否能够完成任务呢?看了看Firefox和Thunderbird,感觉一下子信心倍增。那就按着IM软件这个想法,开始XUL的学习之旅。
首先从XUL老家的教程开始http://xulplanet.com/tutorials/xultu/
IM软件的样子现在都差不多,就以POPO和MSN的样式为例,参照着实现。通过半天的学习,界面完成如下:




然后又仔细看了一下文档,界面美化优化靠CSS就可以了,而且也支持HTML标签,数据靠RDF也可以搞定,现在要解决的问题就是如何脱离Mozilla运行XUL程序。
XUL源程序如下:

补充一下:
为何要使用XUL?
XML User-interface Language,简称 XUL(如果您想酷一点儿,可以念作“zool”),它在 Mozilla Platform 中的地位就是 Swing 在 Java 环境中的地位,或者是 Gtk 在 X-Window 环境中的地位。它是一组 GUI 控件。这些控件适合用于具有传统的非-HTML GUI 的应用程序。有很多基于 Mozilla 的浏览器,它们的菜单、工具栏、滚动条、对话框等等都是用 XUL 文档构建的。
XUL 具有广泛的跨平台支持——Macintosh 菜单看起来就是 Macintosh 的菜单,GNOME 按钮看起来也就是 GNOME 的按钮。为了达到这样的目的,XUL 紧密依赖于当前平台的固有控件。这样的策略类似于 IBM 支持的 Eclipse 开发工具。不过这种相似性也是有限的,因为 Eclipse 最终发布的 GUI 控件是 Java 类,而 Mozilla 发布的控件是 XML 的 XUL 方言中的标签。
XUL 存在的理由何在?多半是因为 HTML 适合显示超文本文档,但是却不适合显示 GUI。传统的基于 Web 的应用程序花费了无穷无尽的力量,试图强行让 HTML 具有传统表单/菜单形式的应用程序的外观。可是 HTML 当初根本就没有打算达到那样的目的。
向 HTML 中增加表单元素(即 FORM)无非就是创建了一种新的方法,以仿照古老的 3270 终端风格实现瘦客户机块模式(block-mode)应用程序。HTML 与 3270 一样,也提供了批处理方式的表单提交机制。基于字符模式的应用程序最终发展成十分高效的用户导航系统,但是当 GUI 应用程序出现的时候,这一切就都消失了。随后,GUI 应用程序也用鼠标和控件反馈的方式,实现了自己的界面导航结构。
当 HTML 表单登上历史舞台的时候,它们模仿了块模式终端的设计,但是却没有提供紧凑的导航机制,也没有用适当的 GUI 来代替它。在 HTML 之下,用户不得不自己猜测,页面上哪一个可视元素是用户可以控制的,哪一个又仅仅是装饰。因此对于 GUI 驱动的应用程序而言,HTML并不是一个很好的起点。这也正是为什么 Java applet 刚刚出现时市场上会出现一片热烈的响应,因为 Java applet 是实现真正 GUI 的一个机会。
现在 XUL 到来了。XUL 沿袭了 HTML 的极瘦客户机模式,但稍微让它变胖了一些。除了任何极瘦客户机都会提供的几种最平常的表单元素之外,XUL 还像复杂些的客户机软件一样,提供了完整的控件组。
在过去,这样的客户机软件可能是编写成 Java 应用程序,可能是用 Tcl/Tk 或 Visual Basic 编写的。现在,更胖的客户机可以实现为一个或者多个 XUL 文档,并且可以通过 Web 传递(或者仅仅进行本地处理)。应用程序的表现形式一开始是一个文档,而不再是一组对象。一个运行着的 Mozilla 平台读取那个文档,然后显示指定的 GUI,供用户使用。
这样,XUL 就将 HTML 轻量级的优势与传统 GUI 结构化的可用性结合起来了。