要直接从Git编译，参考这个文档（居然有中文版本）。从网上下的zip包一大堆问题。然后我在linux和osx下都测试过，居然在osx下容易很多，而在linux下要一大堆依赖。

• 运行例子

tutorial放在qtquick1目录下，例子还算丰富，文档在这里。运行QML文件需要qtbase/bin/QMLViewer.app。一个QML文件描述了界面显示和事件触发，所以跟HTML很像，但描述语法不类似，我猜只有javascript是一样的。

Hello world。可以看出支持Lion的全屏模式，也支持中文。

疑问：1）有HTML的一套，C++的位置在哪里？2）还有CSS么？3）qtwebkit在这里面扮演何种角色？4）Javascript性能如何？真的是第一公民还是如同Gnome Shell只是一个UI的扩展？

一个静态的本地应用有什么用呢？有人也有这种疑惑：没有服务器段那如何和数据库打交道呢？如果还是要调用Rails，那表明这个框架只能算上半个。

所以把这东西当作一个C-S的框架比如Swing来看就容易明白了。或者更直接点：它就是为手机上的移动web应用准备的，这个应用可以是http的web应用，也可以是本地的js+css应用。

作为一个C-S框架，比web应用要更关注界面中组件之间的交互，事件绑定和数据绑定是要优先考虑的，而这也是SproutCore的强处。

如果用它通过REST直接连CouchDB之类的文档数据库，倒是一个好的组合。

另外由于HTML5已经足够强大，比如图形和拖放，所以完全可以用javascript来写些“本地”应用。你可能说Swing和Gtk之流已经很成熟了呀？但答案是：HTML5是标准。

所以我关心的一点是SproutCore的模版语言仿佛走上了java JSTL的老路子：

{{#collection SC.TemplateCollectionView contentBinding="Todos.todoListController"}}}
   {{view Todos.MarkDoneView}}
{{/collection}}

又是XML，极端难看啊。如果页面要微调，肿么半呢？

找了下，webkit的代码Source\WebCore\platform\gtk\RenderThemeGtk3.cpp是用来创建Gnome 3外观风格的控件，比如方法paintToggle就是对应单选框。我把里面的代码抽取出来，做了个小例子。费了老大劲，因为压根不知道如何得到context和cairo_t这些上下文信息（或者称为状态机，Functional Language反感的就是这个）。GTK的getting started在这里。

/**
  this code show how to render a button with gtk 3
  Some code copy from webkit/Source/WebCore/platform/gtk
*/

#include <gtk/gtk.h>
static gboolean
draw_cb (GtkWidget *widget, cairo_t *cr){
  GtkStyleContext *context;
  context = gtk_widget_get_style_context (widget);
  gtk_style_context_save(context);
  gtk_style_context_add_class(context,GTK_STYLE_CLASS_CHECK );
  gtk_style_context_set_state(context, GTK_STATE_FLAG_ACTIVE);

  int i;
  for(i = 0; i < 20; i++){
    gtk_render_check(context, cr, 10*(i+1), 10*(i+1), 10, 10);
  }
  gtk_style_context_restore(context);
}

int
main (int   argc, char *argv[]){
  GtkWidget *window;
  GtkWidget *ebox;

  gtk_init (&argc, &argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  ebox = gtk_event_box_new ();
  gtk_event_box_set_visible_window (GTK_EVENT_BOX (ebox), TRUE);
  gtk_container_add (GTK_CONTAINER (window), ebox);
  g_signal_connect_after (ebox, "draw", G_CALLBACK (draw_cb), NULL);
  g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit), NULL);

  gtk_widget_show_all (window);

  gtk_main ();

  return 0;
}

上面的截图中可以看到checkbox有native的looking（本人非Nike控），不同的是这些控件只是画上去的（没有JButton这种类的层次结构），没有event binding，也就是MVC只有MV。C的一块可能就由浏览器接过来来统一管理，那得遵循HTML Dom Event Model的规范。

这里不考虑CSS的外观。Gnome 3也是用CSS来控制外观，不知道是不是借鉴webkit。Windows的theme我还没有找到在哪里。

从webkit的代码看其已经支持Gtk+-3.0的back-end，不过Chrome还没有推出相应版本，据说是因为他跟Gtk+-2.0绑的太紧，跟Ubuntu走的太近（Ubuntu没有支持gnome 3）。唉，才几年又轻又快的东东就成了个史前巨无霸。

这是macruby的一个Gem，用来快速开发mac GUI应用。

2. 安装

首先安装macruby，我装的是0.11版本。然后运行sudo macgem install hotcocoa，这个package默认是没有安装的。

3. 运行命令hotcocoa w3，具体参考官方的指南。这里会产生一个和Rails类似的目录。

4.build。 直接编译的话会有问题：Undefined symbols for architecture i386，产生的代码都不能用，很无语。修改gem，在这里/Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/hotcocoa-0.5.1/lib/hotcocoa/application_builder.rb里面的 archs = RUBY_ARCH.include?('ppc') ? '-arch ppc' : '-arch x86_64'，把-arch i386去掉，现在的macruby都已经只有64bit的了。

5. 编译没问题的话就可以看到界面了。不过还没完，试试ruby的closure语法，不然妄走一趟。

def start
  application :name => "W3" do |app|
  app.delegate = self
  window :frame => [100, 100, 500, 500], :title => "W3" do |win|
    title = label(:text => "Hello from HotCocoa.", :layout => {:start => false})
    win << title
    name = text_field(:text => 'you name please')
    win << name
    win << button(:title => 'go') do |b|
       b.on_action do
          title.text = "hi," + name.stringValue
       end
    end
    win.will_close { exit }
end

可以看到，比起objective-c来直观多了，想想看objective-c是怎么操作array的，痛苦。而且这里用closure的方法比用Interface Builder来建立button的事件响应要直观、简单的多，不过就要自己手工组织layout了。能否用HTML中的event bind呢？比如这样dojo.connect(‘buttonId’, “onclick”, function(){…}

这里如果把name.stringValue写成name.text，运行时会有异常：in `’: undefined method `value’ for you name please:NSTextField (NoMethodError)，可以看到这里是直接访问cocoa的foundation的。macruby是基于cocoa的运行库的，比如NSString，但是当运行macrake时有个build的过程，时间有点长，难道macruby直接把ruby代码编译成二进制？打开打包好的app文件（这里为W3.app），

可以看到这里即有二进制，也有rb的源代码。可能这里的二进制文件是编译出来的，所以需要一段时间，二进制文件大概作为程序运行的入口，比如运行ruby加载rb文件，这个和有些exe结尾的可执行java程序相像。只是这样打包后coding-build-test的周期就长了，还是“刷新浏览器”的方式爽啊，当然有firebug这种工具就更爽了。

现在的大多数浏览器都有内置的同步工具，如Firefox wave，Chrome sync，这些强大的工具能同步cookie, form data, history，当然还有bookmark。乍一看，Delicious危已。但是功能越多，内聚性越大，想要独立于浏览器使用也就更难了。chrome同步后能在换台电脑能在firefox上面访问这些bookmark么？手机上呢？所以不要那么悲观，这个小角落对于某些-可能是少数-的人来说则是迫切需要的。

在功能上，delicious的firefox plug-in有个书签列表菜单：“Recently bookmark”，这是我个人使用很频繁的一个功能，很可惜，在其他bookmark工具中都没有。

Delicious的保存书签的弹出对话框做的也很好，你可方便的选择tag，然后回车保存。

一般说弹出对话框是比较恼人的，但是很奇怪，这里的对话框我很喜欢。1）我要保存资料，弹出的对话框是对我的要求的积极反馈；2）UI得体，更重要的是操作快捷。你只需要写入tag（带提示），然后按回车即可完成这项任务，很有成就感。

但是Delicious的plug-in开发速度很慢，这个也要怪现在浏览器的“版本大战”。作为一个独立的书签管理器，跨浏览器是战略要低，不能丢失。

书签这种应用从技术上来说应该不难，大概就是数据库表的添删改查，也出现了很多这种类型的应用，然而这这种“小角落”里面“做的对”的却很少，能像Delicious重视和专一的更少。

最大差别是IDE对语言的支持。java在eclipse下可以即使的显示语法错误，而objective-c还的build一把才能看到，这个太影响效率。xcode下一个版本改进了llvm后会引入这个feature。eclipse的refactory的功能也很强大，这个在xp开发模式下是必须的，而xcode也没有这个东西。所以objective-c其实拖累了iphone，真是成也萧何，败也萧何。

java在exception情况下会给出详细的调用stack，而xcode的错误信息很少，空指针情况下提示更如天书一样，不清楚这个是语言的局限还是ide的无能。其实界面还是用约束毕竟少的语言，比如弱类型或者动态语言来开发，C和Java过于严肃，很小的错误都会导致程序崩溃，也缺乏灵活性，因为界面是千变万化的，预想好的模型在实际开发中并不能适应所有情况。

UI方面，xcode还是坚持用多窗口的方式，苹果好像对这个情有独钟，一个程序分成多个小的窗口显示，这中非独占式的模式在大显示器下可能有更好的互操作性，因为你可以任意的调整窗口位置，也更节省空间：独占式的会将整个桌面填满。但是有时候则很不方便，比如它的log是单独的窗口显示，大多数情况下这个窗口被代码编辑器（这是个大窗口）挡住，而任务栏上又看不到这个log窗口的图标，这时候想查看log就很不方便。

当然，Interface builder这里就显示了apple的强处，界面非常cool，特别是事件定义时采用拖拉的方式很是直观。Cocoa的界面是独立定义的，然后跟objective-c的类进行绑定（事件绑定和属性绑定）。Swing则是在code中定义界面，纯编程式的，这部分有些IDE可以代劳。

所以最完美的组合是：java + mac的UI库，或者java用javascript代替。当然，已经存在的东西就是不完美的，所以存在的东西就是完美的…..

字体，我只感觉Chrome OS下的字体显然较一般的Linux字体有改进，很明显。

显然用的是Droid的字体，跟Anroid下面一样的字体，Google一个字体用了两个位置，便宜啊。还有这个页面是scale放大过的，可以看到图片放大后还是很平滑的，比较而言，Firefox for Linux就必须很烂了。还有Chrome OS下面的freetype不知是否比linux下有调优，因为freetype的作者已经被google招到麾下了。

本来这些都是些细微的调整问题，包括字体，包括图片的缩放，Google只是做了个收集整理的过程。

事在人为啊。