我的chGUI (4)
总体构思
将chGUI按分层设计, 最低层是硬件抽像层, 由图形抽像GAL和输入抽象IAL组成, IAL不作重点.
第二层是GDI层, 实现通用的2D图形功能, 字体Font, 文本输出, 设备上下文DC等功能
最三层窗口控件层, 实现窗口管理, 消息传递, 通用控制等功能.
首先以上述的功能有主, 并为扩展留下余地, 便于加入多任务操作系统, 外观换肤(skin)等.
说心里, 大体的划分谁都会,但是真正将每层的具体接口描述出来, 也是很不容易的.
我仔细看了ucGUI的代码, 硬是难以将各层的接口很好的分离出来, 特别是从源码的实现层分离,更不容易. 我在网查了很久, 就是没有发现分析ucGUI整体架构的资料, 大部分都是以使用ucGUI为主的资料. 希望有高手能分析分析啊!
我对ucGUI速体的感觉是, 各部分藕合太紧密了, 根本无法将某个源文件独立出来分析. 当然也可能是我技术不够,看不明白哟! ucGUI如果是C++实现的,会不会好一点呢?!
PS. 思考的问题.
1. 颜色问题.
先将颜色分为二种, 一是24位的真彩色(R8G8B8), 这个可是全世界通用的哟,基本上可以表达这世界所有的颜色了, 暂将其称为颜色, 二是对应我们的LCD屏, 可能只有8位或16位或更少位的颜色, 它只对应24位颜色中的一部分, 我们称其为颜色索引吧. 这种说法不太准确, 但我真的想不出好的名称了.
在chGUI中上层, 描述颜色当然用24位, 这样可以脱离具体的硬件. 但最终它必需转化为颜色索引, 写入具体的LCD硬件中, 问题就是在哪一层实现, 这种转化呢?
a. 在颜色的定义时, 就用直接将24位颜色转化为颜色索引, 那么在带个GUI中, 实际用的就是颜色索引, 这么可以减少资源的使用(24位要用4Byte的int表示, 如果索引为8位, 就只占用1Byte就行), 但我总感觉不太妥当. 假如,在GUI中进行颜色的运算(如异或运算), 其'精度肯定不会太好啊!
b.在硬件层实现转化, 整个GUI都用32位颜色, 只在最后,写入LCD之前, 才转化为颜色索引. 这样的话, 颜色要占用4byte, 有点浪费资源, 对于单片机有点残忍. ucGUI好像就是这样做的.
在chGUI, 我先用a种方案吧! 以节省资源为主. 不知我的想法对不对, 请高手指点哟!
2.剪切区问题
3.字体问题
这些问题等到具体设计时, 再考虑吧!
今天就写这么多, 打字真痛苦, 要是我的E文好, 用E文来写, 效率肯定高多了. 我很少练汉字的, 只是abcde(){}; 这些就用得很熟啊! :-)