开发图形用户界面(GUIs)曾经是Java技术编程中一个非常灵活寂静的部分。尽管Java Foundation Classes/Swing (JFC/Swing)技术已经推出很长一段时间了，设计专业的样式，跨平台的GUI仍然是单调乏味和容易出错的。所有这一切将会因为有NetBeans IDE 5.0 和Project Matisse而改变。

Project Matisse通过使得可视化窗体的设计层次更加容易来解决了GUI创建的核心问题。该项目扩展了NetBeans IDE 4.1 Form Editor来支持一个自由设计范例，该范例提供了容易理解和快速使用的版面设计规则。

NetBeans IDE软件工程师Roman Strobl 访问了Project Matisse的创建者Scott Violet 和Tomas Pavek.

你们在Matisse项目中扮演什么角色? 你们涉及这个项目多少时间呢?

Pavek:我在NetBeans作为GUI开发者的领导开发者，现在主要在Matisse项目中工作。这个新的版式的支持项目是在大约在一年以前开始的。

Violet:我是Swing的架构师，一直在做与使得这个系统加入到JDK的那部分的工作。我几乎已开始就参与到了这个项目中。

Matisse项目的起源和目的

Matisse项目是如何开始的? 它的目的是什么?

Violet:我们在几乎所有的Swing的计划会议中已经在悼念编排处理了。特别是现存的大多数的构建者要求你知道编排管理。这是很令人痛苦的一件事情。开发者不应该被强迫去了解有关GridBagLayout的所有的怪癖之处或者本质的LayoutManager来创建可视化的令人愉悦的窗体。这是Matisse所追求的目标。

Pavek:NetBeans GUI builder包含一个定制的GridBag——一种受欢迎的配置GridBagLayout的可视化工具。知道和了解GridBagLayout是非常有用的。我们总是收到要求提高该定制化工局来提高薪能的请求。这些请求希望能够有更加丰富的设计时间支持，更多的可视化操作，更好的编排的约束的边框形式值等等。

我认为开发者们当时实际上是在要求通用的设计编排。他们希望GUI builder能够从GridBagLayout和它的借口中抽象出来。在这个时候，我开始考虑一种自然编排支持，这种系统能够提供任何具体的编排管理器。我必须说的是我曾经把这种想法认为是一种疯狂的想法，并且觉得可能很难以实现。

与此同时，我们把NetBeans GUI builder的demo给了国内的一个GUI的工作组讨论会议，我们也听到了相同的意见。GUI builder是很好的，但是为什么你要去处理所有的这些填料，插入件，填充件，权重合其他的一些参数?我们难道不能具有一些更高水平上的，更加可视化的当然也是更容易使用的工具吗?我们抓住这次机会同Swing工作组的工程师见面了。他们也对现在的对可视化编排设计的工具支持的状况表示失望。

简单的讨论之后，我们都认为问题不是由于编排管理器，而是由于过多的把他们暴露出来了。排版管理器很适合构建结果实现的用户接口(UI)，但是并不是采用被用于交互式可视化工具中的呈现原则。

这个想法很适合我最初的关于自然编排的想法。这种方法就是并不是通过找到另外一个编排管理器来做的，也不是为它创建一个新的工具，而是通过决定开发者需要从一个GUI编排设计工具获得什么。这就是可视化工具将会如何的用于对构件的操控，建立构件关系，排列构件，设置可调节度等等.所有这一切都应该变成可视化的，简单的和直接的。它也需要同现有的Apple和微软工具进行比较。对于开发者没有必要去查看封装在下面的细节，也不需要知道编排是怎样构建的。当然，一个编排管理器对于编排能够合适的工作是必要的，当时它并不是我们需要开始的。最重要的东西是用户的模型。

当我们完成了我们的第一个原形之后，每一个看到我们展示给他们的东西的时候都感到惊奇。我们开始相信我们的路子是对的。

创建一个新的编排管理器

据我所能知道的，一个新的编排管理器并不是这个项目的最初目的。为什么你们会决定创建一个新的编排管理器而不是重用原来已经存在的一些呢？

Violet:把编排处理抽象出来成为一个编排管理器的过程中最美丽的东西是，它允许了无限的可能性。不幸的是，我们没能够找到一个适合我们需要的工具，所以我们决定创建一个新的工具。这个编排管理器命名为GroupLayout并且是一个开放源码的项目。当Matisse需要使用GroupLayout的时候，我们的期望是开发者使用了Matisse之后，就不再需要同GroupLayout直接交互了。至少这是我们的目标。

从某一点上来说，我们也愿意把GroupLayout加入到JDK中。

Pavek:正如Scott已经提到的，你在使用Matisse的时候将不会注意到编排管理器。尽管如此，这个编排管理器非常容易的使用在手工编写代码中，并且可以同Matisse分离开来使用。从Scott提到的 GroupLayout的web站点主页上，你可以下载这个基于具体用户手册的支持文本基线排列和首选的间隔的整个库文件来体验。

我们最初的目的并不是要开发一个新的编排管理器或者进行其他的扩展。但是我们也不想因为现在的JDK中不支持这些特征而极大的限制该工具的功能。至少我们需要基线支持和首选间隔。我们需要一个编排管理器，它可以使用这些新的特征，并且能够处理从Matisse产生的编排结构。GridBagLayout的能力还不足够好，并且使用SpringLayout是一件很痛苦的事情。

一些人认为Matisse的编排把GroupLayout作为私有的工具来使用的。例如，一个Eclipse开发者说:“我们可以使得可视化编辑器近乎准确的类似Matisse来工作，但是却不能有一个私有的编排管理器”。 GroupLayout是你们所私有的吗?

Violet:GroupLayout和相关的功能不再是私有的，而是GTK。GroupLayout已经开源了(LGPL)。

如果你需要把编排管理器和你使用Matisse开发的应用服务器邦定起来，那么这个应用程序看起来似乎更难以部署。你们计划什么时候把它加入到标准的JDK发布版本中?

Violet:我们已经计划把它加入到JDK中。但是GroupLayout相对于Java平台，标准版(Java SE, 就是 正式发布的 J2SE) version 6的周期太慢了。另外的，我们不希望开发者在可以使用Matisse以前一直等待版本6 的发布。我们的目标是支持J2SE 1.4.2!由于这个需求的提出，所以一个扩展的库是必须的。如果一切顺利，我们将会把GroupLayout加入到版本7中。

Pavek:我们并不是总是会有扩展的库，但是希望这并不是一个太大的问题。使用扩展库在今天是很普通的一件事情。你很难看到那些大型的项目是仅仅只依赖于标准的JDK类的。这个库是很小的，开放源码，并且你可以通过NetBeans自动获得它。正如Scott说的，这只是一个暂时的解决方法，当GroupLayout能以适当的方式融入到JDK以后，这个问题就会被解决的。

我希望指出的一点是，Matisse并不是取代前面的NetBeans GUI builder，它只是扩展了NetBeans GUI builder。它仍然可以使用原来的方法来开发窗体，通过使用标准的编排管理器。

一些人说Matisse只是一个Java技术实现版的Macintosh操作系统的接口构建(Interface Builder )。你们从这个工具获得了多少的启发?

Violet: Matisse同Interface Builder共享了相同的相似性，这并不奇怪。IB是目前开发出来的最好的构建工具。它允许开发者拖拽和放置构件，就如同是在画一个程序一样。但是IB 和AppKit同Swing是非常不同的。特别的，Swing运行在许多不同的操作系统之上，并且支持不同的外观和效果。因此，编排必须根据构件的尺寸在外观和效果，位置和操作系统之间做适当的改变。而不需要要求每个外观，效果，位置都有一个窗体来对应。你想象一下，在一个对每一个位置，操作系统，外观及效果的组合都要求一个新的窗体的情况中，如果这样的状况下来写应用程序，会是怎样的一种痛苦的事情。噢!

Matisse解决了所有的这些问题。所有在Matisse中设计的窗体将会随着由于构件的位置、不同的外观和效果或者操作系统而使得构件具有不同的尺寸的不同的情况而改变。

Pavek:最主要的区别是通过Matisse你将得到一个完全交叉平台的编排定义。这意味着构件的选项和尺寸将不会仅仅是在由当你把它们放置到设计框架中去的那个时刻的数字来决定了，而是会在目标环境中运行时动态的计算。Matisse创建了一个编排模型用来记住所有构件之间的关系，并且GroupLayout动态的维护这些记录。这就意味着当你使用抓取的特性并把这个构件放到一个特定的地方，这个构件就不仅仅会收到一个位置协调的消息，并且会记住为什么它会被抓取。例如，如果它被抓取同另外一个构件的左边对其，这个时候这个构件会始终保持它们的左对齐格式，即使它们的绝对位置发生了改变。

双路编辑和保护模块

许多的开发者很高兴能看到在NetBeans中有双路编辑——使用一个可视化设计器和一个文本编辑器。一些可视化设计器已经实现了这种方式。但是NetBeans IDE使用保护模块来防止用户编辑代码。为什么你们选择这种途径?

Pavek: NetBeans已经有很长的历史了。这个决定是在很多年以前作出的，并且很大一部分是由源驱动的。创建一个Java 技术开发GUI的双路工作工具并不是微不足道的。理论上来说，它将永远不会完美的运行，尽管具有一个已经足够好的工具在实际上也是可以行得通的。仍然的，你将会面精力不足的情况，特别是当工具不能理解一部分的代码并且不能构建所有的可视化操作的UI的时候。NetBeans GUI builder在这方面是百分之百的可靠的。

保护代码并不阻碍你做任何的事情。NetBeans提供了钩子，从而你可以更改生成的代码，并且加入你自己的代码。更多的，你能够自由的在任何的保护代码——也就是在类的构造方法——之外的地方增加附加的修改。你开始对这种方法也学感觉没有那么好，但是我们认为它将逐渐的成为一种非常自然的习惯。

然而，双路编辑方式实在是真的很流行并且被广泛的请求，所以我们不可能会忽略掉它。我现在不能说我们是否会完成全部的双路编辑或者不做。但是很明确地我们愿意解决这个我们没有涉及到的最主要的用例——就是从现有的代码倒入UI。这就是我们收到了许多请求要求实现的性能中的一个。

Violet:这是一个被热烈讨论的问题，但是我认为代码生成是一种错误的路径。具有代码生成能够鼓励开发者胡乱的添加代码。另外的，代码生成会鼓励开发者以有编排、构件创建、事件配线和功能的粗糙的大型类结束。从长远来看，我更愿意看见构建工具使用持久beans或者其他形式的持久化。这种方法，让开发者不用感觉有添加代码的必要，或者很有希望的是它能产生更具有可读性的UI相关的类。

Pavek:我同意。这些都还没有发生，是因为还缺乏适合的和标准的持久化格式。我担心bean持久化现在看起来似乎没有那么强大。从历史上来说，Swing UI也是通过代码表示的最好的形式:每一个人都通过这种方式来认识它，并且查看那些代码来确定是否出错了。那也是为什么双路编辑工具很流行的原因。如果只有Swing一开始就把具有了宣布的持久化!但是这仅仅是一个完全不同的不相关的讨论。

Matisse的动力和挑战

Matisse的动力是什么?你们是从什么来考虑认为这个项目会走到其他的可视化工具的前面?

Pavek: Matisse把苹果和微软的工具提供的对设计的减轻都集成了进来，同时产生了跨平台的UI, 例如在使用编排管理器的时候。这是一个相当独特的融合，我个人是这样认为的。

Violet: Matisse的勇气是在于 ，它可以让那些新的Java技术的开发者来开发一个可以给与可视化指导方针荣耀的外表和效果的窗体，把构件用他们的基线对齐，并且可以对任何的外表和效果、位置以及操作系统组成都能够适当的调整 他们的大小。他们可以完成这一切而完全不用知道LayoutManager的细节。这是没有多少其他的工具能够让你做到的。

在Matisse项目中曾经最具挑战的问题是什么?

Pavek:在一开始,我们就在努力的寻找一个编排概念，已使其能够使得用户友好的设计和交互能够有效，并且足够来创建典型的编排的能力。首先，我们尝试了一个类似于SpringLayout的构件边缘任意相关的想法，但是这种想法最后因为太过于开放而结束，并且还尝试了一个编排类似的构件网格想法，试图使它能够实现适当的跨平台编排。最终两个想法都很快的被放弃了。于是我们想出了在两者之间的一种办法:一个融合了两种途径的实力的嵌套组的编排系统。

在交互作用的部分，我们需要处理用户的表示的含糊。当用户放置一个构件的时候通常的有多余一种的方法来处理本质的模型。但是我们却不能读到读者的想法。工具可能作一些并不是开发者希望的事情，但是它始终应该是采用一种开发者可以理解的方式来进行的，这样也就不会让用户感觉到正在屏幕背后发生的奇怪和复杂——而实际上是这些事情正在发生。另外一个具有挑战的领域是编排结构的可视化——那就是，显示构件之间的关系，队列，调整打大小等等。这个工具必须容易使用，所以我们不能完全的细致的展示所有这些内在必要的结构。但是一定水平上的信息是必须的，特别是为了能知道编排将会作什么和为什么这么做。终究跨平台编排并不是一个实验的东西。

Violet:肯定的最大的挑战是如何把用户的手势映射到对应的编排管理器。我的意思是说当你在一个按钮前放下一个文本文件的时候，当你移动一个按钮的时候，等等这些时候LayoutManager将会发生什么。这听起来也许很琐碎，但是当你考虑为了维护构建之间的关系在其尺寸改变的时候可以适当的调整过来的需要的时候，你将会意识到这不是一件简单的事情!

前面的路

你们以后的计划是什么?你们认为最令人惊奇的特色已经由NetBeans IDE 5.0带来了吗?或者仍然有许多为以后的在5..0之后的版本可以创新的空间，直至最后?

Violet:我们决不会完全做完的。Matisse本身就将会不断的提升，不管是在可用性还是在稳定性这些类似的方面。在5.0发布以后，你将会看到很多有趣的东西正在被加入到Matisse中。从长远来看，我们的想法也是没有缺少过的。下面就是一些我们已经考虑过的东西。

提供能够把一个模版作为一个窗体的开始点来使用的能力。很多窗体都是非常相似的，除了一些个别的领域。如果能够有一种方式可以从一个相似的窗体开始，并以此来开始配置，这将会是一件很好的事情。这就将会和在StarOffice或者PowerPoint中选择不同的模版一样。

使得开发者能够更加容易的编写大量的代码，需要把构件同数据邦定起来。这个工作已经在SwingLabs中正在完成。
提供书写标准的持久性文件的能力，而不是通过代码生成。
使得编写和维护中型到大型的应用程序更加容易。我不是很确信这将会带来什么，但是毫无疑问的是这将带来NetBeans和Swing的改变。

Pavek:我只是补充一下Scott的列表。

基于我们获取到的回馈我们调整和提高Matisse。在编排设计领域仍然有许多有用的特征可以加入进去。我们只是不能把所有我们想要加入的东西都加入到一个发布版本中去。同样的，一些东西需要一些时间来平定下来并且找到他们的最佳的形式。

修补GUI builder的剩下的部分，就和我们对编排设计所做的事是类似的——那就是使得更加专注于设计UI而并不用知道过多的关于Swing的细节。

导入UI窗体源文件或者限制双路编辑。

提供更好的支持来使用和开发定制构件(这在JSR 273中得到了丰富的支持的)，重用窗体(可视化继承)，和编排(模版和构件摘录)。

并且还有许许多多的不同的关于使用性的和其他的提高。这些只是我们想到的基本的想法。我还不知道他们将会怎样出现在具体的计划和具体的发布版本中。