摘要: 这个操蛋的问题要从一年前说起，当初做无线点菜，PC端的接口是用C写的，提供的是lib/dll方式。有些客户惯于使用的是vc或delphi，这些都很方便，但是某些客户使用的是vb和pb，问题就来了。pb因为我并不熟悉，所以没有多管，vb一开始打算用的是dll，但是发现一触发事件就崩溃，在网上找了很久，发现问题出在事件触发是在thread中的，vb属于线程不安全的类型，所以一触发就崩溃，但是我又不能更换模型，后来写了一个ocx的版本，但是问题依旧
阅读全文
首发站点：http://www.heybrain.com
FLTK，如同其名字所表达的：The Fast Light Tool
Kit，一个轻量级的GUI开发库。但这轻量级并不代表功能的羸弱，相反，FLTK在具有基本的GUI功能之外，还拥有一些特殊的功能，比如跨平台、内置
OpenGL功能、速度更快、尺寸更小、协议宽松等。当然，缺点也是有的，比如对于复杂的界面构件支持不够，资源支持的不足等。但一个工具如果使用的好，
取其长而去其短，自然可以飞花摘叶皆可伤人;P
我选择FLTK
的过程还是比较曲折的，当初做ARM下的GUI开发，选择的GUI库是MiniGUI，一个国内开发的界面库。当时还支持类unix平台，对
Windows的支持尚在开发中。由于需要寻找一些问题的解答，所以经常在其论坛上搜索，从而知道了还有microwindow、nano、
qtembedded等嵌入型GUI开发库，但当时没有太过注意。后来又开始转向WINCE平台的开发，这一搁就是２年。再后来终于要做跨平台的开发，对
具有跨平台的GUI开发库开始注意起来。
一开始的选择是wxWidgets，但是研究了一段时间后发现不好解决的问题越来越多，终于
放弃。最头疼的就是C++类的事件传递，wxWidgets内部使用的是一个类似MFC的方法，所有传递事件的类全部要从一个根类继承，这样就导致创建的
类和wxWidgets绑定过甚，复用性大大降低，同时由于wxWidgets的目标不仅仅是GUI，造成其包含功能过多，其内部结构非常复杂，虽然是
OpenSource，但要若要修改其代码还是很困难的。综上所述，wxWidgets并不符合我的要求，从而被排除在外。
之后研究的QT，老牌的跨平台GUI开发库，工具很多，开发也很人性化，qtdesign很像Delphi的界面开发方式，代码带有强烈的linux风格，但是看看附带的库文件又实在让人有些泄气，尺寸大，发布麻烦。所以在试用了一段时间后还是放弃了。
在此期间，其实也看到过一些对FLTK的介绍，但大多数对其评价不高，也就没有注意。直到有一次偶然心血来潮，上http:
//www.fltk.org看了一下，发现FLTK
似乎正对我的胃口，这才开始对其进行了深入的研究。经过一段时间的实际开发，个人觉得，对于跨平台和代码简洁而言，FLTK是再适合不过了。
FLTK的底层只提供一套完整的画点、画线功能，另外附带了字体的显示功能，但FLTK对字体的支持还很粗糙，尤其对于非英文字符集而言，后面我会详细
说明。在基本的点、线功能基础上，FLTK完全自己实现了一套界面，比如Button、Label、Edit、Tab等，全部都是由基本的点线画出。看到
这，可能你会觉得这实在是属于自己造轮子，吃力不讨好。诚然，如果你只针对一种平台开发，这样的做法不能带来多少好处，还造成学习时间的拉长。但若要针对
多个平台开发，这样做的好处就很明显了。首先是移植容易，只要针对目标平台实现基本的点线功能就可以实现代码的移植，这可能是所有跨平台GUI库中最方便
最直接的方案，目前FTLK支持MacOS、Windows、Linux(x-window)等平台，针对WinCE（主要是unicode的问题）和
plam
的开发正在进行中。其次是保持了界面的一致性，虽然QT、GTK等开发库也具有这种功能，但是他们都需要一套基本库的支持，无法做到系统尺寸的优化，而对
于FLTK而言，这却恰恰是他的优点和长项。最后是代码层次清楚、结构简单，由于大部分的工作就是基于底层的点线功能进行自绘，所有很多代码都是简洁明
了，很少费话。
底层之上是一套以Fl_开头的类，代表了各种GUI构件，比如Fl_Window、Fl_Button、
Fl_Input等，使用起来很是容易。同时由于上面所说的，所有的界面构件都是画出来的，因此在熟悉了这种方式后，生成自己的构件也是很容易的，反正是
画界面嘛，既然别人能做到，你也能做到，实在不行可以查阅源代码进行学习。这些界面类的共同特点是轻量型、都拥有一个draw()，只要在draw()里
实现自己的绘画动作即可。
说到界面就不能不说其事件实现方式，对于FLTK而言，使用的是最直接的方法：while(1){}。这也
是很多人批评FLTK原始的一个原因。但仔细想想，其实这是最直接的办法，不管是哪种平台，最终的事件方案不外乎是死循环和中断，中断的确具有很多好处，
但只要while(1)能完成这部分的功能，那又有什么关系呢。每个界面类都有一个handle(int
event)，只要继承这个成员函数，就可以在其中处理自己的事务。是不是很简单？同时由于这样的事件方式，造成FLTK的刷新速度很快，事件反应迅速，
也算是个附带优点了。现在大多数的开发库都是采用OO方式的事件处理方式，但FLTK却采用了最原始的函数指针方式，也算是一个异类，这可能和FLTK的
unix背景有关，无论如何，这种方式还是需要一定的适应时间的，而且这种方式的优缺点也是属于各花入各眼了，不过我本人还是很喜欢这种方式的，谁叫我比
较原始呢#-_-
FLTK产生于NeXT环境，发展于X-window环境，所以对图形加速的支持必然是选择OpenGL。FLTK
使用Fl_Gl_Window这个类将OpenGL的基本功能囊括其中，只要在Fl_Gl_Window的draw()里glbegin/glend即
可，基本的设置工作FLTK全都做好了，对于我现在的系统要求简直是最适合不过了。
FLTK基于LGPL，对使用者的要求非常宽松：
Contrary to popular belief, it can be used in commercial software -
even Bill Gates could use
it! 所以开发者不需要担心其项目的隐形问题。但是如果对FLTK进行了卓有成效的修正最好还是能回馈给开发组，所谓我为人人，人人为我嘛。
说了一堆的好话，现在开始谈谈FLTK的缺点。首先一条就是对非英文字体特别是中文的支持比较差，甚至是非常差。在Windows平台下还好一点，因为
在
Windows平台下使用的是TextOut函数输出字符串，但是在X-Window环境下就完蛋了，无法正确显示中文，也不能调用输入法进行输入。从这
点来说，FLTK还是只适合一些封闭软件的开发，对于通用软件而言FLTK并非是一个好的选择。但只能在Windows平台下开发中文软件也不是个办法，
要解决中文的显示问题也不难，目前FTLK的稳定版是1.1.7，开发版是2.0，有人针对1.xx版本修改了一个unicode版本，可以很平滑的支持
汉字的显示，但很遗憾，我没有编译成功过，如果谁编译成功了可以给我来个信。2.0已经对非英文的支持进行了专门的开发，但目前还没有release，在
不久的将来应该可以完整的解决这个问题。目前，要么等待，要么就像我这样，用点阵字库瞒天过海。具体方法因为还不够成熟，就不公布了。
无论如何，FLTK的目标还是针对嵌入式和封闭软件的开发，所以复杂的界面并非其长项，如果想做出花哨复杂的界面，还是用其他GUI库比较好，FLTK并不适合。
综上所述，FLTK的优点和缺点都是非常的突出，如何取舍还是自己决定吧。
2006-04-16 22:02