辛昕

接下来，会考虑如何实际组织界面

实际上，在交流中我发现，每个做过 人机界面 的人——不管是像我这样，在单片机上自己实现，还是使用某个特定的库如ucgui或者在PC上使用 windows（VS上的 winform mfc.Borland的CBuilder等）或者linux的（如Qt)的人，都会对这个东西产生许多看法和想象。

我也如此，因为它启发了我很多东西——有些甚至超越了 人机界面 的范畴，而到了 多任务环境 等其他 软件中间件 语境里的问题。
同样的，每个人对它的理解也深深打上了他自己曾经实现，或者接触过的 那套系统。
我也是，比如我就深受我工作时用过的那套 屏-控件 二级目录系统 影响。

而我在脱离了所有原项目和设备的限制之后，只是综合此前的经验和想法，来重新设计的时候，我发现了许多不同点，许多可以更加高度抽象的东西。

所以，接下来在具体设计时，我会总结，整理 此前的那套环境 的特点 和 我之前的做法。
（之前一直没具体说，一则是避免做广告嫌疑，二则是因为工作内容，要写的话要做很多别的工作，比如不能直接使用工作的界面和代码，要自己重新抽取。）

辛昕

我进一步把接下来要做的事情 列了一张简单的清单：

1.借鉴、分析 现有的代码——尤以开源的为最佳；
2.自己原有项目的参考（这将是重点，毕竟这才是我的最稳重的起点）；
3.考虑这个手机界面，是否具有通用性？（比如可以推广到一般的工业设备？至少，首先能在理论上，用于我原有的工作项目，这是个最佳检验。）

辛昕

关于 借鉴和分析

我试着搜索了一下 雅虎，没什么发现还是和以前一样。
但是我忽然意识到，当然了，想要找到一整套的UI方案，不管开源不开源当然都是不容易的。
问题是，是否清楚自己要寻找什么？

因为我发现HMI，UI是一个相当复杂的东西，它涉及的东西非常多，可以做的很简练（但不意味着难看，人际友好性差。）
也可以做的非常炫酷，漂亮，所谓的 富UI；

而就我做下来的经验来说，它至少可以分三层

1.绘图层（已经包含具体驱动）
   这个绘图层提供了基本绘图动作，包括，画线，画块。

2.UI元素风格层
   所谓元素风格，指的是 这套界面使用的是什么 控件元素类型，以及它们的外观。而最重要的是，针对不一样的显示器件，它们有不同的表现力，所以，采用的 控件类型和外观都有可能不一样。
   所以这个层，在理想情况下，是一个总的外部接口，以及一个又一个针对具体器件，不同显示风格的 实现源模块；

3.界面设计
   这是最高层的设计；
   它关注的是 整套界面的基本风格，比如排布，颜色选择 之类的，在我看来，它最理想的情况是类似于一个CSS表（PS:对于CSS表，我的理解停留在几年前用DW做静态网页的水平，并不是太深入，接下去会考虑先看看，看是否有 方便的有价值的启发。）

   而在这之外，其实应该还有一层，只是此前我不知道它是否应该归入前面提到的 第三层，甚至第二层。
   
   这一层的重点是关注，如何组织用户的事件。
   当然，这个应该可以让用户根据自己的需求，自由自行定义，但就我维护的那个项目的经验来说，我看到一种相当混乱的混搭的风格：因为那套东西经过创建者，包括我在内的两个维护者 的过程，如今在我看来，它已经变得相当混乱，对于维护和改动，要掌握页面的跳转路径，特别是有时在路径中增加其他页面，路径，变得非常麻烦。
    当然还有许多隐约感觉到但还没系统整理出来的问题。
    所有者一些都让我觉得，如果可以 提供一种看起来不错的，至少划一规整的方式组织用户事件，至少可以作为一个不错的推荐方案，供使用者备选 也是很不错的。

由此，我觉得，对于第一项任务，其实暂时去搜索是没太大意义的。
我反而，忽然想起不久前我群里一个人上传的一套有些年月的，也是专门基于 一般终端设备的开发需求，作者也是专门去研究各种手机界面，并在其基础上，整理了一个相当完整的方案。

下面我先上传这个文档，过后再做一个简要分析。
我此前多多少少通览过这个文档，对其中一些内容也有一些感触，但当时我限于具体的问题以及不太清楚其实应该怎么划分一个UI功能的层次，所以我还是如以往，对其中的方案，批判的多，学习的少。
是时候改变这种 不善于学习他人 的习惯的时候了～～
一个占用内存极少的菜单系统的实现.pdf (1006.82 KB, 下载次数: 21)

2015-1-25 11:56 上传

点击文件名下载附件

辛昕

先确定一下自己想从中得到那方面的启发，这个也许会对接下来再次阅读这个实现，更加有针对性。

针对上面提到的三层 或者说 四层。

我首先最关注的一个是：
1.它是否有提到 如何组织用户事件；
其次，它也是基于黑白屏的，我想知道它选择了一套什么样的 UI元素；
当然，UI样式还是其次，最有价值的——这其实也是一般的UI实现中最有价值的部分：

它是如何组织起一整套UI界面，并把它们衔接起来的；

辛昕

参考pdf中的方案的一个初步总结：
1.首先，我发现，实质上他划分出来的三种 菜单类型 ，和我总结出来的四种，其实是一样的。
当然，这里面没必要是 “我的和他一样”还是“他的和我一样”，因为，反正我看过他的方案，另外就是一个很简单的理由：既然是做同一样东西，难免实现方案是类似的，毕竟他看到的手机我也看到过。
这个，没太大意思。

多出来的一个，是 提示框，那是我自己单独提取出来的，实质上也可以不提取，但是，无所谓了。我觉得还是可以区分的。

2.我和他最大的分歧，在于
如何控制 菜单周转。

我们都知道，手机上除了数字，井号啥的按键之外，起到控制周转作用的 其实只有五个键

上下左右 四个方向键 外加一个 确定键。这也就是所谓的 五向键。

因此，文档中的这种方案，针对此，对每个页面都给了五个函数指针，分别存储 这五种动作对应的操作。

然而，我的原有项目经验里，却不存在这种思路。
这是因为我发现，即使对于手机这种应用。

五个按键里，其实只有 左右 两个按键 对应的动作 有可能变化。
但是，上下，永远都是上翻。只是对应不同的 菜单类型，操作的不一样。
比如
对于 列表，也就是文档中提到的 条目层，上下是在移动到不同的 条目项；

而对于 文本输入框，也就是文档中提到的 动态内容层，它很可能就是移动输入的行数而已。

也就是说，无论如何，这两个键的功能都是固定的；

但左右就不一定了。
因为对应每个页面，它可能存在很多种不同操作

比如说 短信输入情况下 有可能是 “发送” “放弃”
比如说 电话本输入 “保存” “放弃”
比如说 拨号         “拨通” “重输”

很显然我们发现了，左右键是与具体的页面，逻辑有关的。
而上下键则相对单纯许多，虽然 略有不同，比如 上下条目移动 和 文本的上下行移动。
但毕竟，仍然只是 移动上下而已。

对于确定键 也是。
它在任何情况下都只是 选定/选择 的 语义而已。

所以在我过往的实现方案里，在这个地方，我是把这几个键当成 UI层可以直接处理 的 操作语义，而不需要和具体的函数绑定。

这样一来，我们就可以进一步简化 进一步的界面配置。

辛昕

对于 “事件的组织”  这个问题，其实已经可以从处理按键的方式看出来了。
他的方法和我的最大区别是：

我没有细分，而是把一些按键抽象。
对这个问题。

它其实应该单独抽取出来作为一个问题做理论分析（尽管并不复杂）。

这个问题就是：
       是否任何情况下，任何事件的操作都可以只通过 设置 左右键 的 功能 就可以实现？
——从我们经历过的手机来看，这个答案是非常确定的。

但问题没有这么简单。首先，手机只是手机，我们没有把握这种操作方式可以适用于任何操作设备，任何应用情形。
另外，从我原有项目的情况来看，按键操作之后，还要考虑，跳转到另一个画面，那么，这个问题就进一步变成了

是否一个操作如果只限定为 两个跳转页面，是否能满足所有的应用——更重要的是，这种跳转设置，实现起来是否足够方便。
特别是这种实现显然和我原有的实现方案肯定不一样，我必须推演一遍，这种新方案同样可以适应我原来的方案。

所有这一切，我想，我需要仔细梳理我原来的项目中的这些问题，这个问题就可以确定下来了，那就可以 开始 实现了。

当然，至于更加具体的实现过程和代码，我没有细看。
因为当前我仍然处在吸收设计理念的过程，而非到具体实现过程。

辛昕

洗澡的时候，我突然一下想明白了 我在TFT上实现那种UI 和 当前我基于12864的这种实现方案 差别这么大的一个根本原因

这是因为，在12864这种小的屏幕上，受限于它的大小，我们往往不可能在上面放置 许多 Button，这种情形迫使我们必须把整套界面设计成 通过 若干个键就可以完成所有操作的 人机操作系统。

但是，在大的屏幕上，特别是，出现了新的输入方式
比如其实对我们现在的人早已习以为常的 鼠标，还有相对来说要新颖的 触摸屏输入。

它们和上述的这种手机界面操作的 最根本区别就是

手机上的方向键 只能 上下左右移动，然而，有了鼠标 和 触摸屏，情况发生了质的变化
那就是，我们可以在屏幕上任意位置移动和做操作。
‘
这样做的好处是 相对于频繁的左右移动来说，用户的操作更加直观，便捷快速。

当然，这种情况下导致我们内部的一种实现机制，也相应发生了非常本质的区别。
我们不再可能仅仅通过两个左右键 或者，了不起把 上下左右确定 五向健都加进去 来确定某个按键输入该调用哪个函数去触发响应。

所以，在这种情况下，我们需要一种 新的绑定技术，就是把某个控件 和 一个特定的操作函数绑定在一起。
在Qt里这种技术被称为 信号槽。

实则，在Borland CBuilder 和 VS的Winform也是类似的技术，只是叫法不一样。
而到了我们单片机领域，我们实质上也是采取类似的方式。

只不过，在我们见到的现成模块里，它为了帮我们处理 UI这块的（部分）功能，它把 控件 和 触发函数分离了，，触发函数由我们在单片机程序里书写，而控件的设置，或通过 上位机界面设计，或通过一定的指令，脚本向屏内的设备输入来形成。

这个时候，我们面对的问题仅仅只是，如何把一个特定的控件和其对应的函数绑定在一起而已。

我见到的方案，就是 通过编号完成。

这个地方，我可以推荐一个链接。
再次说明，不是广告，只是我恰好用的就是这家的方案而已，当然这选择权也不在我手上，我只是维护这个项目。
以下是这家屏的官网链接

http://www.gz-dc.com/

与此类似的其实还有挺多。
比如一家早几年就听说过的 叫 北京迪文。以及 同样是在北京的 大器智成。
特别是 大器智成这家，其实我更喜欢他的实现方案，通过类似AT指令的 文本，它说那是 javascript，但我不懂这个东西，尽管真的语法很简单。

大家可以参考参考。

只是我基本可以确定，它们内部实现的方案，基本都是上述我所分析的这种方法。

辛昕

到了这个时候，我可以进一步总结
此前我原希望 把这两种方案 统一起来，但我最终发现，它们其实是两种完全不一样的实现，尽管也可以统一起来，但那样是没有太大意义的，与其如此，倒不如分开实现算了。

因此，此后我会继续就着这个 12864，这个手机DIY，继续不断细化设计方案，并最终实现出来。
但原来我打算把这个方案同样应用到 带触摸的TFT彩屏上 的想法也就打消了。

前面我反复强调，我在将近一年多的维护UI项目中，对UI产生了相当浓厚的兴趣，并且我希望自己总结经验，打造一套不一样的方案出来。
而这次的12864就是这样的一个尝试。

手机DIY已经变成了这个方案的第一次应用，我是一定会做完他的，哪怕，你已经看到了，它耗费了我不少时间和精力。
但彩屏上的方案，我暂时可能就不会考虑在12864之后继续了，因为我还有别的东西要弄

比如已经销声匿迹了很久的 Contiki。

另外，就是，这个帖子，我只会写到这里。
因为，剩下的是具体的 设计到具体实现方案，不再有讨论和分析过程，而只是当一个应用笔记写。
而那个将作为一个独立的 UI方案 出现，与 手机DIY不存在直接关系，所以另行开贴。

辛昕

最后就是，其实我特别想知道，对这个帖子感兴趣的人，看到这里是否有一些想法愿意和我分享呢？

还是说我这样的发帖方式是你们所不喜欢看到的。
我的本意是 尽可能描述我的观点和想法，你们就可以更清楚我的想法和观点，并期待你们的反馈和意见。

小硕硕

期待楼主继续更新。

whz

contiki 中有UI的实现，它是不是更成熟一些啊。

辛昕

没留意这个模块。
不过基本上我有了一套自己的套路，做在我自己的开源项目FreeUI里