HT for Web嵌入QtWebKit的客户端解决方案

HTML5已经足够强大，但很多应用还是需要独立桌面客户端的解决方案，毕竟能操作本地文件等功能还是很多工具类软件短期内无法完全采用云方案替代。

最近Adobe发布的http://brackets.io也是类似的应用，Brackets这样描述自己：An open source code editor for the web, written in JavaScript, HTML and CSS. 这样的描述在过去很难想象居然是编辑器的工具，如今采用WebKit嵌套各种壳的方案已让这类应用成为主流。

Adobe的Brackets采用的是自家的https://github.com/adobe/brackets-shell/套壳框架，不过brackets-shell仅为Brackets量身定做，并不建议一般应用使用：

Note: The brackets-shell is only maintained for use by the Brackets project. Although some people have definitely had success using it as an app shell for other projects, we don’t provide any official support for that and we haven’t done a ton of work to make the app shell easily reusable. Many people will likely find it easier to use a project like node-webkit, which is more generic by design.

一般应用采用https://github.com/rogerwang/node-webkit，HT for Web自然也能通过node-webkit打包成客户端应用程序，如下图所示：

最近遇到用户通过Qt将HT for Web嵌入QtWebKit的解决方案，但遇到了显示正常但无法鼠标操作的奇怪问题，经过一番折腾才发现HT居然把QtWebKit在桌面的环境，错误的识别为可Touch的移动终端环境，如何正确判断Touch和Mouse的交互环境是非常狗血的事情，可参考http://stackoverflow.com/questions/4817029/whats-the-best-way-to-detect-a-touch-screen-device-using-javascript/4819886#4819886 加上如今window8的即可touch又可mouse让问题更加复杂化。

还好HT预留了可配置的方案，通过在引入ht.js包之前设置htconfig = {Default: {isTouchable:false}};强制HT采用常规的mouse事件进行处理。因为HT内部简单采用”ontouchend” in document的方案来判断，一般情况下桌面环境该值为undefined，移动终端为null，而QtWebKit居然在桌面环境下也为null，结果HT采用了Touch的监听事件从而导致了无法操作的现象，通过htconfig的设置后一切就正常了！

http://player.youku.com/embed/XODI2MTAwNTA4

HTML5通过WebKit嵌入打包成本地应用已经不是新鲜事了，整个世界的各种客户端技术正在变得更加融合，无数种千奇百怪的客户端方案正在改变很多观点和架构，不久前的wwdc2014中的JavaScript for Automation我觉得是被严重忽略的亮点，整个mac osx系统和应用程序都可通过JavaScrpit进行调用，早期window得利于众多应用软件而普及，苹果在站稳了移动终端后，借助诸如JavaScript for Automation的动作吸引更多专业客户端开发者，也许会不知不觉在桌面领域翻盘。