如何用 C++ 从零编写 GUI?
对一般人来说,不要奢望能做出大GUI库,写一个小一点的,满足自己的需求,针对某类应用就好了。
我曾经遇到一个需求,需要一个小型的GUI库来写个安装程序。
安装程序是比较特别的,对于互联网下载安装的软件,要满足以下要求:
1. 不能带DLL,必须是静态链接,对系统的依赖越小约好。
2. 可执行代码必须足够小,一般来说要500KB左右最好。
3. 有比较好看的图形效果,比如安装过程的过场动画,窗口要有个半透明阴影光圈什么的。
用Qt写显然不合适,虽然我在知乎多次说过Qt库其实不大,但是对于写安装程序还是真的有点大了,Qt的静态链接出的Exe有2MB左右。
用MFC也不合适,MFC静态链接出来有400KB左右,算上安装程序自身的代码和资源肯定突破500KB了。
用VC++ 6.0的MFC去写,可以小很多,但是用这种古董不符合我的品味。
用WTL写,这个肯定很小,只创建一个窗口的程序静态链接只有50KB左右,但是什么功能都没有啊,只能创建使用基础的标准悾件,做个透明窗口都要自己再用其他API实现。
还是自己写一个吧,小一点实用一点,就用来做安装程序好了,不追求有多么高大上的能力。
跨平台就不追求了,只解决Windows问题就好了。
实现GUI库,有几个基本的子系统:
1. 窗口管理系统,这个代码就是封装Win API,但是这个工作很无聊,又很麻烦,我索性用WTL实现了,把自己的窗口类去聚合WTL的 CWindow,拿WTL做后端帮我创建管理窗口,对外是看不到WTL的,我没有用派生是因为不想让WTL污染我的接口设计。
我用私有类的方法,把WTL封装起来了,外面看不到
//伪代码
class RWindow : public RObject
{
private:
RWindowPrivate *d;
}
class RWindowPrivate
{
public:
CWindow m_wnd;
}
2. 事件系统,WTL的消息映射宏太丑了,我喜欢Qt的signal/slot,但是实现一个Qt那样的signal/slot可不容易,相当于发明一种C++扩展语法,还要自己实现一个MOC这种编译预处理器,工作量太大了。用Boost::signal 也太笨重了,boost会引入一个很大的依赖库,我还希望这个GUI库可以用默认的VC++就能编译呢,不想依赖太多其他库,而且boost的function会带来编译困难。
我选择了用一个轻量级的sigslot库,http://sigslot.sourceforge.net/
基于C++ template实现的,功能简单,实现也很简单,只有一个头文件,很符合我的要求,本来就不需要那么复杂的功能。
class RWindow : public RObject
{
sigslot::signal0<> Clicked
}
class MyApp
{
void on_clicked()
{
}
void init()
{
m_win.Clicked.connect(this, &MyApp::on_clicked);
}
RWindow m_win;
}
3. 图形系统
既然是GUI库,总不能还用GDI函数往hDC上绘制吧,好歹要弄个FrameBuffer,支持RGBA,渲染好了可以通过UpdateLayeredWindow更新到窗口上,以实现半透明异形窗口图形效果,比如实现个阴影边缘什么的。
自己写一个还是很麻烦的,光基本的点线圆绘制,基本的Alpha混合就要写上万行,更别提文字输出了。用第三方库的话,2D图形库就没有小的,光图形库就突破500KB的限制了,用Direct2D是不是有点小题大做了?还是用GDI+吧,虽然这个函数库不太受待见,但好歹是标准库,所有Windows都内置,而且我要求的基本图形功能都是有的。
自己写个 RPainter 包装GDI+的函数,顺便把 PNG JPG的编解码也解决了。
4. 布局系统
GUI库总不能让用户自己一个一个创建控件然后用绝对坐标摆放吧。基本的UI描述文件,Layout支持还是要有的。
但是我没有用XML,而是用了JSON,这两种格式描述能力是差不多了,仅是我个人偏好JSON,另外JSON库比较小,我用的是这个
http://sourceforge.net/projects/mjson/
根据JSON的描述来构建窗口控件的对象树。
我没有去实现复杂的布局,只实现了Anchor Layout,基本可以保证够用了。
给每个控件设定好object name,在C++里提供
template<typename T>
T *findObject(const RString &name)
5. 基本数据类型和容器类型
身为一个Qt粉当然要自己实现一套string类和泛型容器,向Qt致敬啦。
我没觉得自己有能力重写一遍STL,就是用系统的STL做后端,聚合STL的类,实现COW(copy-on-write),实现统一内存池。后来我把vc++的STL换成了 eastl
paulhodge/EASTL · GitHub
这个STL的实现非常好,解决了代码膨胀问题,编译出来的代码比用VC STL小得多。
RString是我自己写的,但是很多代码是照抄QString的。
但是实现string和数据容器不是GUI库必须做的,只是我个人偏好。
6 一些杂项 utility:
基本算法,MD5 SHA1 ZIP 7Z
网络支持,TCP UDP HTTP,没搞太复杂网络模型就是简单的select,HTTP是封装的WinHTTP。
IO支持,RFile RStream
7. 至于基本控件,早期只提供了RButton RLabel RTextEdit,其他的按需求用到哪个就实现哪个。
好了,差不多了吧,有这些做个安装程序基本算够了。
这个GUI库写大程序还是不行,格局太小,只能做小玩意儿,而且GUI库要有配套的工具链,这个很麻烦工作量又大,所以开发大工程还是推荐用Qt。
这个库早期的基础版本写下来也就两万行左右代码,基本只有自己用,想到如果要给别人用的话还要写文档,脑袋瞬间大了一圈圈。
后来有个同事把Lua集成进去了,做了脚本绑定,支持拿Lua脚本写程序,有点QML的感觉了,不过没有在真正的产品里用到。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。
王斌,数学爱好者,喜欢平面设计、户外运动
大概2009年的时候,我就沉醉在编写一款能跨时代的GUI上,从哪时候开始,我开始大量研究国内外所有开源非开源的GUI。
最开始的时候,每个写GUI的人都会经历那么几个阶段(windows下),
使用MFC,windows控件 ->发现windows控件不足,开始改装->发现改的多了,重复造轮子,开始思考从头完全自己实现控件->GUI的雏形->总结各种gui,写出自己的DirectUI->发现光是DirectUI还不够满足日益增长的界面需求,开始思考更合理的设计理念
所以你会发现,要从头实现一款自己的界面库,你需要了解界面库是如何运作的,这就牵扯到消息机制、绘图机制,这算界面库的最底层。在这层其实就有大量细节。比如在windows上,在用GDI的过程中,会发现GDI有各种各样极其不爽的地方,不支持alpha通道、抗锯齿效果不好、矢量功能太弱、图像处理功能太弱等等。所以在这一步,你需要一个好用的渲染框架。个人非常推荐skia,效果强大,速度极快。
有了渲染层,你要设计一套消息循环机制,你需要设计你的各个控件是如何接受消息,并做出反应。然后之上到了控件层,你需要设计你的控件体系。比如你要怎么分类你的控件,各种控件之间怎么协作。控件层之上,你又需要布局,就是说你需要有一种方式,让你的控件方便的放置在应该在的位置。
写完了这些,你会需要一个更方便的配置系统。这时候你会想到xml。这种结构化的语言对你来说很适合描述控件的各种信息。于是你又加入xml配置控件。
等等等等,写完这些,你基本上已经算半个界面专家了。但其实这一阶段,才是真正界面高手和界面熟手的分界点。到这一阶段,如果你对界面有更高的要求,你会发现用xml配置那些写好的控件,到底还是太麻烦。产品会给你提无数乱七八糟的需求,这种需求不是一个通用控件可以搞定的。这时候,你会有所思,想怎么才能更加方便的开发。当年,在这个阶段,我苦思了很久,最后直到在公司的某个公共目录,发现一份对迅雷界面库的分析,我才恍然大悟。原来你少了一种打破控件系统的勇气和创意。这个时候,你会发现,市面上许许多多的js库,其实就代表未来界面库的发展方向:不再使用传统的控件体系,而是用比控件更小粒度的原子控件---就比如迅雷界面库里的各种原子控件,又如js库里所使用的那些html元素。你会发现,只使用基本的几个元素,然后强化他们的拼装方式,能更方便快捷的实现产品提出的那些奇怪需求。
有了原子控件,你拼装出异性控件更加方便,你要实现控件各种动画也更加简洁。当你还是觉得有点不足,你会发现C++写这种异步逻辑的工作,太tm麻烦了。你会发现写网页的那群人永远写出炫酷界面的时间比你短。这时候你会再次醒悟,用脚本来实现这一切,用脚本去黏合这些逻辑。你会发现,用脚本去写动画,写消息响应,由于脚本天生自带闭包,写这种异步逻辑简直爽到爆…………
写完这些,我的库基本也被公司所用。小小得瑟一下,现在毒霸的加速球悬浮窗就是用这套逻辑写的,使用的库叫kdgui :-)
未完待续,有时间还想讲下kdgui的设计思路,当时可是把10多m的webkit,给完全解剖了,变成2m的kdgui:-)
Gdier,就是一死写界面的
从0开始学GUI编程,但是不用库,这件事本身是个伪命题。GUI编程是个复杂的知识体系,并不像大多数人想像中那么简单。所以如果题主真的想对Win32下(我猜的)的GUI编程有比较深刻的理解,建议还是从使用库开始。
先简单的说下,一个能用的界面程序员需要储备哪些知识:
1.各种系统内置控件的使用方法及特性
2.界面相关的消息机制。比如Windows下的消息循环,iOS中的RunLoop机制等
3.消息及事件派发机制
4.简单的绘图方法
优秀的界面程序员需要具备的进阶技能包括但不限于:
1.熟悉进程、线程调度机制,各种内核对象的应用
2.基本的图形学和图像处理技能,位图基础
3.图像编辑工具的使用,熟练使用PhotoShop、AI、mspaint等至少一种
4.有过多个平台的界面开发经验
回到题目,从0开始,当然先要成为能用的界面程序员。熟悉系统内置控件的最佳方式莫过于使用各种成熟framework来实现需求。至于是MFC还是WTL还是别的什么,倒不是什么大不了的事。
还是简单说下MFC和WTL(ATL)的区别。以前经常会看到有人说MFC如何如何渣,如何如何误导观众,其实这也是一个误解。
MFC
优点:易上手,对于界面订制不高的需求更容易做到快速实现
缺点:不够灵活,效率略低,运行库体积较大且版本太多
WTL(ATL)
优点:灵活,代码执行效率高(其实就是Win32 API的简单封装,当然快),运行库小,老版本甚至有个minicrt版本,一个简单的helloworld只有80k且不依赖任何运行库
缺点:封装的不够完全,很多功能需要自己实现;细节暴露太多,控制能力较差的程序员很容易把代码写的乱七八糟;WTL的支持者大多对范型这种东西有着阶段性盲目崇拜(顺便怀念一下当年那青葱的自己_(:зゝ∠)_)
OK,我的意图已经很明显了,如果完全没有基础,先看看MFC吧。如果能够做到熟练运用(如果悟性好,这个时间段可以非常非常短,所以不要着急),并且开始接触Win32原生API,再开始试着用下WTL,你顿时会发现世界美妙多了。
当你已经可以熟练使用框架进行界面开发之后,就可以开始探讨一些原理性质的东西了,这个时候可以试着读一下界面框架的源代码,然后你就能了解为什么同样是API封装,不同的框架使用起来会有那么多的区别。
举个例子,比如消息机制,以上两个框架的消息循环封装都写的非常漂亮,MFC的消息注册机制、WTL的thunk机制,都是非常值得一读的。
如果你已经走到这一步,恭喜你,你已经是个不错的界面程序员了,如果这个时候你仍然觉得自己非常喜欢写界面,你就有机会成为一个很优秀的界面程序员。那么,接下来会发生些什么呢?
1.你会嫌弃各种系统控件,什么都想自己画。你手上会有一套常用的自绘控件代码
2.你会开始崇拜DirectUI,对spy++抓不到的窗口怀有深深的敬意
3.你开始尝试自己写一个简单的界面库
4.你会后悔高中没学好解析几何,大学没学好线性代数
5.觉得写界面的程序员好不受重视啊,要不要也去做几个牛逼的功能?
于是那年我辞职出去创业了,为了公司的产品,我花了一个多星期写了bkwin的原型,基于WTL实现了一套基本的DirectUI体系,用XML描述界面布局,并实现了一个RelativeLayout和一个FrameLayout(以至于一年后当我看到AndroidSDK里描述界面的方法时,各种即视感,然后感慨自己道行尚浅)。后来又断断续续的增加了一些复杂控件实现,以及缓存优化、换肤支持等等。现在这个库的早期版本已经被公司开源,并且应用在有上亿用户量的产品中。(好久没得瑟了,一下没忍住 ´▽`)
越往后写,越发现自己知识的匮乏。当GDI+解码PNG的效率成为瓶颈的时候,我开始学习自己处理DIB;当C++代码处理DIB的效率已经不能再提升的时候,我开始看SSE的流水线指令...当我觉得我已经实在改不动的时候,有幸读到了WebKit的代码,被WebCore彻底击溃;然后我转行做了iOS程序员,于是三观又被毁了...
话题扯的有点远,其实我的根本意思还是想说,学无止境,既然打算从0开始,就认认真真打好基础,每向前多走一步,都要夯实,尝试去了解一些原理性的东西,不能浅尝辄止。不求甚解是成为一个优秀程序员的大忌讳。
最后推荐两本书:《Windows核心编程》、《Windows图形编程》,其中《Windows图形编程》早已绝版,不过网上可以买到影印版的,非常值得细读。希望题主以后有机会成为一个牛逼的界面程序员。