windows桌面开发,界面始终是最大的困惑。我们对前端工具的要求,其实只有窗体设计器、消息映射,过分点的话自适应屏幕、模型绑定。能够免于手工书写,其实这个问题并不复杂,但VS不实现、QT语法怪异、wtl同样,甚至第三方工具也无,wxWidgets也没有。
一、各种Html方案:
1、node-webkit:
有一个叫light-table的IDE项目复杂些,但看起来性能未必很好。不过,与webstorm之类java做的ide区别,性能上似乎也并没有多大的差距。目前来看,简单的通过调整初始url,可以直接将服务端应用转为客户端,这意味着一个能够全屏、置顶的浏览器。
需要带十几兆的包,这是比较讨厌的事情。
最初的疑问是:node-webkit使用require之类语法,在前端调用node模块。这种开发实际上比较麻烦的,好像在哪种IDE下都不好工作...那么,很简单的思维,既然node就在本地,那么使用本地资源为何不直接用node做服务端,而前端用REST调用?这样两个好处:1、前端是纯粹的前端项目,不同的是自带浏览器。后端为纯粹的node项目。两方面来看,各种编译器都支持。2、桌面和Web应用的代码将完全一致,不同的只是前者自带浏览器。
不过后来发现这个不是问题,node-webkit可以通过设置启动url直接的使用服务端项目。
类似node-webkit的,首先是CEF3,这个有一些应用,看起来历史更早,但据说其追随新版chrome比较麻烦,在node-webkit上也有一个分支名为CEF。网易的Hex是典型的中国式项目,只发布了简要的文档和二进制包,据说要开源但目前还没有,用hex做的有道词典,性能还不错,据说是分析过node-webkit,觉得不易商用才自行处理的,但作者重新造轮子、敝帚自珍的心态很明显,几乎是不能考虑的。
2、htmllayout
另一种选择,是个600k左右的dll,不开源。使用html处理布局,使用css的特性调用c++的功能,当然这不是html5,也不是完整的html解析,只是针对窗体布局的子集。
3、EA-Webkit:
是对Webkit而非chrome核心的剪裁,只有4M,但显然也是很冷的...其本身的目标应该是在桌面应用中显示网页,没有调用c++、访问本地资源的能力,那么就不能说是界面方案。当然,用wtl结合它,应该能做些简单的工作。
这是极少的例子中的一个:用duilib和eawebkit制作的浏览器,当然,用起来令人崩溃:
4、htmlview
mfc提供了基于ie核心的htmlview,这个,由于用户端机器的ie版本不同,也是颇为要命的事情,这会带来多大的工作量呢?国内颇多产品,近年将对ie的依赖转向chrome,不是没有原因的。
5、tc/tlk方案
看看git的官方windows界面就知,这是很古老的东西,丑陋的不成。界面使用所谓tlk文件,并没有太好的设计器,其主要的意图是跨平台,而非简化设计。
二、Direct ui方案
国内还存活的大约只有DuiLib,金山自己都不用自己的界面库,迅雷的各种复杂,其他都比较小众,而且这个话题,所谓的less window在2010年后似乎提及的也不多。
以duilib来说,窗体设计器非常简陋,许多bug,经常崩溃。更别提模型绑定、事件绑定了。我将其在vs2013下编译通过,仔细看了下代码并与其中一个开发者讨论过,设计比较紊乱,自愿者的组织也相当松散。
三、Mfc和wtl:
确实很麻烦。使用资源文件描述窗体,和使用xml、html没什么区别。有简陋的对话框设计器和ribbon设计器,消息映射可以使用类助手来略麻烦的处理。从这个角度来说,html方案并不占优。wtl则在进入vs2012之后,wtl helper没人维护,消息映射需要手工书写。如果界面简单,或可使用wtl,"小"是优势。
四、QT和wxwidgets
QT相对比较成熟,业界应用也广泛,但比较庞大,且写法怪异,需要类似mfc一般的深入了解所谓"框架"。wxwidgets实际上是类似mfc的做派,同样也比较大。两者都跨平台,事实上桌面应用,跨平台到mac、linux的需求少得可怜。
其他小众的界面库,甚至都没有深入了解的愿望。
实际上,当年Delphi的界面设计,今天在windows里,各种方案都做不到。我相信微软、谷歌这些公司肯定能做到的,但是,是否每个公司都本能的希望,win平台的原生开发需要门槛高企?