Firefox上的命令行: Ubiquity和Vimperator

前几天Firefox的新扩展Ubiquity掀起了一个热潮，都说是浏览器上人机交互的突破。

GUI的优势在于上手比较容易，而CLI的优势在于效率更高。其实Ubiquity并不是第一个这么干的，这之前的vimperator扩展也早通过模拟vi里面的ex命令的方式，实现了Firefox上的命令行，比如输入:tabopen google就能在新的标签页中打开http://www.google.com ，输入 :dialog addons就能显示"附加组件"对话框，也可以跟ubiquity一样扩充新的命令。但vimperator的主要目的在于模仿vi/vim的操作方式，"模"的问题决定了很多人不会使用，或者不愿使用。

(BTW: 最开始vimperator给我看Google Reader造成了很大的不便，因为快捷键都得先按一下Ctrl-V才行，烦得要命，好在不久发现可以用autocomand在某些网址上禁用vimperator的键拦截（在vimperator中输入:help autocommand可以找到相应说明，不过那个网址匹配表达式需要懂一点JavaScript才能搞懂怎么写）

不过Ubiquity似乎比普通CLI要跟强一些，还可以利用命令的输出与网页交互。以官网的视频里 的第一个例子来说，以前我们要跟朋友相约去哪里吃饭，发电子邮件时需要这样：先到某个网址查饭馆联系方式，然后将内容拷贝粘贴到邮件中，然后又 Google Maps上找相应的地图，然后点击拷贝图片和链接到邮件中，最后发送。但现在只需要在写邮件时，用map命令查出地图，点击一些"insert into page"就可以将地图直接放入邮件了，而饭馆的信息则可以通过yelp来查然后添加到邮件中（当然，这些命令对应的网站能否服务于我这里是另外一个不得 不考虑在内的问题）——这倒有点象vi中用!!调用外部命令并将其输出插入到当前文本中来。

GUI系统发展史

Graphical User Interface Timeline

里面介绍BeOS时 说: One of the most noted features of BeOS is its use of tabs instead of typical title bars. This perhaps saves a little bit of screen space and definitely gives the windowing system a unique appearance. 这正是我最近用xfwm4的beos风格替代metacity的原因 :-)

罗梅洛说: “我们的计划就是，让全世界游戏制作者都用上NeXTSTEP，让所有人都连到因特网上，让每个人都拥有一辆法拉利。” 到底NeXTSTEP是个怎样的东西，居然有这么大魅力? 这里也有NeXTSTEP的后继OPENSTEP的介绍(这种风格跟我们现在常见的风格差别太大了，都有点边缘化了，搞得GNUstep现在有点冷清)。

P.S: NeXTSTEP和OPENSTEP居然也是Apple弄出来的。

Links 2006-09-01

• GTK+的仿MacOS菜单栏(hack)
• wxWidgets的历史
• 不久前发现absurd这位网友的blog里面干货不少
• Linux下文件关联的实现原理
• SCIM输入法架构分析
• 开发代码产生器的经验
• 几则关于glibc的locale的笔记
• ......

Gimmie: 另一种桌面构想

在FootNotes上看见Gimmie这 个东西，对桌面提出了一个新的构想，不再是Windows那样的以程序/窗口为导向(我得说，GNOME/KDE是在学Windows，从开始菜单到窗口 列表，从桌面图标到TrayIcon)，而是以对象为导向: 有哪些文档，跟哪些人联系，有哪些电脑以及电脑上有哪些设备，能否根据某个标记(tag)找到某个对象(还有提议说跟beagle集成起来最好了)。

Gimmie目前只有一个雏形，还只是一个应用程序，还不能让众多程序告知它信息(比如直接从nautilus中打开的文档目前并不能被gimmie在Documents中列出)。目前它表现为一个面板(所以作者给了个副标题叫Panel Revisited)，如下。

但这里有个按这种方式组织桌面的一个mockup。

BTW: 那个Application栏的搜索功能我比较喜欢。你有没有在开始菜单中一个个查看以试图找到某个程序的痛苦经历，反正我有。

相关资料:

• 在GUADEC '06上的介绍胶片
• 演示(Flash): Attack of the Killer First-Class Desktop!
• 演示(AVI): tag的应用

UI杂谈: Tabbed Window Manager?

现在多标签(tab)似乎是越来越流行了，不知道是不是firefox惹的祸。不过在GNOME里面基本上见不到 M$ Windows那种MDI，要支持同时编辑多个文件都是用tab了。

不过诸位可曾想过用tab来管理窗口？如果你使用的是一个比较小的屏幕，并且常常觉得标题栏比较浪费空间，那么就可以试试这种风格: ion(图) fluxbox(图)



其优点在于:
1. 标题栏改成了tab，不需要占用原来那么多了空间
2. tab之间可以切换，M$那单纯的taskbar(GNOME上叫window list)也就不需要了
3. tab可以自由分组(操作方式一般是将一个tab拖到另一个tab上就可以了)，比taskbar上一个一个列出来要方便(M$那种按程序分组的方式我总觉得别扭，所以总是关掉的)

GUI程序的RAD和脚本化: 答案就是boa-constuctor?

刚发现有Boa-constuctor这样的好东西，这应该才是我一直想要的。看来我真要学习wx了?

User Comments

还不太稳定

铁石 | 12 二月, 2006 14:21

才开发到0.4版本，我以前试用过一下，常挂！但wx感觉还是挺不错的！

GUI程序的RAD和脚本化?

在我赖之混饭吃的那个项目上，这个大版本碰到一个比较棘手的问题， 那就是: 业务功能太多，虽然都不是很复杂，但总工作量却相当之多，加上项目组有2/3是新入职不到一年的同事，所以我们一直想把核心功能和业务功能分开来，后者用脚本来写。

但UI怎么办呢? 当然是要求有一些常用控件的，而且有事件响应能力，脚本中也要求能够操纵这些UI元素。基于俺个人多年的爱好，最好是能够同时编辑UI和事件处理代码(我认为没有这个功能就不能叫RAD:-)。

比较理想的是像Excel/Word那样用VBA(该项目是在Windows上用MFC开发的)，但似乎这方面的例子和文档都比较少，也拿不到VBA的试用版来评估一下。

从目前看到的一些东西来看，Windows下比较接近我们的需求的是Script Builder， 它是基于Delphi的，可以直接使用ActiveX或者Delphi编写的package，支持ActiveScript(也就是说可以使用 VBScript, JScript, Python和Perl了)和DelphiScript。如果我们自己的项目是用Delphi开发的，把这个集成进去应该是件很酷的事情。(这个东西实际 是基于以前见过的Dream Scripter，只是UI表现上做得更加接近了我们“用脚本写程序”的想法而已。)

再看一些其他的GUI toolkit吧:

• gtk有一个glade来编辑界面，然后我们可以在pygtk/python-glade或者gtk-perl/glade-perl来写响应代码，没法直接编辑界面代码(毕竟glade不是针对具体哪种语言的) P.S 刚刚在Planet Debian TW上看见yungyuc介绍一个新东东Gazpacho，说是"看起來是 Python+GTK 的 IDE"，我还高兴了一阵，拉下来试试却发现只是一个改为完全用python写的一个glade而已。当然，我们可以以此为基础再来扩展。
• wxWidgets有个wxGlade, 是模仿Glade的，不用多说。
• Qt有Qt-Designer来编辑UI, 但这个东西也是跟glade差不多;同时它还有个Qt Script for Application，使得可以通过Qt Script(基于JavaScript)来操纵UI，不知道这两个东西是否可以接合，不过这已经很不错了。
• SpecTcl是一个tk的界面设计器，不过它可以直接生成脚本(tcl甚至perl, python, ruby)
• Java方面我用过JBuilder, 对于Borland的这种方式，用最近最红火的郭德纲的话说：“ 这个杭子，我做兴！”，简直" 要了亲命了"。只是因为java的烦琐，一个用JBuilder编写的略微复杂的界面，其创建UI部分的代码，基本上是不可手工维护的。至于Eclipse上UI设计器，还没玩过，不瞎说了。

说了这么些，有朋友会问，到底你们用的哪种？呵呵，记住我们的程序是用MFC写的，也没有买Qt这样的界面套件。最后我们用了用友华表的 Cell控件做模板来模拟UI，上面也可以放些按钮、下拉框什么的，虽然显得很不专业，但总算能对付过去。

想 想也知道为什么这种东西没有基于MFC的: 要在脚本中操纵UI控件(当然是说比较自然的方式，比如MainForm.Statubar1.SimpleText = "hello, world", 不是我见一些高手在tcl里面用c代码封装SendMessage来操纵的那种)，这显然要求界面库有良好的RTTI，以便宿主程序能够很方便地将界面控 件对象加到脚本解释器当中去，否则脚本中怎么操纵它们。MFC有这些个嘛? ──除非完全自己手工来折腾。

补充:

1. 忘了gambas了，这个接近于Visual Basic，UI是用Qt写的。

2. mozilla的XUL应该是一个很不错的选择，而且传言很快将加入python支持，只是比较耗内存(似乎也没界面编辑器)。

SmoothGNOME for Windows XP

呵呵。

User Comments

世界變了

semson | 30 一月, 2006 15:15

向來只有人在gnome上套用xp them, 現在居然有人 "亦" 向行事

and clearlooks

bamanzi | 30 四月, 2006 21:06

http://www.deviantart.com/view/17870413/ http://www.deviantart.com/deviation/18777943/

闲话UI: 对话框不应该可调整大小?

今日在公司阅读其他人给出的一份界面可用性“规范”，里面看见一条“对话框不应可调整大小”，不仅哑然失笑：这是那门子的规矩。

Windows下的这些程序喜欢将控件固定放在第(x,y)象素，所以调整窗口大小的时候，移动窗口上控件的位置就是一件相当麻烦的事情了，因为要自己写代码来计算各个控件的相对位置，决定是固定大小、随着某边延长还是固定距离某边多宽。

我最受不了MFC的就是这个。

闲话UI: 选择目录对话框

很多时候我们都会要求让用户选择一个文件夹。在很多论坛上都会有朋友问到这个问题：怎么能够显示如下一个对话框?

这用ShBrowserForFolder这个Windows API可以实现。
WINSHELLAPI LPITEMIDLIST WINAPI SHBrowseForFolder(
LPBROWSEINFO lpbi
);

在Delphi中有下面这个函数可以使用:
function SelectDirectory(const Caption: string; const Root: WideString; out Directory: string): Boolean; overload; (1)

但我更喜欢用这个(在一些简单的场合):
function SelectDirectory(var Directory: string; Options: TSelectDirOpts; HelpCtx: Longint): Boolean; overload; (2)

但很多朋友不愿意，认为后面这个太难看。但在我看来，第一个对话框在可用性上是存在很大问题的:
* 不能设置(并展开到)缺省的选择
* 不能手工输入，这使得要进入一个层次深一点的目录非常麻烦
* 不能新建目录

其 实就ShBrowserForFolder这个API而言，第一个问题是很容易解决的，不过M$提供的是一种挺麻烦的方式: 你必须得编写回调函数(BrowseCallbackProc)，在BFFM_INITIALIZED消息里面发送BFFM_SETSELECTION消 息。(我觉得Delphi在提供SelectDirectory(1)这个函数时就应该包装这个功能。)

对于第二个问题, 如果你的shell32.dll版本大于或等于4.71, 就可以有个手工输入路径的编辑框了, 只要在flags中包含BIF_EDITBOX;

对 于第三个问题, 如果你的shell32.dll版本大于或等于5.0, 就可以有个"新建文件夹"按钮了, 只要在flags中包含BIF_NEWDIALOGSTYLE (而且这个版本有其他一些特性: 对话框大小可调, 目录可拖动, 目录有context menu(这可以带来其他一些功能)。

BTW:
1. lazarus中有TSelectDirectoryDialog控件，功能上等于Delphi的SelectDirectory(1)函数加上设置缺省目录功能。
2. DFS套件(Torry.Net上的信息)里面有一个dfsBrowseDirectoryDlg控件，支持shell32 5.0的NewDialogStyle，对这个功能包装得比较完整(其实上面的第三个图用得就是这个控件)，要添加新版本的特性(比如6.0的BIF_NOTRANSLATETARGETS等)也很容易。

闲话UI: 最小化...到任务栏?

对，我是个linux的fans。对于gnome/kde，我有一个很大的不满: 为什么要去学Windows的任务栏风格？

我认为比较好的方式是什么呢? 是WindowMaker的"最小化为图标"。

在最小化为图标的方式下，你可以将图标自行组织，也不局限于一行。但在M$的风格里面，你被限定在这一排上了。而且在XP下，你还可以得到两个更“高级”的选项: 一个是变成几行，你可以上下来回切换，总会让你有点事情做；另外一个特性就是“分组”...

当 然，缩小为图标的时候，其他窗口最大化可能会覆盖这个窗口，这是个问题。但这个问题至少在WindowMaker上可以很容易地解决：在WPrefs里面 Window Handling Options(第二个图标)将When maximizing...do not cover icons选上就可以了。

最开始玩Windows 3.1的时候，最小化都是缩为一个图标的。后来知道Windows早期很多东西都是从X Window System上学的，OpenLook和CDE也都是缩小为一个图标。然后玩WindowMaker，也是这样。可惜现在GNOME和KDE也都学M$的 风格(好在还有一个Roll Up/Down，聊胜于无吧)......

P.S 前几天在一个论坛上看见一个M$ Windows的扩展: Desktop Mate，可以让你的窗口最小化为一个浮动图标:

Usage: right click on

minimizes window to floating icon:

vim-cream的tear-off menu

vim的菜单是支持tear-off的(gtk, motif 1.2或者win32版本), 但装了cream(debian package)之后，菜单就不再能够拆下来了。

vim的文档里面说可以用":tearoff 菜单名"这个命令来手工将一个菜单拆下来。

注意: 1. 对于已经翻译过的菜单，直接使用翻译过的名字，比如简体中文环境可以用":tearoff 编辑(E)"；

2. vim是采用'.'来分隔多级菜单的，比如用":tearoff 设置(S).色彩主题(C)"就可以拆下cream的color scheme菜单，然后我们就可以一个个地试验那个颜色比较养眼了。

当然，如果你想主菜单创建的时候就有那个用于拆卸的分隔条，也是可以办到的: set guioptions+=t，但我看见cream/cream- settings.vim里面特意关闭了这个选项，不知道是不是有什么特殊的原因。

链接:

Tear-off menu 有什么不好
vim -cream的菜单国际化(i18n)支持

Tear-off menu有什么不好?

半年前写过一篇tear-off menu，里面提到gnome2缺省没有打开这个功能，但可以通过一个gconf设置项打开。

但这并不适用与“开始”菜单，因为上述设置只影响gnome_menu_new()创建的菜单(由libgnomeui里面提供)，而开始菜单gnome-panel是直接用gtk_menu_new()创建的。

对于这个功能的缺失我一直有点耿耿于怀。 今天下载源代码看了看，发现要加这个并不难，效果图见右，尤其是Debian菜单现在用起来方便多了。

但我不明白的是，当初为什么要删除这个功能?

--- gnome-panel/menu.c.orig     2005-06-07 03:08:56.000000000 +0800
+++ gnome-panel/menu.c  2005-11-23 00:07:22.000000000 +0800
@@ -257,6 +257,7 @@ GtkWidget *
panel_create_menu (void)
{
    GtkWidget       *retval;
+       GtkWidget       *tearoff; 
    static gboolean  registered_icon_theme_changer = FALSE;

    if (!registered_icon_theme_changer) {
@@ -267,7 +268,11 @@ panel_create_menu (void)
    }

    retval = gtk_menu_new ();

+        tearoff = gtk_tearoff_menu_item_new();
+        gtk_widget_show(tearoff);
+        gtk_menu_prepend(retval, tearoff);
+
    panel_gconf_notify_add_while_alive ("/desktop/gnome/interface/menus_have_icons",
                                        (GConfClientNotifyFunc) menus_have_icons_changed,
                                        G_OBJECT (retval));

玩玩GNUstep

感觉Gnome做得越来越象Windows, 时间长了有些烦它；而一直又觉得NextStep风格的WindowMaker不错，于是开始玩GNUstep。费劲编译了ProjectCenter, GSCommander等应用程序，但结果发现自己不怎么习惯它们的操作风格，观感(look & fee)也似乎有些单调。估计我真是受M$的荼毒太深了。叶公好龙？

不过这次在GNOME菜单里面发现了有个“嵌入式登录”，居然可以在桌面上再开一个X server，从GDM里面再登录一个会话，在这里玩玩WindowMaker+GNUstep也不错。(这项功能要拜Xnest所赐)

UI杂谈: Tear-off Menu

在公司论坛上前两天一堆人在捧scite，忍不住弄下来试了一下。在cygwin下编译了gtk1和gtk2的版本(在这里放 了一份gtk2的版本)，发现除了Edit->Copy As RTF这个功能和option菜单下的项目布局(windows版本里没有Edit Properties这个子菜单，造成options菜单老长)这两点不同之外，Windows版本还缺少一个tear-off menu的功能。



个人认为tear-off menu是可用性(usabilities)上比较重要的一个小功能(FYI: [Apple], [HP], [usablitiyfirst), 因为对于常用的一个菜单可以更方便快捷地点击其项目，对于一个三级菜单更是如此。我甚至猜测WindowMaker成为最受欢迎的WM ，GNUstep成为一些Hacker的梦想环境，这个方便的小功能也有贡献。

从控件集这个层次上看，gtk是有这个特性的(vim是常见的例子，而且它的windows版本也有这个特性——虽然不是用gtk作界面; 另外这里有个gnumeric的贴图), Qt也有(不过我找不到一个应用程序的例子，只有示例), 而Motif(DEC, HP), GNUstep(看WindowMaker就知道样子了), OpenLook(桌面全图)无一不有。

可惜后来GUI程序大都跟Windows学，不用这个功能或者丢掉了这个功能。比如GNOME, 这个特性在GNOME-1.x的Start Menu上还能见到，但到了GNOME-2.x就缺省关闭了。如果你想打开它，需要自己在gconf-editor里面找找 (/desktop/gnome/interface/menus_have_tearoff 示意图) , 或者试试gTweakUI这个小工具 (BTW: 关于GNOME是否应该自己为这些设置提供界面，而gTweakUI提供这个是否又违反了GNOME HIG这个问题，FootNotes上展开过一段辩论，不妨一看)。

GtkList/GtkListView的查找快捷键

一直以来，对于Gtk程序中的列表(GtkList, GtkCList或者GtkListView)，总是不能通过按首字母跳转到相应项目上去，很是不爽。今天无意中敲到了Ctrl+F，发现居然有个小搜索框。

记得当初gtk-2.4要添加GtkFileChooser时，FootNotes上 对于界面原型中"用Ctrl-L打开一个路径输入框"这点争论了半天(但我找不到具体的URL了，也许是这个)。反对者的意见是这样不直观，不看文档的话谁会知道这个 快捷键呢，用户要跳转到某个目录只能一层一层地点; 支持者的意见是这样界面比较简洁，“我们为什么要做得象Windows一样呢?" 对于这个问题，我的意见是反对不显示出来。

回到刚才说的Ctrl+F，好在这个搜索框是直接现在在窗口上，不是一个模态的，还算好用(Firefox后来也改成了这样，而不是原来的Windows风格的对话框。这个搜索框的模态问题其实Jef Raskin在The Humane Interface里特别讲到过)。

P.S. 我将键盘上所有字母键和Ctrl的组合都按了一遍，想看看还有没有别的什么(答案是没有)。

又: 当初别人说KDE比GNOME好(至少是好用)，我还跟他们争论一番，最近似乎没有太多底气了，尤其是放弃维护Cygwin GNOME 2.x以及前两天Slackware宣布移除GNOME之后。

expocity = metacity + expose

看见阿当的blogExpose for Linux，想起原来移植Cygwin GNOME 2.x的时候接触过一个叫做expocity的wm, 就是对metacity做了一点修改，添加了类似Expose的功能。

我记得当初我还编译了cygwin的版本，只是cygwin在windows上，Alt+Tab之类的用不了(当时忙得一塌糊涂，也懒得来改)。

但作者对这个东西似乎只是偶一为之，就那么一个版本，并没有跟随metacity更新。另外看一些评论说是速度上面

相关的链接:
FootNotes上的讨论
一段中文介绍(by Yuren)