嵌入式GUI FTK设计与实现-三项基本原则
李先静
GUI无疑是最复杂的基础软件之一，在我研究过的GUI中，像X Window、DirectFB、 GTK+和MicroWindows，它们都是非常复杂的软件系统。我写过不少关于它们内部实现的文章，但是我现在要非常惭愧的告诉你，这些GUI的实现 太复杂了，我其实没有完全搞明白过其中任何一个系统。分析一个GUI系统，对一个工作经验丰富的程序员来说尚且如此困难，对初学者的难度就可想而知了。不 过FTK则是希望成为人人可以读懂的GUI系统。如果你在阅读代码的过程遇到了难题，请不要犹豫，大胆的来和我们讨论吧，让我们一起想办法把它变得更加简 单。
为了提高FTK的可读性，我们采用了下列措施：
1.保持简单。
简单的东西才是容易理解的。从代码量 来讲，FTK的代码量只有GTK+的十分之一，总共代码在两万行以内，90%的文件的都是少于600行代码的，80%的模块对外的函数是少于10个的，单 个函数基本上都是少于50行代码的。从设计时，FTK也尽量选择简单的模型，比如只支持单进程单线程方式运行(其它线程可以通过idle来串行化对GUI 的访问)，从而避免引入进程间通信机制和并发带来的复杂度，这一点我们在后面有更详细的描述。
2.一致的代码风格。
代码 风格的一致性对代码可读性的帮助很大。FTK的文件名、函数名、变量名和类型名都遵循统一的命名风格，FTK中的命名风格和GTK+的命名风格基本上是一 致的。FTK所有代码的排版布局也保持高度一致，整体上的代码风格与《系统程序员成长计划》一书介绍的一致，如果你读过《系统程序员成长计划》，再看 FTK的代码就像见到熟人一样。
3.避免复杂的算法。
GUI和图形算法相对是比较复杂的。出人意料的是FTK几乎没有使 用任何复杂的算法，连画普通直线和圆弧的算法都没有，更不要说线性代数中那些矩阵变换了。FTK中尽量使用水平线和垂直线来绘制基本的图形，而用图像来实 现更复杂更美观的界面，这样就绕开了复杂的图形算法。不过，可以使用可选组件cairo来绘制复杂的矢量图和做些高级的图形变换。
4.设计高内聚的模块。
高内聚简单的说就是一个模块(或函数）只完成单一的功能，单一的功能从逻辑上更容易理解，代码量也更少。要保持简单，设计高内聚的模块是必要条件，把多个功能糅合在一起，自然不可能做得简单了。
5.编写内部实现文档。
隔行如隔山。对于对GUI一点概念都没有的初学者来说，再简单的GUI也是难读的。为了降低初学者阅读FTK的门槛，我们决定写《嵌入式GUI FTK设计与实现》系列文章了，也希望大家都参与进来讨论和完善。
保持简单但是不能太简单。
记 得这句话是爱因斯坦说（Keep it simple but not too simple! ）。它的道理是非常明显的，在完成需要的功能的前提下，实现越简单越好。反过来说，实现越简单越好，前提是要完成需要的功能。如果不能实现所需要的功能， 再简单又有什么用呢。我们要保持FTK实现上的简单性，但同时我们必须要实现GUI所需要的功能。
记得在开始FTK项目时，我和一位朋友 讨论FTK的需求。他说，对于嵌入式GUI，他关心的是，能不能在几K到几十K的内存的系统上使用。我说，这样的小系统，它的界面会很复杂吗，需要一个真 正的GUI吗？他后来说不需要。为一个简单得根本不需要GUI的系统设计一个GUI是没有什么意义的，FTK要保持简单，但是不能太简单。
GTK+ 太庞大，不适合在嵌入式系统中使用。而X Window和DirectFB虽然够轻量级，但它们没提供足够的功能，它们离开ToolKit单独使用非常困难。FTK要取其所长避其所短，设计得够简 单够小，才能在GTK+等传统GUI不能使用的地方使用，但是又必须要提供GUI常用的元素，对用户才有实用价值。
要够酷够时髦。
之 前我也分析过一些其它嵌入式GUI系统，它们通常都是仿照Windows传统的界面风格来实现的。它们的实现确实够轻易级，通常可执行二进制大小在 100K到500K之间，但给我的印象就是太土气了点，不能满足现代消费电子产品的需求(呵，真的不想通过扁别人来提高自己，欢迎对我的作法不满的朋友来 扁FTK)。所以在设计FTK时，我一直提醒自己，FTK一定要够酷够时髦。其中主要表现有：
1.支持主题
支持主题是现 代GUI的基本特征了。众口难调，没有一个GUI会让所有人喜欢，但是有了主题机制，通过一些数据和图片文件来配置显示风格，可以给用户多种不同的选择。 FTK的主题非常简单，在一个XML中设置各个控件的表现属性(不同状态的颜色和图片)，然后提供相关的图片文件即可。
2.支持窗口动画
窗口动画也是现代GUI吸人眼球的特征之一，是制作各种比较炫的效果的基础。FTK实现了滚动和淡入效果，并提供了一种机制，让开发者实现任何自己想要的效果。
3.支持透明/半透明效果
很多炫的效果离不开透明/半透明机制的支持。在FTK中，不管硬件平台的支持的多少颜色数和颜色格式，每个像素在内存中都由ARGB四个分量组成，其中8bit的alpha通道用来实现透明/半透明效果。
4.支持XML界面描述
XML界面描述也是现代GUI的基本特征了，它的魅力在于分离用户界面和内部实现，让它们能够独立变化。而且借助一些界面构建工具，生成用户界面变得更加容易。FTK实现了一个小巧的XML解析器，以非常轻量级的方式实现了对XML界面描述的支持。
5.支持脚本语言绑定
脚本语言的开发效率相对较高，部署也更加容易，越来越开发者的欢迎。呵，不懂一门脚本语言的程序员经常会被人鄙视的。FTK和其作者们自然不想被人鄙视，所以支持脚本绑定是FTK的首要目标之一，目前已经支持LUA的绑定(还需要进一步完善)。
6.支持输入法(特别是手写)
GUI 少了对中日韩文字的支持，注定是要失败的。对中日韩文字的支持包括编码，字体显示和输入法三个主要部分。FTK采用UTF-8编码，可以表示 Unicode中的所有字符。FTK支持点阵(内置)和矢量(需要freetype)字体，所以显示中日韩文字不成问题。输入法相对复杂一点，FTK目前 已经支持中文拼音、中文五笔和手写三种最常用的输入方式了。
7.支持屏幕旋转
很多手持设备，其屏幕的长度和宽度不一样。而有的内容适合横着看，有的内容适合竖着看，通过重力感应器自动旋转屏幕，可以提高系统的易用性。支持这个功能不难，只是优先级不高，FTK将会在今年支持这个功能。
8.支持手势识别和多点触摸
手势识别可以大大提高系统的易用性，随着触摸屏越来越流行，新一代GUI都支持手势识别了。多点触摸是手势识别的特例，需要硬件支持，从GUI的角度来说，实现难度不大。FTK将在今年支持手势识别和多点触摸，有兴趣的朋友可以来帮助增加这个功能。
欢迎大家参与讨论、学习、开发、编写文档和在产品中使用，让我们一起把FTK做成最好的嵌入式GUI吧。
万瑞瑞
手势识别 ,多点触摸。貌似很遥远。
屏幕旋转貌似是调用者来做的吧？GUI库能决定旋转后的界面么？
龟腚
zpcat
On 3月4日, 下午2时26分, 李先静 <xianji...@gmail.com> wrote:
> 记得X Window在设计初期就提出了七项基本指导原则，在后面X
> Window几十年的演变过程中，都以这些基本原则作为指导思想。其中给我印象比较深的一条就是：提供机制而不是策略。X
> Window一直都遵循这条原则，它只提供实现某些功能的机制，而把实现的策略留给ToolKit或其它辅助软件。为了让FTK在以后的演化过程中不至于
> 迷失方向，我们也给FTK定了三项基本原则：
>
> *第一：程序首先是给人读的，其次才是给机器读的。*
>
> 程 序首先是给人读的，其次才是给机器读的。这句话是很多程序员都认同的，加上FTK最初的目的就是作为《系统程序员成长计划》的综合练习项目，目标是让《系
> 统程序员成长计划》的读者通过阅读FTK的源代码，来学习如何把前面学到的知识应用到一个实际的项目中。所以把FTK代码的可读性放在第一位是理所当然 的。
>
> GUI无疑是最复杂的基础软件之一，在我研究过的GUI中，像X Window、DirectFB、
> GTK+和MicroWindows，它们都是非常复杂的软件系统。我写过不少关于它们内部实现的文章，但是我现在要非常惭愧的告诉你，这些GUI的实现
> 太复杂了，我其实没有完全搞明白过其中任何一个系统。分析一个GUI系统，对一个工作经验丰富的程序员来说尚且如此困难，对初学者的难度就可想而知了。不
> 过FTK则是希望成为人人可以读懂的GUI系统。如果你在阅读代码的过程遇到了难题，请不要犹豫，大胆的来和我们讨论吧，让我们一起想办法把它变得更加简 单。
>
> 为了提高FTK的可读性，我们采用了下列措施：
>
> 1.保持简单。
>
> 简单的东西才是容易理解的。从代码量
> 来讲，FTK的代码量只有GTK+的十分之一，总共代码在两万行以内，90%的文件的都是少于600行代码的，80%的模块对外的函数是少于10个的，单
> 个函数基本上都是少于50行代码的。从设计时，FTK也尽量选择简单的模型，比如只支持单进程单线程方式运行(其它线程可以通过idle来串行化对GUI
> 的访问)，从而避免引入进程间通信机制和并发带来的复杂度，这一点我们在后面有更详细的描述。
>
> 2.一致的代码风格。
>
> 代码 风格的一致性对代码可读性的帮助很大。FTK的文件名、函数名、变量名和类型名都遵循统一的命名风格，FTK中的命名风格和GTK+的命名风格基本上是一
> 致的。FTK所有代码的排版布局也保持高度一致，整体上的代码风格与《系统程序员成长计划》一书介绍的一致，如果你读过《系统程序员成长计划》，再看
> FTK的代码就像见到熟人一样。
>
> 3.避免复杂的算法。
>
> GUI和图形算法相对是比较复杂的。出人意料的是FTK几乎没有使
> 用任何复杂的算法，连画普通直线和圆弧的算法都没有，更不要说线性代数中那些矩阵变换了。FTK中尽量使用水平线和垂直线来绘制基本的图形，而用图像来实
> 现更复杂更美观的界面，这样就绕开了复杂的图形算法。不过，可以使用可选组件cairo来绘制复杂的矢量图和做些高级的图形变换。
>
> 4.设计高内聚的模块。
>
> 高内聚简单的说就是一个模块(或函数）只完成单一的功能，单一的功能从逻辑上更容易理解，代码量也更少。要保持简单，设计高内聚的模块是必要条件，把多个功能糅-合在一起，自然不可能做得简单了。
>
> 5.编写内部实现文档。
>
> 隔行如隔山。对于对GUI一点概念都没有的初学者来说，再简单的GUI也是难读的。为了降低初学者阅读FTK的门槛，我们决定写《》嵌入式GUI
> FTK设计与实现系列文章了，也希望大家都参与进来讨论和完善。
> *
> 保持简单但是不能太简单。*
>
> 记 得这句话是爱因斯坦说（Keep it simple but not too simple!
> ）。它的道理是非常明显的，在完成需要的功能的前提下，实现越简单越好。反过来说，实现越简单越好，前提是要完成需要的功能。如果不能实现所需要的功能，
> 再简单又有什么用呢。我们要保持FTK实现上的简单性，但同时我们必须要实现GUI所需要的功能。
>
> 记得在开始FTK项目时，我和一位朋友
> 讨论FTK的需求。他说，对于嵌入式GUI，他关心的是，能不能在几K到几十K的内存的系统上使用。我说，这样的小系统，它的界面会很复杂吗，需要一个真
> 正的GUI吗？他后来说不需要。为一个简单得根本不需要GUI的系统设计一个GUI是没有什么意义的，FTK要保持简单，但是不能太简单。
>
> GTK+ 太庞大，不适合在嵌入式系统中使用。而X
> Window和DirectFB虽然够轻量级，但它们没提供足够的功能，它们离开ToolKit单独使用非常困难。FTK要取其所长避其所短，设计得够简
> 单够小，才能在GTK+等传统GUI不能使用的地方使用，但是又必须要提供GUI常用的元素，对用户才有实用价值。
>
> *要够酷够时髦。*
>
> 之 前我也分析过一些其它嵌入式GUI系统，它们通常都是仿照Windows传统的界面风格来实现的。它们的实现确实够轻易级，通常可执行二进制大小在
> 100K到500K之间，但给我的印象就是太土气了点，不能满足现代消费电子产品的需求(呵，真的不想通过扁别人来提高自己，欢迎对我的作法不满的朋友来
> 扁FTK)。所以在设计FTK时，我一直提醒自己，FTK一定要够酷够时髦。其中主要表现有：
>
> 1.支持主题
>
> 支持主题是现
> 代GUI的基本特征了。众口难调，没有一个GUI会让所有人喜欢，但是有了主题机制，通过一些数据和图片文件来配置显示风格，可以给用户多种不同的选择。
> FTK的主题非常简单，在一个XML中设置各个控件的表现属性(不同状态的颜色和图片)，然后提供相关的图片文件即可。
>
> 2.支持窗口动画
>
> 窗口动画也是现代GUI吸人眼球的特征之一，是制作各种比较炫的效果的基础。FTK实现了滚动和淡入效果，并提供了一种机制，让开发者实现任何自己想要的效果。
>
> 3.支持透明/半透明效果
>
> 很多炫的效果离不开透明/半透明机制的支持。在FTK中，不管硬件平台的支持的多少颜色数和颜色格式，每个像素在内存中都由ARGB四个分量组成，其中8bit-的alpha通道用来实现透明/半透明效果。
>
> 4.支持XML界面描述
>
> XML界面描述也是现代GUI的基本特征了，它的魅力在于分离用户界面和内部实现，让它们能够独立变化。而且借助一些界面构建工具，生成用户界面变得更加容易。-FTK实现了一个小巧的XML解析器，以非常轻量级的方式实现了对XML界面描述的支持。
>
> 5.支持脚本语言绑定
>
> 脚本语言的开发效率相对较高，部署也更加容易，越来越开发者的欢迎。呵，不懂一门脚本语言的程序员经常会被人鄙视的。FTK和其作者们自然不想被人鄙视，所以支-持脚本绑定是FTK的首要目标之一，目前已经支持LUA的绑定(还需要进一步完善)。
>
> 6.支持输入法(特别是手写)
>
> GUI 少了对中日韩文字的支持，注定是要失败的。对中日韩文字的支持包括编码，字体显示和输入法三个主要部分。FTK采用UTF-8编码，可以表示
> Unicode中的所有字符。FTK支持点阵(内置)和矢量(需要freetype)字体，所以显示中日韩文字不成问题。输入法相对复杂一点，FTK目前
> 已经支持中文拼音、中文五笔和手写三种最常用的输入方式了。
>
> 7.支持屏幕旋转
>
> 很多手持设备，其屏幕的长度和宽度不一样。而有的内容适合横着看，有的内容适合竖着看，通过重力感应器自动旋转屏幕，可以提高系统的易用性。支持这个功能不难，-只是优先级不高，FTK将会在今年支持这个功能。
>
> 8.支持手势识别和多点触摸
>
> 手势识别可以大大提高系统的易用性，随着触摸屏越来越流行，新一代GUI都支持手势识别了。多点触摸是手势识别的特例，需要硬件支持，从GUI的角度来说，实现-难度不大。FTK将在今年支持手势识别和多点触摸，有兴趣的朋友可以来帮助增加这个功能。
songbohr
GUI无疑是最复杂的基础软件之一，在我研究过的GUI中，像X Window、DirectFB、 GTK+和MicroWindows，它们都是非常复杂的软件系统。我写过不少关于它们内部实现的文章，但是我现在要非常惭愧的告诉你，这些GUI的实现太复杂了，我其实没有完全搞明白过其中任何一个系统。分析一个GUI系统，对一个工作经验丰富的程序员来说尚且如此困难，对初学者的难度就可想而知了。不过FTK则是希望成为人人可以读懂的GUI系统。如果你在阅读代码的过程遇到了难题，请不要犹豫，大胆的来和我们讨论吧，让我们一起想办法把它变得更加简单。
为了提高FTK的可读性，我们采用了下列措施：
1.保持简单。
2.一致的代码风格。
代码风格的一致性对代码可读性的帮助很大。FTK的文件名、函数名、变量名和类型名都遵循统一的命名风格，FTK中的命名风格和GTK+的命名风格基本上是一致的。FTK所有代码的排版布局也保持高度一致，整体上的代码风格与《系统程序员成长计划》一书介绍的一致，如果你读过《系统程序员成长计划》，再看 FTK的代码就像见到熟人一样。
3.避免复杂的算法。
GUI和图形算法相对是比较复杂的。出人意料的是FTK几乎没有使用任何复杂的算法，连画普通直线和圆弧的算法都没有，更不要说线性代数中那些矩阵变换了。FTK中尽量使用水平线和垂直线来绘制基本的图形，而用图像来实现更复杂更美观的界面，这样就绕开了复杂的图形算法。不过，可以使用可选组件cairo来绘制复杂的矢量图和做些高级的图形变换。
4.设计高内聚的模块。
高内聚简单的说就是一个模块(或函数）只完成单一的功能，单一的功能从逻辑上更容易理解，代码量也更少。要保持简单，设计高内聚的模块是必要条件，把多个功能糅合在一起，自然不可能做得简单了。
5.编写内部实现文档。
隔行如隔山。对于对GUI一点概念都没有的初学者来说，再简单的GUI也是难读的。为了降低初学者阅读FTK的门槛，我们决定写《嵌入式GUI FTK设计与实现》系列文章了，也希望大家都参与进来讨论和完善。
保持简单但是不能太简单。
记得在开始FTK项目时，我和一位朋友讨论FTK的需求。他说，对于嵌入式GUI，他关心的是，能不能在几K到几十K的内存的系统上使用。我说，这样的小系统，它的界面会很复杂吗，需要一个真正的GUI吗？他后来说不需要。为一个简单得根本不需要GUI的系统设计一个GUI是没有什么意义的，FTK要保持简单，但是不能太简单。
GTK+ 太庞大，不适合在嵌入式系统中使用。而X Window和DirectFB虽然够轻量级，但它们没提供足够的功能，它们离开ToolKit单独使用非常困难。FTK要取其所长避其所短，设计得够简单够小，才能在GTK+等传统GUI不能使用的地方使用，但是又必须要提供GUI常用的元素，对用户才有实用价值。
要够酷够时髦。
1.支持主题
支持主题是现代GUI的基本特征了。众口难调，没有一个GUI会让所有人喜欢，但是有了主题机制，通过一些数据和图片文件来配置显示风格，可以给用户多种不同的选择。 FTK的主题非常简单，在一个XML中设置各个控件的表现属性(不同状态的颜色和图片)，然后提供相关的图片文件即可。
2.支持窗口动画
窗口动画也是现代GUI吸人眼球的特征之一，是制作各种比较炫的效果的基础。FTK实现了滚动和淡入效果，并提供了一种机制，让开发者实现任何自己想要的效果。
3.支持透明/半透明效果
很多炫的效果离不开透明/半透明机制的支持。在FTK中，不管硬件平台的支持的多少颜色数和颜色格式，每个像素在内存中都由ARGB四个分量组成，其中8bit的alpha通道用来实现透明/半透明效果。
4.支持XML界面描述
XML界面描述也是现代GUI的基本特征了，它的魅力在于分离用户界面和内部实现，让它们能够独立变化。而且借助一些界面构建工具，生成用户界面变得更加容易。FTK实现了一个小巧的XML解析器，以非常轻量级的方式实现了对XML界面描述的支持。
5.支持脚本语言绑定
脚本语言的开发效率相对较高，部署也更加容易，越来越开发者的欢迎。呵，不懂一门脚本语言的程序员经常会被人鄙视的。FTK和其作者们自然不想被人鄙视，所以支持脚本绑定是FTK的首要目标之一，目前已经支持LUA的绑定(还需要进一步完善)。
6.支持输入法(特别是手写)
李先静
我没有仔细读过miniGUI的源代码。我个人对魏永明是非常尊敬的，他写miniGUI时我还是个门外汉。从网上的资料来看，miniGUI是很成功的，microwindows停止开发后，除了miniGUI，似乎没有几个成气候的轻量级开源GUI了。
如果要拿FTK和miniGUI相比，我希望FTK代码可读性更好，表现更酷，更开放(永久免费用于商业软件和开源软件)，FTK的成功需要各位兄弟一起努力！
tao yu
songbohr
tao yu
李先静
The terms(widget, source, idle, im_context, entry, text_view, ..) and name conventions(function/type/variable) come from GTK+.
The interface in C style and PC emulators come from DirectFB.
The modern features (animation, rotation, gesture...) come from Android.
FTK try to implement these good ideas with very light-weight style.
I once worked for HTW from 2004 to 2005. HTW developed a business phone(also known as ShangWuTong) with microwindows, there were 4 or 5 developers maintaining GUI. My first task was testing microwindows and reviewing its code，I found it's complicated and unstable(more than 12,000 bugs found in that project, I don't know how many bugs caused by GUI).
I learned the basic knowledge of GUI implementation from microwindows, but I don't like it.
phil song
Sub-Module List:
l EventQueue
l DeviceMonitor
l Dispatcher
l WindowSystem
n Window
u Control
u Menu
u Edit
u Label
u Button
l PrintManager
l Utility
l Customize
Most ideas of FTK come from GTK+, DirectFB and Android: |
|
= = = = = = = = = = = = = = = = = = = = = =
joshua
On Mar 5, 2:53 pm, 李先静 <xianji...@gmail.com> wrote:
> webkit占多少内存主要与打开的网页有关，对于小于32M内存的系统，运行webkit确实有点困难。UC浏览器好像完全是用JAVA写的。
>
> 在 2010年3月5日 下午2:40，phil song <phils...@techtrex.com>写道：
>
>
>
> > Hi,李先静,
>
> > 请问webkit占多少内存？UC浏览器用的是不是webkit核？一般的嵌入式内存只有2M-32M。
>
> > Yours sincerely!
> > phil song
> > 2010-03-05
>
> > ======== 2010-03-05 14:29:12 The content in your letter： ========
>
> > 这种设计还是不错的。不过，对于需要让逻辑运行在另外一台机器上的需求，我觉得采用B/S架构更方便一些。我倒是想用FTK+webkit+linux，做一个-类似于ChromeOS的系统。
>
> > 在 2010年3月5日 上午11:15，phil song <phils...@techtrex.com>写道：
>
> >> Hi,absurd,
>
> >> Thanks for your reply firstly.
>
> >> I agree your opinion about GUI special for embedded system,but I have a
> >> question about design for whole project(not only GUI part).
>
> >> Our developer team had developed a GUI and Logic module for POS and
> >> ATM projects last year,GUI communicates with logic via socket. If applcation
> >> uses that way ,we can run GUI in one machine,and run logical module in
> >> another.It is discarded due to non-tech reason at last.
>
> >> like this:
> >> GUI<-----socket---------->Logic
>
> >>> 2010/3/5 songbohr <songb...@gmail.com>
>
> >>> I agree with you,I am in nanox mails list.
>
> >>>> I find yongming.wei took part in developing the microwindows in 2000
> >>>> years because I find his comments in microwindows code.
>
> >>>> and,I find ftk is similar with microwindows. I am unsure whether
> >>>> xianjing.li borrow ideas from that.Microwindows have
> >>>> backgroud,window,engine.and ftk has those too.Is it a coincidence?
>
> >>>> I cannot receive email in company by gmail.hi,absurd,could you add me to
> >>>> group using my another email phils...@techtrex.com.
>
> >>>> Thanks.
>
> >>>> ------------------------------
> >>>> songbohr
> >>>> 2010-03-05
> >>>> ------------------------------
> >>>> *发件人：* tao yu
> >>>> *发送时间：* 2010-03-04 22:32:08
> >>>> *收件人：* funnytoolkit
> >>>> *抄送：*
> >>>> *主题：* Re: [funnytoolkit] 嵌入式GUI FTK设计与实现-三项基本原则
>
> >>>> nanox is active again this year, and will release 0.92 very soon. :)
>
> >>>> 2010/3/4 李先静 <xianji...@gmail.com>
>
> >>>>> 呵，先说一下称呼，千万不要叫我李总，因为我从来没有当过什么总。大家叫我李工，先静，absurd，或者先静兄，absurd兄都可以。
>
> >>>>> 我没有仔细读过miniGUI的源代码。我个人对魏永明是非常尊敬的，他写miniGUI时我还是个门外汉。从网上的资料来看，miniGUI是很成功的，mi-crowindows停止开发后，除了miniGUI，似乎没有几个成气候的轻量级开源GUI了。
>
> >>>>> 如果要拿FTK和miniGUI相比，我希望FTK代码可读性更好，表现更酷，更开放(永久免费用于商业软件和开源软件)，FTK的成功需要各位兄弟一起努力！
>
> >>>>> 在 2010年3月4日 下午8:43，songbohr <songb...@gmail.com>写道：
>
> >>>>> 不知道 李总怎么评价miniGUI?
>
> >>>>>> ------------------------------
> >>>>>> songbohr
> >>>>>> 2010-03-04
> >>>>>> ------------------------------
> >>>>>> *发件人：* 李先静
> >>>>>> *发送时间：* 2010-03-04 14:26:14
> >>>>>> *收件人：* funnytoolkit
> >>>>>> *抄送：*
> >>>>>> *主题：* [funnytoolkit] 嵌入式GUI FTK设计与实现-三项基本原则
>
> >>>>>> 记得X Window在设计初期就提出了七项基本指导原则，在后面X
> >>>>>> Window几十年的演变过程中，都以这些基本原则作为指导思想。其中给我印象比较深的一条就是：提供机制而不是策略。X
> >>>>>> Window一直都遵循这条原则，它只提供实现某些功能的机制，而把实现的策略留给ToolKit或其它辅助软件。为了让FTK在以后的演化过程中不至于迷失方-向，我们也给FTK定了三项基本原则：
>
> >>>>>> *第一：程序首先是给人读的，其次才是给机器读的。*
>
> >>>>>> 程序首先是给人读的，其次才是给机器读的。这句话是很多程序员都认同的，加上FTK最初的目的就是作为《系统程序员成长计划》的综合练习项目，目标是让《系统程-序员成长计划》的读者通过阅读FTK的源代码，来学习如何把前面学到的知识应用到一个实际的项目中。所以把FTK代码的可读性放在第一位是理所当然的。
>
> >>>>>> GUI无疑是最复杂的基础软件之一，在我研究过的GUI中，像X Window、DirectFB、
> >>>>>> GTK+和MicroWindows，它们都是非常复杂的软件系统。我写过不少关于它们内部实现的文章，但是我现在要非常惭愧的告诉你，这些GUI的实现太复杂-了，我其实没有完全搞明白过其中任何一个系统。分析一个GUI系统，对一个工作经验丰富的程序员来说尚且如此困难，对初学者的难度就可想而知了。不过FTK则是-希望成为人人可以读懂的GUI系统。如果你在阅读代码的过程遇到了难题，请不要犹豫，大胆的来和我们讨论吧，让我们一起想办法把它变得更加简单。
>
> >>>>>> 为了提高FTK的可读性，我们采用了下列措施：
>
> >>>>>> 1.保持简单。
>
> >>>>>> 简单的东西才是容易理解的。从代码量来讲，FTK的代码量只有GTK+的十分之一，总共代码在两万行以内，90%的文件的都是少于600行代码的，80%的模块-对外的函数是少于10个的，单个函数基本上都是少于50行代码的。从设计时，FTK也尽量选择简单的模型，比如只支持单进程单线程方式运行(其它线程可以通过i-dle来串行化对GUI
> >>>>>> 的访问)，从而避免引入进程间通信机制和并发带来的复杂度，这一点我们在后面有更详细的描述。
>
> >>>>>> 2.一致的代码风格。
>
> >>>>>> 代码风格的一致性对代码可读性的帮助很大。FTK的文件名、函数名、变量名和类型名都遵循统一的命名风格，FTK中的命名风格和GTK+的命名风格基本上是一致-的。FTK所有代码的排版布局也保持高度一致，整体上的代码风格与《系统程序员成长计划》一书介绍的一致，如果你读过《系统程序员成长计划》，再看
> >>>>>> FTK的代码就像见到熟人一样。
>
> >>>>>> 3.避免复杂的算法。
>
> >>>>>> GUI和图形算法相对是比较复杂的。出人意料的是FTK几乎没有使用任何复杂的算法，连画普通直线和圆弧的算法都没有，更不要说线性代数中那些矩阵变换了。FT-K中尽量使用水平线和垂直线来绘制基本的图形，而用图像来实现更复杂更美观的界面，这样就绕开了复杂的图形算法。不过，可以使用可选组件cairo来绘制复杂的-矢量图和做些高级的图形变换。
>
> >>>>>> 4.设计高内聚的模块。
>
> >>>>>> 高内聚简单的说就是一个模块(或函数）只完成单一的功能，单一的功能从逻辑上更容易理解，代码量也更少。要保持简单，设计高内聚的模块是必要条件，把多个功能糅-合在一起，自然不可能做得简单了。
>
> >>>>>> 5.编写内部实现文档。
>
> >>>>>> 隔行如隔山。对于对GUI一点概念都没有的初学者来说，再简单的GUI也是难读的。为了降低初学者阅读FTK的门槛，我们决定写《嵌入式GUI
> >>>>>> FTK设计与实现》系列文章了，也希望大家都参与进来讨论和完善。
> >>>>>> *
> >>>>>> 保持简单但是不能太简单。*
>
> >>>>>> 记得这句话是爱因斯坦说（Keep it simple but not too simple!
> >>>>>> ）。它的道理是非常明显的，在完成需要的功能的前提下，实现越简单越好。反过来说，实现越简单越好，前提是要完成需要的功能。如果不能实现所需要的功能，再简单-又有什么用呢。我们要保持FTK实现上的简单性，但同时我们必须要实现GUI所需要的功能。
>
> ...
>
> read more >>
>
> Catch0(03-05-14-37-05).jpg
> 136KViewDownload- Hide quoted text -
>
> - Show quoted text -
_________________________________________________
李工，其实也不一定需要走移植webkit的路，webkit太重，可以自己来写支持wap/html的浏览器,
没有想象的复杂，但这样的话，费的时间多一些......
呵呵：）
其实我觉得移植不移植webkit本身不重要，我觉得需要重构下当前的架构......
实现当前widget 元素tree与真实的widget控件渲染tree分离，最好实现类似web的边下载边解析，
lay out机制更灵活一些（不需要指定x,y）......个人觉得提供一个htmlcontrol就可以了......
其实差不多了......个人意见，有点不知天高地厚了：）
joshua
李工，其实也不一定需要走移植webkit的路，webkit太重，可以自己来写支持wap/html的浏览器,
没有想象的复杂，但这样的话，费的时间多一些......
呵呵：）
其实我觉得移植不移植webkit本身不重要，
个人觉得对于ftk gui 提供一个htmlcontrol就足够了......
个人意见，有点不知天高地厚了：）
tao yu
phil song
你的意思是剩余的GUI 交给web开发者写html？
Sincerely
phil song
2010-03-05
======= 2010-03-05 16:59:46 The letter which you wrote before:=======
joshua
嗯，这样比较方便一些......可以节省开发效率......哈哈
李先静
joshua
------------------------
李工，其实也不一定需要走移植webkit的路，webkit太重，可以自己来写支持wap/html的浏览器,
没有想象的复杂，但这样的话，费的时间多一些......
呵呵：）
其实我觉得移植不移植webkit本身不重要，我觉得需要重构下当前的架构......
实现当前widget 元素tree与真实的widget控件渲染tree分离，最好实现类似web的边下载边解析，
lay out机制更灵活一些（不需要指定x,y）.....
个人觉得对于ftk gui来说提供一个htmlcontrol就足够了......
个人意见，有点不知天高地厚了：）
yapo
1. webkit 是目前全功能浏览器最好最现实的选择。
2. 考虑到实际的开发者群体包括了不同开发习惯的开发人员，基于浏览器的UI设计只能满足部分开发人员的需要，虽然开发效率较高但是运行效率必然较低（同等编码水平下）。所以觉得移植webkit
和 提供native的UI api 都是需要的。
2010/3/5 joshua <hua...@126.com>:
phil song
建议默认把data目录设成当前目录，我打了日志才发现是宏定义的。。。。
font filename1=/home/phil/ftk-0.2/data/unicode.fnt
ftk_mmap_create:49 stat(filename, &st) == 0 failed.
font filename2=/usr/local/share/ftk/base/data/unicode.fnt
ftk_mmap_create:49 stat(filename, &st) == 0 failed.
ftk_deinit: ftk exit.
load font failed.
Sincerely
phil song
2010-03-08
phil song
而且font和theme的加载顺序又是反的，晕哦
ftk_theme_parse_file:459 m != NULL failed.
ftk_theme_parse_file:459 m != NULL failed.
ftk_init_input:16 dir != NULL failed.
FB: /dev/fb0
不介意就给我开放个写权限，我来改下这些细节，用着不爽
Sincerely
phil song
2010-03-08
======= 2010-03-08 15:02:20 The letter which you wrote before:=======
李先静
欧阳
李先静
phil song
Yours sincerely!
= = = = = = = = = = = = = = = = = = = = = =
李先静
phil song
Yours sincerely!
Most ideas of FTK come from GTK+, DirectFB and Android: |
|
