cee1的梦、想

鸟老说我的文章大部分像在说天书。那么，好吧。这次就写点半天书的东西。

梦

不得不说，我有时候是理想主义者。所谓理想主义有时候是很残酷的，轻者类似洁癖，重者类似人类补完计划。不过，引用NERV副司令冬月的一句话——“我宁可生活在有人的地狱”（背景是与碇原堂在发生第二次冲击的南极，碇说这里连微生物也没有，是没有罪恶的世界了），即理想应与现实的交叉——所以我在理想主义者前加了“有时候”，所以这个部分的标题是“梦”——那朦朦胧胧地贯穿了人愿望的，而又会醒来的现象。

以下占位，等有心情了再写...哈哈

想

开源的运动，如同文艺复兴一般，其把那些“高深”的“技”、“术”变得透明，移除高科技的光环，从神坛上拉下，普遍地available。开源运动的意义不仅仅在聚集了“草根”开发软件，更重要的是展现了网络的力量，对传统教育进行了冲击，展现了教育的本质在于环境(context)。对于数字产品（网页、软件、文档、图片、音乐、游戏、电影...）的“绿色制造”（完全使用开源技术而非大众很难获得（包括经济上...）的闭源技术制造）也是有重要意义。值得注意的是，开源虽然始于软件，但是其波及范围已经远远超出了软件的范畴。举个例子说明如何其是从软件向其他领域扩充：硬件方面，受软件开源影响有开源的CPU（CPU设计电路开源），还有开放的计算资源（google和IBM的“云”项目），利用这些计算资源可以进行CPU非常繁重任务。以此为基础开源的思想的广泛在各个领域的传播。（PS：希望某鸟和某鱼将来工作上能用上我组装过的“工具”，实现绿色制造）

现代的(艺术般)制造，是一群人聚集在一起交流与表现其共同的理念与创意。开源运动降低了非相关因素的成本（现代制造离不开网络和计算机吧），使得人与人交流更加自由。（PPS：这个过程中，电脑和网络的功能越发被利用，人与人的交流完全通过虚拟电子电路来完成，这样黑客帝国中的虚拟现实情节就显的可行...为了避免这种情况（出于比如存在感,“存在”这个词貌似很多作品探讨，哪天有感觉了再展开），人与人也需要更多的现实（地理上）中交流，这就是上次和鸟交流的那个创意点子——围绕地理上人聚合来提供相关服务，弥补现代人心灵上的需要。

留言板

留言后可能不会立即显现，请耐心等待...

双屏电脑

特点：

• 正反两面双屏，触摸屏

• 屏幕大小如本本屏幕大小，比如14.1寸

• 两人面对面交谈（屏幕不是很大，不隔离两人）

用例：

当两人面对面讨论、协作时:

• 每人拥有各自屏幕及操作空间。相比两人并坐，两人不会互相影响

• 两人面对面直接对话交流

• 两人的视角相同

• 一方在屏幕指点画圈，另一方屏幕可显示出（多种显示模式）

鳥の詩

鸟の诗(tori no uta)

词：key

曲：折户伸治

编：高濑一矢

歌：Lia

kieru hikoukigumo bokutachi wa miokutta 消（き）える飞行机云（ひこうきぐも）　仆（ぼく）たちは见送（みお）った	目送消逝飞机云的我们
mabushikute nigeta itsu datte yowakute 眩（まぶ）しくて逃（み）げた　いつだって弱（よわ）くて	刺眼的云就这么逸出视线　渐行渐远（总是如此软弱）
ano hi kara kawarazu あの日（ひ）から変（か）わらず	从那日起不变的
itsu made mo kawarazuni irarenakatta koto いつまでも変（か）わらずにいられなかったこと	永远不变的　对逝去 的过去
kuyashikute yubi o hanasu 悔（くや）しくて指（ゆび）を离（はな）す	痛苦悔恨的放开手
ano tori wa mada umaku tobenai kedo あの鸟（とり）はまだうまく飞（と）べないけど	那只鸟虽 还不能飞得很好
itsu ka wa kaze o kitte shiru いつかは风（かぜ）を切（き）って知（し）る	但总有乘风而去的一天
todokanai basho ga mada tooku ni aru 届（とど）かない场所（ばしょ）がまだ远（とお）くにある	到不了的地方尚如此遥远
negai dake himete mitsumeteru 愿（ねが）いだけ秘（ひ）めて见（み）つめてる	便将愿望深藏　直视前方
kodomotachi wa natsu no senro aruku 子供（こども）たちは夏（なつ）の线路（せんろ）　歩（ある）く	孩子们　循着夏天的行迹
fuku kaze ni suashi o sarashite 吹（ふ）く风（かぜ）に素足（すあし）をさらして	在 风中　打(露)着赤脚
tooku ni wa osanakatta hibi o 远（とお）くには幼（おさな）かった日（ひ）びを	远处是　幼时的日子
ryoute ni wa tobidatsu kibou o 両手（りょうて）には飞（と）び立（だ）つ希望（きぼう）を	两手中　希望飞散
kieru hikoukigumo oikakete oikakete 消（き）える飞行机云（ひこうきぐも）　追（お）いかけて追（お）いかけて	不停追逐消失的飞机云
kono oka o koeta ano hi kara kawarazu itsu made mo この丘（おか）を越（こ）えたあの日（ひ）から変（か）わらず　いつまでも	从那时越过这小丘起　就从未变过
massugu ni bokutachi wa aru you ni 真（ま）っ直（す）ぐに仆（ぼく）たちはあるように	但很快的　我们终将同在　而能达到
watatsumi no you na tsuyosa o mamoreru yo kitto 海神（わたつみ）のような强（つよ）さを守（まも）れるよ　きっと	即使如海神般的坚强吧　一定的
ano sora o mawaru fuusha no hanetachi wa あの空（そら）を回（まわ）る风车（ふうしゃ）の羽根（はね）たちは	那空中回转的风车扇叶
itsu made mo onaji yume miru いつまでも同（おな）じ梦见（ゆめみ）る	总作着相同的梦
todokanai basho o zutto mitsumeteru 届（とど）かない场所（ばしょ）をずっと见（み）つめてる	望着到达不了的地方
negai o himeta tori no yume o 愿（ねが）いを秘（ひ）めた鸟（とり）の梦（ゆめ）を	只好将愿望深藏作著鸟之梦
furikaeru yaketa senro oou 振（ふ）り返（かえ）る灼（や）けた线路（せんろ）　覆（おお）う	回首是灼热的线路
nyuudougumo katachi o kaete mo 入道云（にゅうどうぐも）　形（かたち）を変（か）えても	即使笼罩的云　改变了形体
bokura wa oboete ite dou ka 仆（ぼく）らは覚（おぼ）えていて　どうか	我们总还记得
kisetsu ga nokoshita kinou o 季节（きせつ）が残（のこ）した昨日（きのう）を	残留季节的昨日
kieru hikoukigumo oikakete oikakete 消（き）える飞行机云（ひこうきぐも）　追（お）いかけて追（お）いかけて	不停追逐消失的飞机云
hayasugiru aizu futari waraidashiteru itsu made mo 早（はや）すぎる合図（あいず）　ふたり笑（わら）い出（だ）してるいつまでも	对过早的信号　两个人笑了出来
massugu ni manazashi wa aru you ni 真（ま）っ直（す）ぐに眼差（まなざ）しはあるように	很快的眼神交会
ase ga nijinde mo te o hanasanai yo zutto 汗（あせ）が渗（にじ）んでも手（て）を离（はな）さないよ　ずっと	即使渗出了汗也永远别离手啊
kieru hikoukigumo bokutachi wa miokutta 消（き）える飞行机云（ひこうきぐも）　仆（ぼく）たちは见送（みおく）った	目送消逝飞机云的我们
mabushikute nigeta itsu datte yowakute 眩（まぶ）しくて逃（に）げた　いつだって弱（よわ）くて	刺眼的云就这么逸出视线　渐行渐远（总是如此软弱）
ano hi kara kawarazu あの日（ひ）から変（か）わらず	从那日起不变的
itsu made mo kawarazuni irarenakatta koto いつまでも変（か）わらずにいられなかったこと	永远不变的　对逝去 的过去
kuyashikute yubi o hanasu 悔（くや）しくて指（ゆび）を离（はな）す	痛苦悔恨地放开手

青空AIR

青空 AIR

作词：Key

作曲：Key

编曲：折戸伸治

Vocal：Lia

Ano umi dokomademo aokatta tokumade あの海どこまでも青かった远くまで	那片海洋 蔚蓝的一片 直到远方
Ano michi dokomademo tsuzuiteta massuguni あの道どこまでも続いてたまっすぐに	那条小路 笔直地延续 没有尽头
Ichiban hayaku sunaoni warattamono gachi 一番早く素直に笑った者胜ち	还记得那次游戏 看谁会最先笑出声来
Ichiban sukina anohito waratteru 一番好きなあの人笑ってる	还记得最喜欢的那个人 开心的笑容
Dare yorimo toku e ittemo koko kara mata waratte kureru? 谁よりも远くにいってもここからまた笑ってくれる？	就算走得比谁都要遥远 他仍会在这里对我微笑吧？
Hitomi wo tojireba futto natsu no nioi 瞳を闭じればふっと夏の日の匂い	只要轻轻地闭上双眼 便会感到夏日阳光的气息
Ano kawa asonderu futari kiri doro darake あの川 游んでる ふたりきり泥だらけ	那条小河 嬉戏的两人 满身是泥
Ano kumo otteiru todoitara shiawase to あの云 追っている 届いたら幸せと	那朵云彩 只要能追上 就会幸福
Ichiban hayaku kono saka nobotta mono gachi 一番早くこの坂のぼった者胜ち	还记得那次游戏 看谁能最先跑到坡顶
Ichiban sukina ano basho mezashite 一番好きなあの场所目指して	还记得最喜欢的那处地方 我们一直向往
Takusan no omoide ga aru hoka niha nani mo iranai kurai たくさんの思い出がある 他にはなにもいらないぐらい	有着太多太多的回忆 不需要其它的任何东西
Hitomi wo tojireba sugu ano umi no nioi 瞳を闭じればすぐあの海の匂い	只要轻轻闭上双眼 就能够感到那片海洋的气息
Mata natsu ga kuru giniro ni hikaru また夏がくる 银色に光る	夏天还会再来 映照在银光闪闪的水面
Minamo ni utsusu futaribun no kage 水面に移すふたりぶんの影	两人的倒影
Dare yorimo toku he ittemo kokokara mata waratte kureru? 谁よりも远くにいってもここからまた笑ってくれる？	就算走得比谁都要遥远 他仍会在这里对我微笑吧？
Hitomi wo tojireba futto ano hi no aozora 瞳を闭じればふっとあの日の青空	只要轻轻地闭上双眼 便会感到那日蓝天的气息

最终兵器彼女Op & Ed

ASL (Adobe Source Libraries)总览

stlab.adobe.com

作者：

Sean Parent, Adobe Systems Incorporated

Mat Marcus, Adobe Systems Incorporated

Foster Brereton, Adobe Systems Incorporated

更新日期:

2004-12-6

2007-4-3

翻译：

cee1 (fykcee1@gmail.com) 2008-3-19

摘要

本文档总览 ASL (Adobe Source Libraries)。ASL的目标是开发通过用说明性的描述(declarative descriptions )，组合一般算法来构筑高级程序的技术。

ASL最开始的两个重要的库：属性模型库(Adam)和布局库(Eve)。它们负责在软件程序中模型化人机界面的外观和行为。

ASL是Adobe软件技术实验室(Adobe Software Technology Lab ：STLab)一个项目；一个通过提供更好的技术和教育来增加开发者的创作力和软件质量的研究小组。

Adobe Begin是一个用来表现这里提到的观点的简单程序。

个人前言（选译）

这是个开始...

这里是我准备发布Adobe Source Libraries时的想法。这里有些精妙的代码，我希望那些会擦出未来研究和开发的火花。

如果看软件产品的界面，很可能感觉是机械化的。给你的幻觉的是在直接操作底层模型：如果你按这里，你知道什么将会发生（或者什么应该发生）。如果你按那里，会发生另外的。

界面之下是一个非机械的系统。大部分的实现可以用“有机”来更好形容：乱糟糟一堆对象通过信使系统松散地互联。这个系统不是随机的，可以通过使用任意数量的、已很好建立的方法学来仔细设计它。

然而，这个系统的真实构架，是一个由个别数据和互联逻辑形成结构。软件由代数结构所定义。

这个主题在ASL中不断地在很多方面重现，包括：

• 值依赖的语义，而不是引用或者指针语义，作为控制联系的机制。

• 陈述算法的需求，通过语义概念而不是接口。

• 清晰化联系，使用明了的数据结构，在缺少继承的联系机制中引人注目。

这是个好的开始...

这些库被结合到Adobe的产品中，用简洁和简短陈述代替了成千上万行代码。Eve布局引擎节省了 Adobe地方化方面重要的人力资源。

最有“抱负”的库，Adam，源自一个直觉——简单人机界面背后的逻辑可以用一个函数精炼描述：

f (x) -> x'

提供这些功能的代码，占到Adobe代码基的1/3,并且是开发中几乎半数bugs的来源。显然，这些函数不是如此简单，至少不想上述表现的那样简单。其复杂度大约源自高度的互联变量。单靠事件处理代码，其没有足够的上下文来解决上述系统中的复杂问题。

...

属性模型库和布局库简介

属性名模型库包括求解器和用来描述一集合中值间的约束和关系的陈述语言，典型的，传给程序命令(一个函数)的参数。当用在人机界面时(human interfaces：HI)时，属性模型库提供了控制HI行为的逻辑。属性模型库在概念上和一个电子表格(spreadsheet)或者表单管理器(forms manager)类似。值被设置时依赖之的值被重新计算。属性模型库提供了解析互相联系的值的工具，但不是一个一般的约束系统。

布局库由求解器和用于构筑HI的陈述语言组成。布局求解器读取HI元素的丰富描述，来形成一个与手工布局相媲美的高质量的布局。对于跨多个操作系统平台和语言而言，单一HI描述就足够了。布局库被开发出来和属性模型库合用，但是也可单独使用。

这些库不构成一个传统的应用程序框架。它们是可以被融合到多个环境中的组件库。它们也可一起使用，或者独立使用，但必须和其他工具一起来构建一个应用程序。几乎所有构成属性模型和布局库的组件也可以独立被使用，并且作为ASL的一部分被文档化。

ASL用C++开发，并且大量的使用了Boost库<http://www.boost.org>，所以编译ASL需要boost。

布局库开发有三个目标和两个需求：

目标：

1. 更加容易地指定和修改HI布局。

2. 所有平台单一定义（跨平台）

3. 所有语言单一定义（国际化）

需求：

1. 必须满足片段能结合到应用程序中去。

2. 创建布局和手工布局的一样好或者更好。

实现目标三依赖于一个记号字符串系统。ASL提供了xstring库作为类似系统的一个例子，但是布局库不直接依赖任何字符串系统。

以下例子在本文档中通篇使用。这里用来给个第一印象。一个简单的对话框的布局描述如下:

layout clipping_path
{
view dialog(name: "Clipping Path")
{
   column(child_horizontal: align_fill)
   {
       popup(name: "Path:", bind: @path, items:
       [
           { name: "None", value: empty },
           { name: "Path 1", value: 1 },
           { name: "Path 2", value: 2 }
       ]);
       edit_number(name: "Flatness:", digits: 9, bind: @flatness);
   }
   button(name: "OK", default: true, bind: @result);
}
}

注意为了简洁，字符串以简化的方式显示。一般，一个记号字符串系统将被使用。

图一： 上面描述的Clipping Path对话框（在Mac OS X中）

虽然这个例子创建了一个静态的布局，布局库能也能在HI元素隐藏或显示时控制的元素放置，比如当窗口改变尺寸或者内容改变时。

在布局表述中的绑定属性（bind attributes），代表HI元素联接的对象——一个下层的模型。在此例中，模型是是一个传给函数的参数模型（推测起来，一个改变文档"clipping path"的函数）。属性模型库管理HI事件输入的参数间的约束和关系，并且把信息回填给控件来显示。

绑定属性的值引用属性模型中的一个单元。此例的属性模型被陈述为：

sheet clipping_path
{
output:
result                  <== { path: path, flatness: flatness };

interface:
unlink flatness : 0.0   <== (path == empty) ? 0.0 : flatness;
path            : 1;
}

绑定数字文字域到属性模型中的flatness单元，从而HI显示此单元中的值并且使得HI状态影响单元状态。字符域在”0.0”和上次用户输入值之间切换，而弹出菜单则在”None”和文档中可用路径之一切换。当”None”被选择，则文字域灰色不可用，因为flatness单元不能直接对结果产生影响；若此时文字域中输入数字（导致设置了绑定的flatness 单元的值）将对reslut无效故控制被禁用。

虽然模型中的改变在绑定的HI中反应，模型并不引用HI，是完全独立的。它能绑定到任意数量的可选界面，同一模型被用作脚本验证。模型也被用来脚本产生（记录）。

虽然这些库被开发出来解决Adobe产品的应用程序HI开发问题，也存在其他可用的技术。它们可被用于形成布局和逻辑，网页应用程序前端的开发，网页布局和逻辑，或者文档样式表布局。

我们也在努力应用文档模型来扩展这些库中的概念。

属性模型库的目标

属性模型库的目标是高尚的——部分是为了这个库能成功成为一个明显优异的应用程序构筑HI组件的方式。

减少构筑界面的劳力

询问几乎所有软件工程师，什么是他们最痛恨作的，答案将会是“构筑人机界面”。甚至引入布局库，工程师从大部分繁冗的工作中解放出来，构筑人机界面的工作量仍旧繁重。实际上，HI相关代码占了Adobe应用程序中实现某个特性总代码的近1/3。与框架代码形成鲜明对照，框架代码占了我们的应用程序大约1/10，故此项目潜在影响力非常明显。

属性模型库立意通过一种清晰格式，来模型化当前由复杂事件处理代码管理的部分。它同时也减少了冗余逻辑，合并通用逻辑来重用和共享。通过使用属性模型库，用描述来替代当前实现界面的一些必要代码，从而体积减少10倍，复杂度减少大约600倍。

增加界面实现的质量

正如上述，Adobe产品中的大部分代码用来管理HI，预计相应数量的bugs。但在现实中，HI相关的Bug不成比例地高。在Photoshop的20,000-bugs数据库中，抽样显示每500处bugs中一半和界面层相关，这也是属性模型库立足处。这些bug相对不严重，但仍对资源产生中重要影响。横向比较Adobe产品大约40%的bug本质上是“行为上的”。使用属性模型库以后，这些bug中的多数(在 Photoshop抽样中，20个有4个)不会发生。其他bugs，虽然他们仍旧发生，但可很简单地找出和修复或是通过设计更加贴近实现来完全剔除。

允许界面在产品间共享

Adobe应用程序从其他公司获得并且内部开发超过10年。随着时间流逝，平台改变，产品必须移植。结果造成了没有两个主要的应用程序基于同一应用程序框架开发。

我们的应用程序在套件合成和角色转变（从孤立的域到一个大工作流中的组件）过程中，对重要HI元素共享的需求不断增加。在某些领域中，诸如文件和财产（asset ）管理，文本，颜色，元数据，web优化和透明度，都期望与每个应用程序很好整合，并对应用程序通用。布局库已可从某种程度上实现界面布局共享。

由于应用程序的框架、对象模型不同，整合与代码共享显得困难。即使布局被共享，其后的实现不能被共享，但仍旧要满足良好整合。其结果是构成HI背后逻辑的代码在每个程序中用其各自控件和事件处理的模型来重复。造成代码和劳力大量重复。属性模型库试图合并那些逻辑，允许其在我们应用程序间与底层框架无关地轻松移动和定制。

把HI开发工作交给设计师

当前，用户界面设计师负责设计视觉预览，同时可能加些文字来对行为描述。这个工作是使用图形工具比如 Photoshop来绘制界面，添加注释来描述行为。然后设计交由工程师来编写布局和行为的代码。某些时候，设计的行为违背了底层命令的需求，工程师不得不再找设计师来解决之。只有设计由工程师完全实现后，重要的用户测试才能进行，通常需要工程师和设计师再来修正，再测试...这个过程重复多轮。

构筑在布局库上的可视化设计工具将使设计师来布局界面，保存为一种能直接被应用程序开发者使用的格式。这个工具再结合属性模型的支持，通过显露约束与保证设计师实验正确功能的界面，就能增进开发工程师和界面设计师的沟通。

了解属性模型库

Adobe专业应用程序设计遵循模型、视图、控制器(Model、view、controller：MVC)模式。模型代表正在被编辑的文档，视图代表了文档在窗口中的显示。控制器是用来修改文档命令的集合。这些命令遵照一种命令模式(参见Gamma, et. al. p. 233)，每个作用于文档的命令都是一个事务。

图二：应用程序中典型命令参数流动

我们大部分的应用程序遵循此图或者此模式的变种。这种模式下，来自预设或用户配置（preferences）或可能的脚本的信息，与目标文档的状态信息相结合。然后这些信息（部分可能由用户直接提供）被用来构筑传递给命令的参数。这个命令之后在文档上执行，如果此事务成功完成（可能由于资源不足或者用户取消操作而失败），命令的设置被送往脚本系统来记录和记录在用户配置（preferences）中。 灰色框是命令参数输入处（由用户输入并/或在处理前验证），同时也是属性模型库关注之处。

图三：Edit Text域依赖Popup的状态

上图展示了命令参数处理的部分过程。这是上面用过的clipping path例子的一个描述。信息从一组预设（通常是用户上次选择的）或者脚本读入到系统，并和来自当前文档状态的信息合并。这个信息被传给对话框建立代码（用来建立对话框的域和控制。控制通过某个恰当资源描述或用布局库格式化。）[****STOPPED HERE****]当界面中的控制被操作，事件产生，其他控制随之更新反应验证过的参数。最后，通常是在响应用户选择”OK”，来自HI域的信息被收集，进行最终验证，对话框拆除，参数送出指示处理。当没有对话框中的项没有“相互交谈”，行为可以被编码成附加到每个项上简单验证过滤器（比如，一个Text edit域上的过滤器只接受数字）。更加复杂的过滤器能处理简单区间内的值-或者组合一群HI元素为一标准簇（就像edit text域绑定导一个滑动条）。然而，即使有这些简化，脚本验证代码和散落于HI元素验证代码间仍有重复。需要定制的代码来设置，拆除和管理对话框的交互（在非常简单的情形下，交互可能完全由过滤器处理）

命令接口并不局限于模型化对话框。调色板( Palette）界面和直接操作也创建命令参数。属性模型库也能应用于这些情形中。

虽然这个”简单”的例子不足以说明，互联关系会迅速超过项的数目N，全相联时，有(N²-N)直接联系。一个对话框带来吓人的复杂度。例如，Photoshop6中的层特效对话框有超过250个元素。虽然元素间的互联会在某种程度上受限，最终的复杂度仍旧显著。一个图像尺寸的对话框只有一些元素但却是全相联的。带来几页的逻辑，尽管数次Photoshop发布中持续努力，仍旧成为一个不断的bug和bug修正的源泉。即使最仔细地编写，这些修正不断地创建其他缺陷。

所有基于事件系统的代码紧密和应用程序框架及应用程序文档模型绑定。这种紧耦合禁止代码在其他应用程序中重用。

模型化控制器

在更复杂的情形下（比如滑动条和Edit text域联系），导致三角循环依赖。进一步分析显示循环由于HI控制提供了两个功能——既输出显示又输入。通过逻辑上分离这两个功能，循环依赖被破坏。大部分事件句柄，脚本验证，设置和拆除中的逻辑现在压缩成单个”模型”。剩下就是一个HI控制扮演视图和控制器角色的传统的MVC模式。这在图四中描述。被模型化的是传给命令的参数。这个模型和绑定到它的HI独立，给予设计师改变布局和选择HI元素的巨大灵活性（而不需触动底层模型）

图四：Adam分隔了HI控件同时扮演的视图和控制器角色。

合并成单一逻辑减少了系统的复杂性（从 N²-N到N）。更多的，脚本验证和对话框验证的逻辑可以共享，因为只存在单一含系统状态的模型——之前单独的被编写现在可以被封装成应用在整个系统上的简单“规则”。比如，任一HI设计师告诉你，给出界面项当前状态时不产生影响，该界面元素视觉上应该禁用。在一个典型事件处理系统中，没有一种方式测定什么是有影响的，什么是无影响。借助Adam，这个规则可以在应用程序中一次表达而非在每个对其他元素启用状态有影响的元素中表达。

Adam模型系统在概念上类似一个传统的电子表格。单元格用文本标识符命名，而非组织成行/列布局，构成一个“电子表格”。一个“电子表格”类似C语言的结构体，不同的是数据成员（对应单元格）可以有表达式附加之（这样，当依赖成员被修改时，数据成员被再次计算）。依赖关系引擎是双向的，允许查询一个给定的状态如“哪些输入单元影响输出单元”。这类查询用来驱动控制器内的开启状态(如输入不能影响任何输出，附加在那个输入单元的控制器被禁用)。反向的依赖关系查询也被用来作不变量测试，使得引擎能报告哪个输入单元造成不变量违例，而不是报告发生了一次不变量违例。

Adam & Eve 构架

总览

图五：Adam和Eve的基本组件，以及它们的互联方式

两个主要的组件：解析器和引擎。Eve1有其（松散的）基于C的语法。Eve1的解析器和引擎合一，使得很难提供其他可选语法。对于Eve2和Adam，引擎彻底与解析器分开，通过提供解析器来支持其他语法。可选地提供一个格式化器来从Eve2 DOM和Adam表格直接创建。最明显的“其他语法”是XML，许多其他形式也可（HTML，经典Eve，CSS，JavaScript，Java Swing及平台资源）。

Adam表达语言(The Adam Expression Language：AEL)

AEL开发出来作为Adam和Eve2基本表达语言。其语法大量地从Eve1中借鉴（继续“C风格”）。基于XML的语言被考虑过，但由于其太冗长、不便阅读而最终被抛弃（即使依赖一个好的可视化编辑器，基于文本编辑仍是某些用户的偏爱）。然而，基于XML语言作为一种选择没有被完全抛弃。

AEL开始被设计为支持来回编辑(round-trip editing)和良好错误报告。新解析器是LL2的并有一个简单的词法分析器。注释被组织到语法中（而不是被词法分析器作为空格无视掉），从而支持可视化编辑器的来回编辑（round-trip editing）。

Adam

前面提过，Adam表格(sheet)类似C结构体。一个表格由单元格成员组成。单元格成员可以是这些类型： input, output, interface, logic, constant或 invariant

开头例子是一个表格指定(specification)：

sheet clipping_path
{
output:
result          <== { path: path, flatness: flatness };

interface:
unlink flatness : 0.0 <== (path == empty) ? 0.0 : flatness;
path            : 1;
}

[开放问题 1] invariant(不变量)是一个类型为布尔型的输出单元格。附加到一个invariant的句柄在invariant计算值为假时调用。句柄被提供给invariant的名字、invariant依赖的一些输入单元格。默认句柄抛出一个类型为adam::invariant_violation()的异常（不变量违例异常）。

为了理解Adam做到的，考虑以下语句：

unlink flatness : 0.0 <== (path == empty) ? 0.0 : flatness;

作为C++语句，上述语句意味着：

• 当执行时，计算path的输出，flatness输出赋值为0.0或flatness的输入

作为Adam语句，意味着：

• 一旦path的输出被修改，flatness输出赋值为0.0或flatness的输入

• 当path的输出不等empty，同时flatness的输入被修改，更新flatness的输出

更多的，进行了以下查询：

• 给出一个当前状态，哪些输入单元格对输出单元有效？

• 给出一个当前状态，flatness 输出依赖那些输入值？

• flatness的输出当前依赖哪些值？其中哪些最近更新？

与上述语句相关的行为：

• flatness的输出被修改，升级显示

• 设置和flatness的输入相联的edit text域的启用状态（根据flatness的输入是否影响任何输出值，当状态改变时更新）

表格中的语句相关度越高，Adam表达相对于传统事件模型更加有效。上面的语句代替了Photoshop 中一个57行（15个语句）函数。

表格的实例是一个写时复制（copy-on-write：COW）对象，从而支持事务操作。易于实现撤销，当出现不变量违例时重置或者返回。[注意：认真考虑下，COW也能在对话框内实现多次撤销]

[开放问题2]表格中的输入单元格可从字典类型载入，输出单元格可被提取为字典类型。这个功能可用来实现载入，保存，“收藏夹”和预设，也是绑定表格到应用程序的一种可行方式。

修改表格的输入单元格触发一次再计算过程（可通过设置一个复杂的状态来避免）。依赖此改变值的任何单元格被再次计算。如果此过程中一个不可变单元格计算后返假(false)，则抛出异常（含违例的invariant名，及其他触发此违例的单元格）。[注意：提供不变量依赖的所有输入单元格是有用的。提出“弱不变量”(“weak invariant”)的概念也是有意义的——停止传播并导致任何更多的依赖输出单元格到无效状态。需更多经验来看到底需要什么。]

逻辑单元格(Logic cells)用来作中间计算，其状态既不可被读也不可由表格之外设置。

接口单元格(Interface cells)用作输入和输出。通常，接口单元的输入和输出值相互同步。可以在接口单元格前加"unlink"关键字，来阻止输出值不向后传播给输入值。

[开放问题3][开放问题4]界面有时依赖”最近发生的”这个概念。例如尺寸可变对话框中的一个显示“宽度”Edit text域，可能要么显示用户输入的宽度值，要么显示用户改变高度时（译者：锁定宽高比改变尺寸？）计算的值。为了支持这个概念，Adam维持一个随着每次再计算而不断增加的创建计数(generation count)。在再计算时，修改单元格同时打上创建计数戳。

虚拟机

虚拟机是一个用来计算表达式的简单的栈机器。一个表达式归约成一个代码序列（每个代码代表一个值或操作数）。值被压入，操作数应用到栈顶的值上，压入结果。一个中缀表达式能通过重载操作符从序列中再构成。这对来回编辑（roundtrip editing）有用。概念上，AVM（Adam 虚拟机）类似FORTH或者PostScript语言并支持压入一串代码序列为一个值。

在Adam中，依赖关系通过执行语句时监视单元格查找来追踪。查找在实际执行时被延后。简化的布尔量和条件操作符把表达式作为参数，故被标记为依赖某个表达式的单元格实际上依赖表格的当前状态。

[开放问题5]也许需要延后计算（知道函数请求计算）传给函数的参数。虽然可能让作用域规则更加复杂，但允许函数编写时，有条件地使用其参数，从而便于跟踪依赖关系。

绑定

Eve2的关键特性之一就是绑定HI元素到Adam表格的某单元。绑定通过各种绑定属性(bind attribute)来实现。绑定属性的值是Adam单元格的名字(name，译者是一种AEL的类型)例如：

check_box(name: "Check this", bind: @check_this);

名字也可用来绑定其他属性（译者：而非绑定属性）到表格。例如：如上例check box的名字可由用户设置，如下编写：

check_box(name: @user_name, bind: @check_this);

指导(Guides)

指导（Guides）是Eve1中label_width和 top_inset属性概称。在Eve2，指导能处理跨层次的联系，允许n列对齐和基线（baseline）对齐。很多地方，指导是自动的，对用户不可见（由客户端代码设置，由引擎计算）。[注意：当前存在一个找到和谐的指导的好算法。该算法对位置计算不成熟，但初步实现应该能达到“比Eve1更好”的目标]

动态计算

改变视图尺寸（或由于用户拖动边界，或响应内容/状态改变）,极为类似带有附加约束条件（比如视图的最小尺寸）地布局视图中的内容。Eve1开发后，认识到它也能用来控制改变尺寸逻辑。唯一的问题是Eve引擎和解析器混杂在一起，故不能某次程序改变后不能调整布局。Eve2分清了结构，提供了调整属性和强制布局再计算API。

外边区(Outsets)和容器几何

在Eve1 外边区(Outsets)被用来保证有足够的空间来绘制阴影、默认高亮、和操作系统控制的“溢出”。一些工作成果：根据外边区来调整尺寸和项的位置。然而这个逻辑当前是有缺陷，会导致不合适的外边区以及项不合适放置和尺寸。修正这个缺陷，尤其是还要配合指导，将会给引擎带来巨大的复杂性。然而恰当地使用，外边区应该不会影响项的位置和尺寸，但给对话框外观带来视觉上的瑕疵。更多的，outsets被用来让空白（如留白(margin)或项之间的控件）“吸收”。Eve2正确地在布局之后的后处理（post-pass ）中应用外边区。如果尺寸和位置的调整是必要的，一个诊断信息会被输出，但布局不被改变。

Eve1也没有容器边框的视觉几何的概念；边框的留白调整为包含边框。Eve2增加了边框和内边区(inset)(与Eve1的inset的概念不同，Eve1的inset成为缩进(indent)更合适)的概念。客户端代码得益于此，能够容易地指定容器的几何（代码设置一个固定的边框宽度而不再是添加边框到留白中），并能在后处理中更好的侦测不合适的重叠。

库的整合

ASL的与客户端代码整合相当直观。因为ASL不依赖继承整合到客户端代码中，整合过程不过是添加支持代码而非转换已有代码。图6绘制了一种可能的整合ASL到客户端代码的方式。

图6：ASL代码整合和客户端支持代码

ASL代码与客户端代码存在清晰的边界，支持代码用来绑定ASL和客户端。橙色框部分是客户端需要实现的。绿色框由ASL提供，蓝色框由代表操作系统例程。

这个处理过程起始于Adam和Eve界面(比如对话框)描述定义。客户端提供读取这些定义的代码，把它们送给Adam和Eve的解析器。解析器应该和其他一套另一边外的支持代码互动，发出合适的信息给Adam和Eve。也要注意到，解析器到引擎支持代码可能与控件集支持，代码互动（在初始控制、窗口和类似的）。Adam和Eve在它们提供的数据上执行，把结果输出给控件集支持代码。代码将转换来自两个引擎数据和参数为操作系统可用的信息。与操作系统相关的部分应该在客户端支持代码中实现。当OS调用带着通过事件和数据返回到客户端，客户端支持代码将会把合适的信息发回给Adam和Eve。Adam和Eve将升级必要的参数，并向客户端支持代码发送通知（回送重要的信息给OS，比如新的控件值）。这个OS/客户端/ASL/客户端/OS周期随着用户与界面互动不断重复，也是整合了Adam与Eve的“事件循环”(“event loop”)模型。

大部分客户端整合代码非常简单。最复杂的代码片段是控件支持代码集（作为Adam和Eve，他们相应的解析器以及OS一起的回调函数)。某个给定例程的代码通常只做过滤和翻译数据，再把数据路由到合适的目的地。客户端代码最复杂的处理过程应该在此模型之外。毕竟，这个代码是处理过程中构建参数的方式；这个处理过程应该与此代码无关。

附录——其他开放问题

当前Adam类型不严格。可能需要申明单元格强制为某类型。如果这样做，一个限定词“optional”将被添加来指示域也可以含”empty”。

研究XForms。结构化表格和表格融合。

附录——语法

此文档的语法用EBNF（扩展巴克斯范式表达 Extended Backus-Naur Form）记号。EBNF在ISO-14977标准中定义。可从ANSI网站花$38.00获取（PDF）。最终文档草案免费在线获取。

目前前有四个语法。在下文件中可获得：

• Adam语言参考

• Eve语言参考

• 表达式参考（描述词法和表达式语法）

附录——未来的点子

可视化编辑器

布局库和属性模型库的可视化编辑器将成为ASL的巨大补充（Begin例子程序正在这个方向上进化）。最终，它将有两个编辑视图（大纲和预览），但预览窗口也支持直接操作。也许提供源代码视图（ala GoLive）。

一些简化跨平台预览的支持将被提供。组合入的属性模型库将提供活跃仿真。

记号字符串系统能分离应用程序中需要地区化的（译者：比如为中文用户显示中文字符串记号）。然而，剩下的一个主要问题是测定字符串的上下文来作合适的翻译。提供这个上下文信息是编辑器的目标（以“查找字符串...”命令形式）。从而能够在HI中放入合适的字符串。在验证信息情形下，HI在带有触发信息的属性模型规则的上下文中显示。

Eve2考虑中的特性

一个直接操作Eve层次结构的API对于动态视图有用。绑定某值到视图中节点允许某些简单地直接设置值——但不允许对结构操作。Eve层次结构的Xpath接口应该是一个待添加的有用特性。

布局的最大尺寸限制将对调色板非常有用。当前可以设置一个有些用的最小尺寸但需要为地区化进行手动检查和调整。一个最小的解决方案是：当尺寸约束违反时，允许一个可选的视图定义。其他选择是优雅退化布局（打破指导链接，格式化选项）来强制一个对话框来适合。组合这两者很可能移除大部地区化的工作量。

Eve前一实验版可以为单词绕回文本调整布局。这个实现起来相当直观，很可能会包含在Eve2的发布中。

直接指定菜单项在Eve1中办不到（数据集不够丰富，不允许定制容器布局）。在Eve2中，客户端有多种方式支持此特性。

当前Adobe应用程序，正在允许应用程序层上自定义热键。如此特性扩展到对话框，也许需要Eve或记号字符串系统支持之。然而此时，没有如何实现这样特性的建议。

X windows图形系统——现在和将来

X导航(一些笔记)

这些笔记来自O'Reilly出版的《The Definitive Guides to the X Window Systems, Vol 1 - Xlib Programming Manual》, 1992年第三版 (By Laxxuss)

Xserver的职责

• 允许多个客户端访问显示资源(display = screen + mouse + keyboard)

• 解释来自客户端的网络消息

• 把用户的输入通过网络消息传给客户端

• 二维绘制

• 维护一些数据结构 (windows, cursors, fonts, 图形相关上下文Graphics Context——客户端通过资源ID来共享前述资源)

一般客户端的职责

响应相应的事件(输入事件、与其他程序的交互事件)

特殊客户端——窗口管理器的职责

管理有限的UI资源(显示(display)、屏幕空间、颜色表)

• 屏幕上窗口的布局（用户请求(hint) + 窗口布局政策）

• 移动窗口和改变窗口的大小

• 控制屏幕上的窗口栈

X协议分类

• 请求：xlib->server (e.g.绘制线、查询窗口大小、改变颜色表中的某个单元的颜色)。大多数Xlib例程产生请求（除了如Regions和资源管理）。

• 响应：server->xlib，响应相关请求。需要获得响应的xlib例程发出的请求被称为round−trip(往返) request（对性能造成影响）。

• 事件：server->xlib，在xlib中事件保存为队列。客户指定服务器送来事件的范围。

• 错误：server->xlib，通知客户端前一请求是无效，类似事件，但是由Xlib指定的句柄处理（默认是打印错误消息）。

Xlib的覆盖面

• 颜色管理：绘制用的颜色模式(解释)之间的切换

• 指针管理(Cursors)：鼠标图样的改变

• 数据管理：数据和窗口或者数字联系的机制

• 显示(Display)的连接：（通过网络）程序连接/断开一个显示(Display)

• 获取显示(Display)和服务端相关信息：提供服务端的实现和其相连的显示(Display) 的信息

• 绘图：绘制/填充点、线、矩形、多边形和弧的函数

• 错误处理只有keyboard和mouse事件传播。事件掩码是每个客户端独有：一些挂接错误处理句柄的函数

• 事件处理：获取来自用户、其他程序、服务端的事件

• 扩展：获知服务端的扩展以及这些扩展的用法

• 字体：列出可用的字体、载入字体以及找出其相应的字符

• 几何：操作和转换几何相关的

• 图形上下文：设置对绘制请求的解释(绘制的方式，如填充还是勾画、线的形状...)

• 对主机访问的控制：控制来自网络其他机器对服务端的访问

• 图像：获取/显示/操纵屏幕图像

• 客户端之间的通信：

• 国际化：独立于语言的输入和文本渲染处理函数

• 键盘：改变键盘输入处理方式（包括键盘映射）

• 指针设备（鼠标）:改变指针输入处理方式

• 区域(Regions)操作：对多边形区域(Region)作数学操作

• 资源管理：方便管理用户设置和命令行参数

• 屏幕保护：设置屏幕保护期间显示的内容

• 文本：渲染文本和相关文本渲染的几何信息（大小...)

• 用户设置：设置/获取键盘连击相关设置

• 窗口属性(Attribute)：获取/设置窗口的当前特质（属性)

• 窗口生命周期：窗口创建和消亡的函数

• 窗口管理：在屏幕上操作窗口——改变大小、可见性、窗口栈

Xlib清空请求队列（到server端）的时机

1. 调用需要立即响应的函数（名中含Query、Fetch、Get的例程）

2. 调用读取某个事件的例程，而此时队列中没有匹配事件

3. 调用XFlush、XSync ()

属性(property)

• 一个和窗口相联的信息包（用于客户端之间的交流），含有一个字符串名和数字ID(atom)

• 窗口管理器(windows manager)和客户端的大部分通信通过窗口属性（其余通过事件）

窗口的特性

• 父窗口——每个窗口在创建时就指定了父窗口(root窗口——无父窗口，Xserver启动时创建，覆盖整个屏幕)

• 窗口配置(configure)包括：

1. 不计边框的窗口高度和宽度(以像素计)

1. 窗口的边框(宽度可变，0代表边框不可见)

2. 窗口相对的位置(不计边框)

3. 同一父窗口的窗口间，栈中的顺序

• 窗口的几何特性——窗口配置的中窗口的高度、宽度和窗口的位置

• depth & visual：depth——像素值的位数，visual——像素值如何转换成输出颜色

• 窗口的类别：

  1. 输入输出

  2. 仅输入(透明无边界，不能有输入输出类别的窗口作为子窗口,常用来改变鼠标外形)

• 窗口的一组属性(Attributes)：

  1. 窗口边界和背景使用的颜色或者模式(Pattern)

  2. 改变窗口大小时窗口内其他内容的重定位

  3. 窗口内容何时自动保存？(当窗口被覆盖之后又“曝光”(exposure))

  4. 接收哪些事件，哪些事件不向祖先窗口提交？

  5. 是否允许不通知窗口管理器来显示、移动、改变本窗口大小

  6. 使用哪种颜色表来解释像素值

  7. 鼠标在此窗口中时应该如何显示

窗口的层次

• 每个屏幕(screen)对应一个root window(撑满整个屏幕)

• root window的直接子window成为顶级(toplevel)窗口，由窗口管理器所管理

• toplevel窗口的子窗口可用作实现比如按钮，滚动条之类¹

• 子窗口可以部分或全部置于父窗口之外，但是子窗口只能向其和父窗口交集区域输出/获取输入

• 子窗口总是在父窗口的上面

窗口的映射

窗口必须被映射——通过 XmapWindow()（或其他相关例程：XMapSubwindows()），窗口符合以下几点才可见：只有keyboard和mouse事件传播。事件掩码是每个客户端独有

1. 该窗口的所有祖先窗口被映射

2. 不能被其他可见的兄弟窗口或者祖先的兄弟窗口覆盖(通过XCirculateSubwindows(), XConfigureWindow(), 和 XrestackWindows()调整栈中的顺序)

3. 相应的请求缓冲被清空（到server）

4. 顶级窗口的初次映射是个特例——因为需要窗口管理器“领养"之。更复杂的情形：客户必须等待一个“曝光”事件窗口才可见

图形上下文的三个方面

1. 位掩码(plane mask)

2. 剪切掩码(clip mask)

3. 逻辑函数

可绘对象(drawable: window & pixmap)

三类错误事件(Error Event)

1. 检查返回值来侦测错误和进行相应处理(修改请求的参数再试)，比如检测XOpenDisplay()成功否

2. 协议错误——编程失误引起，由XErrorHandler处理(例外：对于返回状态代码过程的则通过检测状态代码来处理)，通过XSetErrorHandler ()添加一个自定义的句柄

3. 致命系统错误——(X服务器崩溃、网络失败...)，由XIOErrorHandler处理，通过XSetIOErrorHandler ()添加一个自定义的句柄

错误事件结构体 (错误发生时刻的相关上下文环境)

错误事件只发给XErrorHandler处理

int type;

Display *display; /* 发生错误的Display */

XID resourceid; /* 资源ID */

unsigned long serial; /* 失败请求的序列号 */

unsigned char error_code; /* 错误代码 */

unsigned char request_code; /* 失败请求的主操作码 */

unsigned char minor_code; /* 指示扩展，若此请求不使用扩展为0 */

其中error_code可由XGetErrorText()或XGetErrorDatabaseText()来解读

GUI设计中的三要素

1. 窗口的层次关系

2. 选择需要处理的事件

3. 事件处理(主要是简单的键盘和鼠标事件)

编写一个X程序的四个步骤

1. 连接到X服务端(即选择显示(display)，因为一个X服务端对应一个显示(display))

2. 客户端之间的通信(和窗口管理器协作)

3. 处理曝光事件

4. 处理改变窗口大小事件(改变给定窗口中子窗口及其他图形内容的尺寸和位置)

创建X程序的一般过程

1. 向X server创建一个连接，失败退出

2. 获取物理屏幕的信息，从而计算窗口大小

3. 创建窗口

4. 设置合适的属性(properties)，从而和窗口管理器通信

5. 选择关注的事件

6. 载入字体，用来打印文字

7. 创建一个图形上下文(GC)，来控制绘图请求的行为

8. 通过映射窗口来显示之

9. 循环处理事件

10. 响应曝光(expose)事件,调用相应例程来绘制图形和文字

11. 获取配置更改通知(ConfigureNotify)事件，其新的大小信息在事件结构体中

12. 响应其他事件

13. 退出——释放相关资源，关闭显示并退出

14. 其他需要的步骤：

    1. 从配置文件/命令行参数获取用户自定义信息

    2. 处理颜色

一个简单的X程序(模板)

//Xlib include files

#include <X11/Xlib.h>

#include <X11/Xutil.h>

#include <X11/Xos.h>

#include <X11/Xatom.h>

#include <stdio.h>

//Bitmap data for icon

#include "bitmaps/icon_bitmap"

#define BITMAPDEPTH 1

//布尔值，window足够大么->否则显示一条合适的信息

#define TOO_SMALL 0

#define BIG_ENOUGH 1

//这两个参数是几乎所有Xlib例程都需要的，故申明为全局比较简单;如果有其他源文件，这两个变量需要申明为'extern'

Display *display; /* 关于服务端及其屏幕的信息的结构体，仅由XOpenDisplay ()填充 */

int screen_num;

static char *progname;

void load_font (XFontStruct **);

/* ... */

void main (int argc, char **argv)

{

Window win; /* Window ID，其值由XCreateWindow ()或者XCreateSimpleWindow ()例程返回 */

unsigned int width, height; /* Window size */

int x = 0, y = 0; /* Window position */

unsigned int border_width = 4; /* Border four pixels wide */

unsigned int display_width, display_height;

Pixmap icon_pixmap; /* 位图资源ID */

char *display_name = NULL; /* Server to connect to,为NULL则由环境变量DISPLAY指示，格式：host:server.screen */

Screen *screen_ptr;

progname = argv[0];

//连接到服务器

if ((display = XOpenDisplay(display_name)) == NULL) {

(void) fprintf(stderr, "%s: cannot connect to X server %sn",progname, XDisplayName (display_name));

exit( −1 );

}

screen_num = DefaultScreen (display); /* screen_num允许的值0 ~ ScreenCount (display) - 1 */

screen_ptr = DefaultScreenOfDisplay (display);

//获取窗口信息

unsigned int display_width = DisplayWidth (display, screen_num);

unsigned int display_height = DisplayHeight(display, screen_num);

//创建窗口

width = display_width/3, height = display_height/4;

win = XCreateSimpleWindow (display, RootWindow (display, screen_num),

x, y, width, height, border_width,

BlackPixel (display, screen_num) /* border pixel value */,

WhitePixel (display, screen_num) /* background pixel value */);

//窗口栏上的图标

#define icon_bitmap_width 20

#define icon_bitmap_height 20

static char icon_bitmap_bits[] = {

0x60, 0x00, 0x01, 0xb0, 0x00, 0x07, 0x0c, 0x03, 0x00, 0x04, 0x04, 0x00,

0xc2, 0x18, 0x00, 0x03, 0x30, 0x00, 0x01, 0x60, 0x00, 0xf1, 0xdf, 0x00,

0xc1, 0xf0, 0x01, 0x82, 0x01, 0x00, 0x02, 0x03, 0x00, 0x02, 0x0c, 0x00,

0x02, 0x38, 0x00, 0x04, 0x60, 0x00, 0x04, 0xe0, 0x00, 0x04, 0x38, 0x00,

0x84, 0x06, 0x00, 0x14, 0x14, 0x00, 0x0c, 0x34, 0x00, 0x00, 0x00, 0x00};

icon_pixmap = XCreateBitmapFromData (display, win, icon_bitmap_bits,

icon_bitmap_width, icon_bitmap_height);

//和窗口管理器通信

char *window_name = "Basic Window Program";

char *icon_name = "basicwin";

XWMHints *wm_hints;

XClassHint *class_hints;

XTextProperty windowName, iconName;

XSizeHints *size_hints; /* 结构体：告诉window管理器顶级窗口最佳大小及大小增量 */

if (!(size_hints = XAllocSizeHints ())) {

fprintf (stderr, "%s: failure allocating memory", progname);

exit (0);

}

if (!(wm_hints = XAllocWMHints ())) {

fprintf(stderr, "%s: failure allocating memory", progname);

exit(0);

}

if (!(class_hints = XAllocClassHint ())) {

fprintf(stderr, "%s: failure allocating memory", progname);

exit (0);

}

//优先级：user(USPosition | USSize) > 窗口管理器 > 应用程序

size_hints−>flags = PPosition | PSize | PMinSize;

size_hints−>min_width = 300;

size_hints−>min_height = 200;

//设置XTextProperty结构体

if (XStringListToTextProperty (&window_name, 1, &windowName) == 0) {

fprintf (stderr, "%s: structure allocation for windowName failed.n", progname);

exit (-1);

}

if (XStringListToTextProperty (&icon_name, 1, &iconName) == 0) {

fprintf (stderr, "%s: structure allocation for iconName failed.n", progname);

exit (-1);

}

//程序是否在窗口第一次映射时显示一个图标/或者是正常的显示

wm_hints−>initial_state = NormalState;

//程序需要键盘输入么

wm_hints−>input = True;

wm_hints−>icon_pixmap = icon_pixmap;

wm_hints−>flags = StateHint | IconPixmapHint | InputHint;

//以下提供给窗口管理器关于本程序的信息

class_hints−>res_name = progname;

class_hints−>res_class = "Basicwin";

XSetWMProperties(display, win, &windowName, &iconName,

argv, argc, size_hints, wm_hints, class_hints);

//选择需要接受的事件， StructureNotifyMask相当于选择了CirculateNotify、ConfigureNotify、DestroyNotify、GravityNotify、MapNotify、ReparentNotify和UnmapNotify

XSelectInput (display, win,

ExposureMask | KeyPressMask | ButtonPressMask | StructureNotifyMask);

//创建服务器资源(至此，已经创建了一个window和icon pixmap两个资源

GC gc; /* ID of graphics context */

XFontStruct *font_info; /* Structure containing font information */

/* load_font：载入一个字体资源 */

load_font (&font_info);

/* get_GC：创建一个图形上下完资源(用来绘制字体和图形) */

//映射窗口

XMapWindow(display, win);

//清空请求缓冲->如果需要周期性绘制则需要调用XFlush ()

//建立起事件处理循环

XEvent report; /* Structure for event information */

int window_size = BIG_ENOUGH;

while (1) {

XNextEvent (display, &report);

switch (report.type) {

case Expose:

//绘制窗口优化：如非连续的Expose事件中最后一个，则不处理之/是否确定最小绘制区

if (report.xexpose.count != 0) break;

if (window_size == TOO_SMALL) TooSmall(win, gc, font_info);

else {

place_text(win, gc, font_info, width, height);

place_graphics(win, gc, width, height);

}

break;

case ConfigureNotify:

//处理窗口大小改变事件

width = report.xconfigure.width;

height = report.xconfigure.height;

if ((width < size_hints−>min_width) || (height < size_hints−>min_height))

window_size = TOO_SMALL;

else

window_size = BIG_ENOUGH;

break;

case ButtonPress:

case KeyPress:

//离开程序

XUnloadFont(display, font_info−>fid);

XFreeGC(display, gc);

XCloseDisplay(display);

exit(1);

default:

break;

}

}

}

void load_font (XFontStruct **font_info)

{

char *fontname = "9x15";

if ((*font_info = XLoadQueryFont(display,fontname)) == NULL) {

(void) fprintf( stderr, "Basic: Cannot open 9x15 fontn");

exit( −1 );

}

}

/* ... */

Some Tips

• X服务器不会自动维护窗口中可见内容，对一个不可见或者没有映射的窗口进行图形操作没有效果。当窗口被覆盖之后曝光，可见内容就会丢弃。通过指定"后台支持"(backing store，开销较大)，或者重绘来维持窗口内容。只有keyboard和mouse事件传播。事件掩码是每个客户端独有

• 只有keyboard和mouse相关事件（沿着窗口层次向上）传播。事件掩码是每个客户端独有。

Q & A

• 为什么GUI的基元是窗口？

  为了提高屏幕的利用虑，把屏幕划分为窗口来使用，故而

• 窗口属于谁？

  窗口是全局的，通过窗口的ID可以引用窗口，故窗口不是特定地属于某个客户端

• 事件如何被分发处理？

  服务端：X发送相关事件给在窗口的事件掩码中有标记的客户端，对键盘和鼠标相关事件可能还要向其父窗口传递

  客户端：通过某ID窗口的事件掩码选择关心的事件，从事件队列中获取事件分发到合适的代码中来处理

  事件的结构体中的两个最主要成员：1)事件发生的窗口 2)事件类型

一些详细的规范(PDF下载)

原书 ( The Definitive Guides to the X Window Systems, Vol 1 - Xlib Programming Manual)第三版

Xlib手册 (X Version 11, Release 6.9/7.0)

ICCCM (Inter-Client Communication Conventions Manual) v2.1

X协议 (X Version 11, Release 6.7 DRAFT)

X会话管理库 (X Session Management Library) v1.0

X各个部分简介(PDF下载)

• X窗口协议及构架

• X 窗口系统核心协议

• 窗口管理器

• X显示管理器(X display manager)

• X会话管理器

• X 选择模型

• X焦点模型 (网页)

• X11颜色命名规范

X的未来

XGL

The State of Linux Graphics (Jon Smirl)(PDF)

XGL (PDF)

EGL（位于窗口系统和OpenGL ES/OpenVG等的一层）

1. 提供创建可供客户APIs绘制和共享的渲染表面(windows,pbuffers,pixmaps)的机制

2. 为客户端API提供创建和管理图形上下文(Graphics contexts)的方法

3. 提供同步客户端API和平台原生渲染API的方式

OpenGL家族(www.khronos.org)

GL 3草案

OpenGL ES

OpenVG

硬件加速矢量绘图接口(Flash、svg...)

新闻：OpenVG加速webkit渲染

开源实现：shivaVG

OpenVG vs cairo：

1. OpenVG不支持字体或者文本渲染

2. OpenVG可以成为cairo的一个后端

3. OpenVG更像硬件的抽象状态机（更底层）

OpenMAX

1. 硬件加速的全面的流媒体编码器

2. 程序的可移植性

开源实现：Bellagio(整合层)

OpenMAX vs gstreamer:

1. 通过OpenMAX 的IL（整合）层可以被gstreamer整合

2. OpenMAX的AL（应用）层和gstreamer竞争。

glFX

运行时刻的特效框架。（特效由COLLADA FX格式所描述）

COLLADA

基于XML，3D内容交换规范

新的驱动

当前DRM的内存管理 (PDF)

新的内存管理模型

Gallium(镓)3D驱动模型 （odp演示文件）

新闻：mesa的采用Gallium驱动模型的cell平台驱动（The Mesa Cell driver is part of the Gallium3D architecture. Tungsten Graphics is leading the project. Two phases are planned. First, to implement the framework for parallel rasterization using the Cell SPEs, including texture mapping. Second, to implement a full-featured OpenGL driver with support for GLSL, etc. ）

讨论：X真的优秀么？

X作太多工作（人机外设的管理(DISPLAY)、绘制及相应数据管理、事件分发）？

主要是现代的绘制工作已经太复杂了，X继续支持绘制工作和已有的OpenGL之流冗余，而且也做不好。

X并没有很好划分Client-Server？

将获取的事件发给客户端处理，有以下几个缺点(看上去有点像AJAX于传统动态网页技术的PK):

• 受到网络延时的影响，使得程序响应度下降

• 事件（服务端）和事件处理的句柄（客户端）在X所处的层次上属于紧耦合，当前的划分对性能(包括网络传输)和模块化不利

• 界面逻辑分布在服务端和客户端之间（某种意义上，不符合界面和程序核分离的原则）

YY（无责任灌水）

X不受欢迎？

• Android平台未见X？

• Max OS X平台X不是原生图形化解决方案？

当前Linux下的GUI除了编写上的困难（包括跨环境），其他还有一些缺点：

• 安全性，例如

  • 焦点安全（依赖窗口管理器）（例如在用户输入敏感数据(如密码)时，一个突然弹出的窗口可能获取当前用户的焦点而导致用户敏感数据外泄（如果用户不十分小心）

  • 对事件源和路径的认证和控制（比如区分用户触发的事件和程序制造的事件，从而确保用户界面用户的意图）

  • ...

• 使用性，例如用户在顶级窗口之间的操作（回想GIMP...）

思路：

• 类基于富功能web浏览器的桌面环境（提供界面服务器而非XServer）

• UI操作的模式(类比启发)

交互系统由硬件——软件——用户构成

硬件(CPU等)	用户
执行线(CPU的执行入口，i.e. CPU的核2)	鼠标指针数3
进程	窗口4(工作流程)
当前进程	获得焦点的窗口
进程间的通信	窗口间操作
进程调度	任务栏（或者火狐之类的标签栏）
进程抢占	焦点抢占
缓存机制	历史记录（最近文档）
...	...

2这个核不支持类超线程的技术

3即多点触摸技术，参见http://www.x.org/wiki/Development/Documentation/MPX

4这里的窗口都指通常称的窗口（不严格的说，就是顶级窗口），下同