總體構思
將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(){}; 這些就用得很熟啊! :-)