Atiti.ui原理與gui理論

我來補充一種比較新穎的GUI實現模式，叫作Immediate Mode GUI (IMGUI)。這種類型的更多的適用於顯示區域實時刷新的程序裏面，例如遊戲和CAD等。IMGUI這種實現模式的優點在於他在實現和實用上都會比傳統的Retained Mode GUI (RMGUI)，例如Qt, MFC等，要簡單很多。我本身兩種模式都實現過，我認爲IMGUI比較適合想學習本身寫GUI的人上手。貼一個我本身實現的一個輕量級GUI庫的效果圖和程序，想玩玩的戳連接：EDXGui。能夠看出IMGUI也能夠實現較爲複雜的控件，給本身的雜七雜八的程序用綽綽有餘了。

2.2. Cli

2.3. Gui

2.4. Nui natural user interface

3. Ui發展的3個階段

人機界面的發展，主要通過了三個階段

3.1. 1. 命令行界面 CLI

命令行的用戶行爲模式，是記憶->輸入，用戶要背下各個命令，單後輸入同機器交互，使用門檻高，如今只有專業人士和好萊塢電影裏要表現黑客們的牛逼才使用

做者:: ★(attilax)>>> 綽號:老哇的爪子（全名：：Attilax Akbar Al Rapanui 阿提拉克斯阿克巴阿爾拉帕努伊）漢字名：艾龍， EMAIL:1466519819@qq.com

轉載請註明來源： http://www.cnblogs.com/attilax/

3.2. Gui(click

蘋果推出，windows發揚光大，其用戶行爲模式，是識別->選擇，用戶不用背命令了，拿着軟件就能夠鼠標亂點進行探索，這個時候大部分軟件的用戶手冊都沒人看了，交互門檻下降，可是咱們沒接觸過電腦的父輩仍是會以爲有距離感，有學習門檻。
GUI其實是使用標準的一套圖形界面語言（按鈕，列表，文本框等），全部的應用需求都轉化爲這套界面語言呈現，信息內容要依附於界面語言形式表現

3.3. Nui(touch

iphone及ipad的出現，將機器交互門檻大大下降，基本全部人包括老人小孩都能拿着就用。由於其交互語言發生了變化，再也不是用標準化控件來設計界面，這時內容>形式，形式要依附信息內容的使用場景。符合人對內容表現和交互的天然預期，這樣，界面引擎僅提供標準的控件就沒法知足要求。

4. Gui的原理解決兩個問題，「輸入」和「輸出」

圖形界面，就是解決兩個問題，「輸入」和「輸出」「輸入」就是用戶經過鍵盤，鼠標，觸摸屏定製設備按鈕等各類硬件裝置進行的輸入操做，經過這些設備的驅動，最後被操做系統轉化爲各類事件消息，圖形界面要響應並管理好這些消息；「輸出」就是顯示，讓用戶看到的內容，圖形界面最終要在屏幕上顯示出來，須要操做系統提供這個接口，本質仍是顯示芯片的驅動提供這個功能。不考慮效率的話，給個畫點的函數就夠了。但畫點確定太慢，因此通常會是一個拷屏的上屏操做，用緩衝防止閃爍；「獲取輸入消息」，「輸出上屏」，這兩點就是圖形界面的「輪子」和「火」。兩個方式都依賴操做系統提供的接口，並且不一樣操做系統的接口也不定相同，甚至同一操做系統也有不一樣的方法實現。對於跨平臺圖形界面引擎，這兩部分的基本代碼是不跨平臺的，針對不一樣平臺會有不一樣實現，可是這兩部分代碼不會不少，封裝的好也不影響上層開發。

4.1. Gui的結構

GUI庫，有幾個基本的子系統：

4.2. 界面引擎和圖形引擎

圖形引擎和基本庫 首先要說明的是，雖然常常說圖形界面引擎，但界面引擎和圖形引擎，這是兩個不一樣的東西，就如同MFC和GDI，android UI庫和skia的關係，圖形引擎任務是提供基本的繪製方法，如何畫位圖，縮放位圖，如何畫線條多邊形等矢量圖形，還有很重要的，如何繪製文字，這些依賴一些基本庫，除非你想本身解析jpg png等圖片格式，本身讀取字體對文字進行矢量渲染。好在大部分這些庫都是開源而且商業友好的（免費） 還有一些支持庫，好比多線程，文件IO，數學算法。所以，一個圖形界面引擎，有如下基本組成部分

4.3. 窗口管理控件系統

4.4. 事件系統

4.5. 圖形系統渲染機制

4.6. 佈局系統

4.7. 動畫

4.8. 一些雜項 utility：

4.9. 經常使用控件集合：特殊控件：

基本框架穩定了，就要作一些比較經常使用的基本控件供應用層直接使用，按鈕，列表，滑動條，進度條等

特殊控件：一些比較特殊的控件，好比模式對話框，彈出菜單，和常規控件的設計會有差別，他們基本須要全局管理。

4.10. 編輯工具：

是否須要圖形界面的編輯工具，對於靜態界面，就如windows的對話框，各類按鈕，列表框，有一個所見即所得的編輯工具會提升界面開發效率

5. Ui的趨勢cli>gui>nui

UI引擎，雖然會提供一套標準控件，可是更重要的，要知足兩個需求

5.1. 方便使用的動態機制，

使用者不用考慮定時器，多線程，異步處理等，能實現界面元素的各類屬性動畫

5.2. 方便的控件拓展機制，

要更方便的定義一個新的控件，讓使用者更專一於定義控件行爲，而不用管控件的消息處理，繪製處理這兩個層面的事情。以前的老HMI引擎，每次生成一個新控件，都要重載Draw和DoMessage兩個方法，新的NUI引擎經過相似android庫drawable層的封裝，並引入信號槽機制，已能夠像搭積木同樣搭建控件，而沒必要再重寫這兩個方法

5.3. 腳本化(native>> html5)

市面上許許多多的js庫，其實就表明將來界面庫的發展方向：再也不使用傳統的控件體系，而是用比控件更小粒度的原子控件---就好比迅雷界面庫裏的各類原子控件，又如js庫裏所使用的那些html元素。你會發現，只使用基本的幾個元素，而後強化他們的拼裝方式，能更方便快捷的實現產品提出的那些奇怪需求。
有了原子控件，你拼裝出異性控件更加方便，你要實現控件各類動畫也更加簡潔。當你仍是以爲有點不足，

如今的NUI引擎基本達到這兩個目標。開發門檻低，

6. 本身的ui 引擎

其實沒有想象的複雜，只要抓住輸入和輸出兩個線索。操做系統只須要給程序一個無邊距窗口，窗口內容許貼圖，窗口能夠接受消息或事件，那麼就能夠發展出一套本身的GUI。

而後，你得定義一種邏輯概念，對應窗口，控件，Sprite，無所謂你本身決定....你的界面元素都是從這個概念逐層派生的，而後用Tree組織起來的。個人平臺是用Sprite這個名稱。

Sprite對象自帶一張Bitmap，固然這個Bitmap也是我本身定義的數據結構以儘可能與系統無關。最後顯示實際上就是從背景的Cavas不斷的貼上各層Sprite的bitmap獲得一個總的Bitmap，而後調用系統的顯示圖片的函數(Windows下可用DirectX或者StreetchDIB)顯示給用戶。

那麼RenderOneTime裏面顯然就作兩個事情，
1，通知頂層Sprite，根據時間戳和自身狀態更新本身的Bitmap，而頂層Sprite要作到這一點就得不斷通知下層的Sprite，遍歷。
2，更新完畢後，獲得一個矩形區域表示哪些地方變化了，而後用顯示函數顯示出來。
這樣，界面輸出部分就完成了。系統能夠按照設定的幀率更新界面，甚至支持動畫。
-------------------------------------------------

那麼輸入部分就更簡單了，自定義了消息隊列和消息分發系統，從操做系統獲得消息或者事件後，轉化爲自定義的消息，而後分發給對應的Sprite去響應就能夠了。

注意渲染和消息處理是兩個不一樣的線程，因此同步設計很重要。

-----------------------------------------------------
字體處理部分仍是部分系統相關的，移植時候須要一塊兒改動。
GDI畫線什麼的都是本身的函數，由於繪畫對象直接是本身定義的內存Bitmap。
-----------------------------------------------------
這樣一來，須要移植的時候只須要把系統相關的代碼包括消息處理，顯示處理，以及線程相關的代碼等替換到新的系統，就能夠完成移植了。目前個人產品能夠跨Windows和mac平臺。有些小不穩定，但整體還能夠勉強達到產品應用水平。