2008年3月20日星期四

ASL (Adobe Source Libraries)总览

作者：

    Sean Parent, Adobe Systems Incorporated

    Mat Marcus, Adobe Systems Incorporated

    Foster Brereton, Adobe Systems Incorporated

更新日期:

    2004-12-6

    2007-4-3

翻译：

摘要

本文档总览 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）。最终文档草案免费在线获取。

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

附录——未来的点子

可视化编辑器

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

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

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

Eve2考虑中的特性

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

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

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

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

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

发帖者 cee1

标签： , , , , ,

0 评论:

发表评论

订阅： 博文评论 (Atom)