FrankHB · April 15, 2020 13:45
diff --git a/20200415.txt b/20200415.txt
 imgui 不算正经的 retaining style GUI ，和图形库本身差距小，容易移植……代价是用户写 GUI 不爽了。
 https://www.zhihu.com/question/267602287
 咦汝装ice也是受害者、、、
 【抖M】幻の上帝  20:29:12

 ……

 的确神烦、、
 【弱受】被子飞了  20:31:42
 “幻の上帝   20:29:37  查看原文
 [图片]
 的确神烦、、
 这倒是，不知道的还以为可以用负数表达其它信息
 “幻の上帝   20:28:00  查看原文
 imgui 不算正经的 retaining style GUI ，和图形库本身差距小，容易移植……代价是用户写 GUI 不爽了。
 挺爽的啊
 【抖M】幻の上帝  21:14:15
 如果你的开发逻辑是 demo - screenshot - release 那似乎确实是很爽，但稍微挖开来一看就是要啥没啥。
 因为根本上所谓的 immediate mode 实际的干活只是搞定了图形输出，其它都是都是凑上去的/踢皮球原封不动地扔给底层，要表示任何不和图形直接紧耦合的 interaction 和不被 UI 独占的 model state 都要用户自己另外糊逻辑。
 要我说的话，这种东西根本算不上 GUI ，因为连经典的 WIMP metaphor 都放不下，更不可能提供和 UI 直接对应的状态扩展接口做 scripting （比如说事件过滤和 mocking ）；甚至对开发者来说都算不上整个 UI ，因为很可能连个交互式程序的框架搞不好都要用户自己糊（连个 invalidate 都处理不好搞得吃满 CPU 核的事件循环显然是在多任务系统中不合格的）。

 imgui 的案例没有一个是框架级别的二次开发的。（当然，Qt 也是金玉其外败絮其中的翔，但那是另一回事。）
 跳出框架开发，在 GUI 这个领域上有 imgui 有两个主要的问题。
 1.定位本来就不咋地，能适应的 GUI 虽然可能用得场景不少，但不管是结构还是依赖 GUI 特性的功能都很不典型，基本只适合呈现时间上连续的数据+简单的输入这种场合（响应输入基本上还不是 imgui 自己干的活），这些场合渲染操作的无用功都可能容易被容忍。大部分 imgui 去试图实现（非游戏的）GUI 的用例是一些小的配置工具，也就是搞定一个固定布局然后硬挨用户的固定输入转换为固定输出的简单逻辑。你当然很容易地发现这比传统拖控件糊代码直观容易，因为逻辑和图形输出对应得很清晰，模型就是极简的甚至根本不需要在图形状态以外表示，传统上指定布局逻辑以及部件和模型的关系之类的操作就是冗余的——但这只是一个原因。另一个根本原因是后者设计得太蠢而不能保证用最小的代价实现最小的需求，而你又常常被蠢方案束缚了想象力，没发现其实直接用脚本配置比你糊 C艹 这样的代码之类的方案还要更容易得多的关系……当然，不想去搞懂脚本怎么用是另一回事。
 2.这些 imgui 剥离状态的操作其实很叒鸡。不像纯 FP 语言整体把状态翻译掉或者生造什么 FRP 来处理整个程序的状态，模型的状态是否容易用 imgui API 实现原则上是不可预测的；你得对具体的 UI 长得什么样相当地清楚，才能明白 imgui 里的状态和不能实现在 imgui 的状态之间的关系。这种对 UI state 的割裂导致 reactive model 基本不可实现。
 根本上这些不爽都来自抽象不足引起的依赖混乱的方法论错误。
 所谓的 imgui 是 rmgui 削除抽象机能后的特例。任何一个像样的 rmgui ，都能合理地包装出 imgui 的接口；用 imgui 去模拟 rmgui ，基本只能重新造一个（也还没 imgui 没有自知之明到想干掉主流 rmgui ）。大多用 imgui 完成任务的用户，本来就是因为 rmgui 繁琐才去用的，于是遇到不适合 imgui 完成的任务嘛……
 例子：YSLib::UI 可以往上糊 EGE ，反过来除非在 EGE 里包含一个 rmgui 就做不到。同理，xege 糊 ctl 用了 Win32 控件，而不是凭空造一个（自己造就变成 GUI 而不止是图形库了）。说 imgui 更接近图形库而算不上真正的 GUI 实现也是类似的——它基本上就是图形库上套了层皮而已；而 GUI 首先是 UI ，其次才指望 G 。
	imgui 不算正经的 retaining style GUI ，和图形库本身差距小，容易移植……代价是用户写 GUI 不爽了。
	https://www.zhihu.com/question/267602287
	咦汝装ice也是受害者、、、
	【抖M】幻の上帝 20:29:12

	……

	的确神烦、、
	【弱受】被子飞了 20:31:42
	“幻の上帝 20:29:37 查看原文
	[图片]
	的确神烦、、
	这倒是，不知道的还以为可以用负数表达其它信息
	“幻の上帝 20:28:00 查看原文
	imgui 不算正经的 retaining style GUI ，和图形库本身差距小，容易移植……代价是用户写 GUI 不爽了。
	挺爽的啊
	【抖M】幻の上帝 21:14:15
	如果你的开发逻辑是 demo - screenshot - release 那似乎确实是很爽，但稍微挖开来一看就是要啥没啥。
	因为根本上所谓的 immediate mode 实际的干活只是搞定了图形输出，其它都是都是凑上去的/踢皮球原封不动地扔给底层，要表示任何不和图形直接紧耦合的 interaction 和不被 UI 独占的 model state 都要用户自己另外糊逻辑。
	要我说的话，这种东西根本算不上 GUI ，因为连经典的 WIMP metaphor 都放不下，更不可能提供和 UI 直接对应的状态扩展接口做 scripting （比如说事件过滤和 mocking ）；甚至对开发者来说都算不上整个 UI ，因为很可能连个交互式程序的框架搞不好都要用户自己糊（连个 invalidate 都处理不好搞得吃满 CPU 核的事件循环显然是在多任务系统中不合格的）。

	imgui 的案例没有一个是框架级别的二次开发的。（当然，Qt 也是金玉其外败絮其中的翔，但那是另一回事。）
	跳出框架开发，在 GUI 这个领域上有 imgui 有两个主要的问题。
	1.定位本来就不咋地，能适应的 GUI 虽然可能用得场景不少，但不管是结构还是依赖 GUI 特性的功能都很不典型，基本只适合呈现时间上连续的数据+简单的输入这种场合（响应输入基本上还不是 imgui 自己干的活），这些场合渲染操作的无用功都可能容易被容忍。大部分 imgui 去试图实现（非游戏的）GUI 的用例是一些小的配置工具，也就是搞定一个固定布局然后硬挨用户的固定输入转换为固定输出的简单逻辑。你当然很容易地发现这比传统拖控件糊代码直观容易，因为逻辑和图形输出对应得很清晰，模型就是极简的甚至根本不需要在图形状态以外表示，传统上指定布局逻辑以及部件和模型的关系之类的操作就是冗余的——但这只是一个原因。另一个根本原因是后者设计得太蠢而不能保证用最小的代价实现最小的需求，而你又常常被蠢方案束缚了想象力，没发现其实直接用脚本配置比你糊 C艹这样的代码之类的方案还要更容易得多的关系……当然，不想去搞懂脚本怎么用是另一回事。
	2.这些 imgui 剥离状态的操作其实很叒鸡。不像纯 FP 语言整体把状态翻译掉或者生造什么 FRP 来处理整个程序的状态，模型的状态是否容易用 imgui API 实现原则上是不可预测的；你得对具体的 UI 长得什么样相当地清楚，才能明白 imgui 里的状态和不能实现在 imgui 的状态之间的关系。这种对 UI state 的割裂导致 reactive model 基本不可实现。
	根本上这些不爽都来自抽象不足引起的依赖混乱的方法论错误。
	所谓的 imgui 是 rmgui 削除抽象机能后的特例。任何一个像样的 rmgui ，都能合理地包装出 imgui 的接口；用 imgui 去模拟 rmgui ，基本只能重新造一个（也还没 imgui 没有自知之明到想干掉主流 rmgui ）。大多用 imgui 完成任务的用户，本来就是因为 rmgui 繁琐才去用的，于是遇到不适合 imgui 完成的任务嘛……
	例子：YSLib::UI 可以往上糊 EGE ，反过来除非在 EGE 里包含一个 rmgui 就做不到。同理，xege 糊 ctl 用了 Win32 控件，而不是凭空造一个（自己造就变成 GUI 而不止是图形库了）。说 imgui 更接近图形库而算不上真正的 GUI 实现也是类似的——它基本上就是图形库上套了层皮而已；而 GUI 首先是 UI ，其次才指望 G 。