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平台。有些小不稳定，但整体还能够勉强达到产品应用水平。

参考资料

如何用 C++ 从零编写 GUI？ - 图形用户界面 - 知乎.html