Weekly Twitters 2009 #1

Supernatual看的人很少么？ 电驴上这么多天没下载下来(S4EP1~S4EP4)。Desperate Housewives和Heroes就很快 30分钟 ago from TwitterFox
刚发现Firefox有个智能的功能: 连续激活两个tab并马上点击x之后，所有的tab都会出现x了 大约2小时 ago from TwitterFox
greasemonkey的namespace是啥昨用? 大约6小时 ago from web
继lotus notes之后，我决定thunderbird里的邮件也用tag的方式来管里，不用文件夹的方式存放了，虽然tb里跨目录搜邮件要比notes方便很多... 大约6小时 ago from web
新年第一天，去园博园逛了一圈。本来打算去东湖公园看菊花展的，那附近交通实在太差了，在路上憋了一个小时决定换地方... 7:39 PM Jan 1st from TwitterFox
有史以来最糟糕的500个密码(http://tinyurl.com/6sh3hp)居然有trustno1，哈哈，看来受《X档案》影响的人不少啊 5:53 PM Jan 1st from TwitterFox
Doctor Who的2008圣诞篇已经出来啦 http://www.verycd.com/topic... 11:16 PM Dec 29th, 2008 from TwitterFox
善用佳软在介绍chandler http://xbeta.info/chandler.htm 不少网友让别人推荐GTD软件，我这两天才弄明白，自己先不理清一个处理事务的原则，啥软件都不会好用... 10:08 PM Dec 29th, 2008 from TwitterFox
Vimperator 2.0 alpha 一瞥 http://tinyurl.com/8b6xrc 10:01 PM Dec 29th, 2008 from TwitterFox
下载到了Essential XUL Programming (pdf) http://tinyurl.com/7suyhd 9:56 PM Dec 29th, 2008 from web

用SciTE作为XUL的入门开发工具

开发XUL应该有这么几种情况:

1. 开始学习XUL，试验各种控件、XPCOM，不会涉及到chrome包。这种情况下只需要编辑XUL 和JavaScript，并能够预览就差不多了，能支持调试更好
2. 开发Firefox/Thunderbird扩展，这种情况下打包、部署、调试都是必须的，有用于创建扩展的向导更好
3. 开发独立的XULRunner应用程序，当然也需要跟2差不多的功能，但模式有些不同
4. 开发Remote XUL应用，这个比较少见，可以忽略

综合一下我们需要的功能:

• XUL编辑器。基本的需求是一个XML编辑器，能够支持语法高亮、基本的well-formed检查(或者结构树、代码折叠等方式可以辅助发现XML错误）。高级一点的需求是能够提供XUL widget的代码完成，能够支持DTD entity自动完成，能够支持内嵌JavaScript的编辑
• JavaScript编辑器。基本的需求也简单。高级的需求是能识别xpcom组件，从而显示里面的方法
• 部署
• XPCOM组件浏览器
• JavaScript Debugger
• DOM Inspector
• Chrome包结构浏览器，能够查看有哪些包能加载进来了。如果能识别overlay就更好了。(chrome list)
  

目前我还在第一个阶段，试验了一些工具，觉得都不爽，最终还是用SciTE

修正Launchy在Thunberbird中独立邮件窗口里菜单不能显示的问题

在Thunderbird中碰到一些链接，需要调用外部程序(firefox或者d4x等)打开，于是安装了Launchy。但Launchy菜单可以在主窗口的邮件视图中出现，而在独立的邮件视图（双击列表栏一个邮件时打开的），这个菜单就没有出现了。

估计Launchy没有在独立邮件窗口注册overlay，但要去查邮件窗口的chrome url，也挺麻烦的。
我看ThunderBrowse的菜单工作得挺好，于是看了一下它的chrome.manifest，里面就三行overlay:

overlay chrome://global/content/customizeToolbar.xul chrome://tbrowse/content/accessbrowser.xul
overlay chrome://messenger/content/messenger.xul chrome://tbrowse/content/accessbrowser.xul
overlay chrome://messenger/content/messageWindow.xul chrome://tbrowse/content/accessbrowser.xul

而Launchy是这样

overlay chrome://browser/content/browser.xul chrome://launchy/content/main.xul
overlay chrome://messenger/content/messenger.xul chrome://launchy/content/main.xul

看名字就知道独立的邮件视图是messageWindow.xul，于是在launchy的chrome.manifest添加如下一行就可以了

overlay chrome://messenger/content/messageWindow.xul chrome://launchy/content/main.xul

XUL: property与attribute有什么区别?

看XUL Elements的说明文档，会碰到Attributes列表和Properties列表，这两个有什么不同?

Attributes:

someValue = element.getAttribute("someAttribute");
element.setAttribute("someAttribute", someValue);

Properties:

someValue = element.someProperty;
element.someProperty = someValue;

前者是按DOM的思路的，而后者是将XUL Element抽象成对象了。但两者是等价的么？如果下两句话一块儿执行，会是怎样的结果?

textbox.value = "First value";
textbox.setAttribute("value", "Second value");

答案是: 界面会显示"First value"，但你用text.getAttribute("value")会取到"Second Value"(或者用DOM Inspector可以看到)。

所以这两个东西还是有点不一样。但你在.xul文件里面设置的attribute怎么能直接反映到界面中? 反正比较复杂。 详细的说明可以看这篇文章:
XUL Solutions: Attributes and properties: the essential difference

基本上是说在用代码操纵时最好用properties，但在XBL中就得注意了。

我还注意到其它一些小差别:
1. 有些attribute没有对应的property，反过来也是;
2. attribute和property可能存在一些大小写的差别，比如tabindex和tabIndex。一般而言attribute倾向于contextmenu或者wait-cursor这样的风格，而property倾向于contextMenu。但也不是绝对的(比如sortDirection这个attribute), XUL里面这个有点混乱;

Port some addons to XUL Explorer

I think the following addons might be of some use for XUL Explorer, thus made some quick-and-dirty patches to make them could work on it.

Chrome List: https://addons.mozilla.org/en-US/firefox/addon/4453
Extension developer's extension: http://ted.mielczarek.org/code/mozilla/extensiondev/
xpcomviewer: http://xpcomviewer.mozdev.org
cview (older xpcom viewer) http://hacksrus.com/~ginda/cview/
(but I'm based on the code on mozilla tree)

The patches and patched addons lie on:
http://bamanzi.inlsd.org/xul/xe-addons/

As an alternative to installing them in the extension manager, you can
also unpack each .xpi to xulexplorer/xulrunner/extensio

ns\.
Unpacking to xulexplorer/extensions won't work for XULRunner 1.8.

Not all features could work. Currently I just made sure they could be launched from the Tools menu.

Mozilla/XUL Links 2007-09-10

• CoScripter: 一个网页自动化工具(Firefox扩展)，由IBM的人折腾出来的，
• Penelope: 著名的老牌邮件客户端Eudora关闭之后，有人想将一些功能重新在Thunderbird上实现，并模拟Eudora的观感和操作方式。
• Open Komono: ActiveState公司决定将Komodo的一部分开放，成为Open Komodo项目。Planet Mozilla上不少人觉得这对XUL IDE是个不错的消息(链接1, 2)。至少，俺一直想把Komodo里面的编辑器(基于scintilla做的浏览器插件)移植到XUL Explorer上来用。
• XUL activities in France
  

Mozilla/XUL Links 2007-08-28

Google Search (xul version)

在侧边栏打开这个地址效果不错

IBM developerWorks : Blogs : Bring information and collaboration into the context of your daily business processes using composite applications

一篇blog，讲述在Lotus Notes 8 (现在是基于Eclipse的了)中如何嵌入XULRunner来显示一个XUL应用，从而形成Composite Application

XUL Explorer 0.7

近来试验了一些XUL IDE的半成品，这个东西的主要长处在于可以预览XUL，而且支持简单调试。新版本0.7相对0.4改动不大，主要是为一个XUL文件可以提供一个chrome环境了（但这个功能很有用，因为一般xul文件都不是独立的，给定一个chrome环境后overlay和dtd都可以正常加载进来了，这样预览才比较接近最后的效果)。如果完全要手工编写xul以及js，我觉得Spket还不错，里面还有Firefox 1.5和2.0的XPCOM接口列表。

XUL是如何传递事件源和参数的

代码这个东西就是这样，你一路看下来，挺好懂的，没啥稀奇，但一旦自己写起来，就觉得好多细节搞不清楚了。我在试验XUL的时候碰到一个典型的这样的问题：多个控件的onclick事件可以绑到同一个javascript函数，但它怎么识别是那个控件触发了这个事件呢？ 怎么传递点击的位置呢？如果传递多个参数的话，控件触发事件的代码要分开写么？

查了一下DOM Level 2 Event Model规范(mozilla.org上说明)，发现HTML/XUL里面是传递了一个event对象来解决这个问题，这个对象有很多属性，但不是每次这个对象里面所有属性都有所用：event.target表示触发事件的对象，event.clienX是点击事件中的点击位置，event.keyCode是按键事件中的键码。

做了个xulplanet的镜像chm

最近研究Mozilla XUL, 发现老是要到Mozilla Developer Center, Mozilla Wiki, XULPlanet这几个网站查阅文档，今天干脆用Teleport Pro拉了它们的镜像下来。考虑到小文件比较占空间，而且没有索引，于是想把它们进一步做成CHM。

首先搞定的是XULPlanet:
http://bamanzi.inlsd.org/xul/xulplanet.chm



写了一个小的Python脚本(html2hhk.py)，把所有的XUL Element属性/方法、XPCOM组件/接口都搜了出来转换为CHM的索引（其实这个脚本的功能是读出HTML的title和keywords meta tag作为关键字，改一改也可以输出devhelp的keyword列表)。

这个CHM文件还有些问题:
1. 目录还没有做，至少一些大的分类得列上去吧，这个东西好像没有什么简单方法；
2. 内容部分每页左边都有一个侧栏，供导航用的，这个东西在CHM里面没有作用，得用sed什么的批量处理一下。

Rich Internet Application? Rich Client?

最近在网上查资料，被Rich Client(富客户端)和Rich Internet Application两个概念搞得头晕。虽然名词都是“相”，但大家约定清楚交流起来容易一些:-)。仔细研究一番之后，得出结论如下:

• RIA在界面交互性上比简单的Web应用当然要强，界面表现能力也要丰富（这才所谓rich嘛）。但RIA强调“零安装”，界面和逻辑都是临时从服务器取得，已避免部署、升级方面的麻烦(从这个角度说，RIA更接近Thin Client)。但。大部分RIA技术都依托Web，在浏览器中实现(所以也常常被称为rich web application)，但可能需要安装一个运行库/解释器。目前的选择大致有Ajax, XForms, Flash(Apollo, Flex或者Laszlo)、SilverLight(WPF/E)，另外ActiveX和java applet好像也算。
• Eclipse整天嚷嚷的副客户端(Rich Client)，似乎跟以前说的胖客户端(fat client)并没有太大的不同，要求安装很大一堆东西。只是现在大家都更加注重用户体验、模块化和快速开发。目前的选择有Eclipse RCP, WPF(XAML), Mozilla XUL, JavaFX这些。这里出现的两个趋势是尽量简化界面的生成(比如用XML等结构化文件来描述界面)和采用脚本来编写逻辑（比如XAML, XUL, JavaFX等).

不过网上很多文章谈到rich client时，可能还是关注在“用户体验”的丰富性上。所以才会有“OpenLaszlo 是一种富客户机应用程序架构"、“Flash成web浏览器标准, 富客户端指日可待”这样一些说法。

其实Mozilla XUL完全满足两方面的要求，大家常用的Firefox, Thunderbird等可以类比为rich client, 而网站上直接提供XUL则就是RIA了。
例如: Mozilla Amazon Browser, 如果你把它安装为一个Firefox插件或者独立程序，它可能又算一个rich client了。
再例如htmlhelp.dotsrc.org提供的API浏览器, 左边是一个XUL编写的导航栏，比如Python, GTK+。

链接:

• wikipedia: Rich Internet Application
• IBM developerWorks: Rich Internet Application的技术选项
• Eclipse Rich Client Platform

XUL学习杂感

• 目前搞到三份教程: Rapid Application Development with Mozilla, Create Application with Mozilla, XUL Tutorial. 正在看的是中间一份;
• XPFE，GRE, XRE, XPToolkit和XULRunner是什么关系?
• 初学XUL时还是用mozilla做试验比较好，如果你写的XUL里面有错误，似乎Firefox会啥反应也没有， XULRunner亦然，但mozilla会帮你指出来。应该是某个选项控制这个;
• Mozilla是如何解决XUL里控件文本的本地化问题的？它直接使用了XML技术里面的DTD/entity，这很有些匪夷所思啊
• menupopup, popup, popupset有什么差别?
• Firefox里面的toolbar为什么没有grippy(就是原来netscape里面工具条左边的折叠条)?

Mozilla/XUL平台在哪些方面吸引我

前几天说，我想学习一下XUL了。为什么呢？

我赖以混饭吃的项目组的项目的业务层越来越复杂，用户们也不满于我们接纳和实现功能需求的速度，期望能够自己搞二次开发。为此我们在前一个版本中 全面加强了脚本扩展，以便能够方便外围业务的开发。但这只是解决了逻辑方面的问题，但缺少界面扩展能力，那怕只是提供几个选项的简单的对话框。

通过Firefox的使用，我看到了Mozilla作为一个开发平台的能力，而ThunderBird, Komodo等也说明了Mozilla不仅仅是个浏览器。所以我想学习一下XUL，如果明年能够推动迁移到这个上面来就比较有意思了，即使这个目标达不到我也期望能够从中学到很多思想。

那么，Mozilla/XUL具体在哪些方面吸引我?

• 脚本与系统完全融为一体，可以响应界面，可以创建XPCOM对象（有点遗憾的是，Python脚本支持的进展有点慢);
• 界面的快速开发功能（XUL），界面元素也相当丰富（对于我们的应用，目前还欠缺一个datagrid, 或者说可编辑的treelist)，我对于还要考虑对话框怎么调整大小、分隔条的行为这些问题感到厌烦;
• 可通过XPCOM扩展系统;
• overlay机制，可以通过扩展修改核心系统的行为（也包括界面，比如在一个已有窗口中插入一些元素）;
• 本身支持HTML的显示，这会给内容的展现带来很大的方便;
• 包，各个包之前是相互独立的，各有自己的名称空间，而overlay机制又允许包之间可以打交道;
• 完整而简单的多语言解决方案。多语言这个问题初看起来简单，但自己实现起来就觉得需要考虑好多东西，比如字符集问题，语言包的更新问题(程序修改过之后，如何识别哪些语句需要更新)，界面的翻译问题等等;
• 跨平台

不过目前也觉得有些不太好的地方:

• 体系有点太复杂了，掌握XML, XUL, JavaScript和CSS似乎是最基本的，还有XPCOM, XBL, RDF, DOM...，还有一些工具的用法，初学者太难于上手了;
• 界面缺少工具WYSWYG工具，别说Delphi那样的完整的RAD系统了，连glade, wxglade那样的工具都没有见到;
• 中文资料比较少，也就在limodou的学习笔记上看见过一些XUL Tutorial的翻译和学习心得;
• 似乎内存占用有点大(其实我倒觉得挺正常，但我们的用户太挑剔了 :-()

开始学习XUL

这两个月工作开始有些闲暇了，于是一直想早点东西学学，这两日终于确定下来主题了: 开始玩XUL。

• XUL: http://www.mozilla.org/projects/xul/
• Documents: (English, Chinese)
• XULRunner (原名XUL Runtime Environment)
• XUL Tutorial (中文翻译)
• Limodou的学习记录 - XUL部分

更新了一下dictionary tooltip插件的“爱词霸”补丁

先前我对dictionary tooltip插件提供了一个使其支持"金山爱词霸"网站的补丁。这两天发现"爱词霸"的网页有了点细节调整，于是更新了一下，并添加了一个选项:显示所有词典解释还是只显示一个。

为了方便，直接提供了xpi安装包: Dictionary-Tooltip_v0.9.1+iciba.xpi

Awesome firefox XUL example!

Searches amazon... you must see it to believe it!
也许以后的“客户端”都应该用XUL来做

P.S: Fun with Firefox Chrome URLs

User Comments

(no subject)

ZHOUQUAN | 22 七月, 2006 14:28

赞同！！！！！！！！！！！！！！！！！

Python and XUL

在Daily Python-URL上看见的:

Sidnei da Silva: Python and XUL: The Screenshot [«Mark Hammond just shown me a screenshot of Python and XUL. That's right, Python used as scripting language on our most beloved browser to create XUL interfaces.»]

比较完整的说明在这里。上面说估计在Mozilla 1.9上可以看到这个东西。

本来我对XUL还是有兴趣的(近来的工作也存在一个如何快速制作业务界面(数量多但大都比较简单)的问题)，只是一直懒得去学javascript了。