windows原生开发之界面疑云

 

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