loading ...

Q网志

my web and me.
显示标签为“SWT”的博文。显示所有博文
  在这篇文章里,我将描述一个Java桌面应用的原型,我把它叫做JImageing。我打算把焦点集中在应用的框架上,解释我怎么做技术上的决定和我怎么解决在开发过程中出现的问题。

  为什么要建造一个原型?

  很多应用程序的开发都是由于几个原因从一个原型开始的。这些原因中的第一条就是,你必须确定用现有的技术能够满足用户的需求。例如,在不用本地代码的Swing应用程序中Windows集成不能够被实现,这就导致丧失了一些Java跨平台的优势。SWT提供了一个和操作系统有限制的集成,这就允许你在很多本地平台上运行同一应用程序。在很多场合,J2SE平台提供给你需要搭建复杂桌面应用程序的丰富性能。在搭建大型Java桌面工程之前,你总是应该搭建一个原型去看J2SE是否满足应用程序的需求。

  另一方面证明你的想法能够被实现并且你的技术决定是正确的,一个原型能够在开发过程中尽早的获得用户的反馈。原型也能帮助你估计完成你的工程所需要的时间和资源。花大量的工作去搭建一个有着菜单,对话框,拖拽特性、剪切版支持、恢复管理、打印等功能的用户接口。在开始这些工作之前,你应该知道搭建应用程序核心功能有多困难。如果你不得不用第三方自定义组件,你应该测试他们看看是否能和你的原型一起工作。如果你不得不解决扩展和性能问题,你应该通过原型状态找到解决方案。

  用户需求

  JImageing原型是一个桌面应用程序,这个应用程序允许你给图片注释。Email可能是最流行的“协作工具”,但是可以通过图片工具提高在截图上做注释的能力,这种图片工具可以让你画线,画矩形、椭圆并且可以写注释信息在图片上。

  如果JImageing的用户使用一个以上的操作系统,那么对于这样的一个应用程序Java是很自然的选择。当Windows支配桌面市场的时候,有一些用户选择Mac或者Linux。例如,当Java开发者通过互联网对一个项目进行合作的时候,有一可能性是他们可以不用同一种操作系统。

  这个用户接口非常简单,它包括一个工具栏和一个画图区。对于测试应用程序的主要功能来说足够用了。下图显示了这个接口的样子:

  包和类

  下图显示了原型代码结构。应用程序的最顶层的包仅仅包含Main类,下段再详细介绍这个类。我将要描述在将来文章中可能用到的其他类。

  frames包囊括了描述应用程序主框架类,基于JDesktopPane的主要panel,和基于JInternalFrame文字注释类。这三个类被命名为MainFrame, MainPanel和NoteFrame。

  paint包组织了PaintView组件和它的数据模型(被命名为PaintModel),还有ToolBarBuilder类,这个类创建应用程序的工具栏。tools子包有绘制图象对象的工具类。

  resources包中的ResourcesSupport类是处理ToolBarResources.properties资源和来自images目录中的图标的工具类。

  The Main Class

  这个类实现了应用程序的main方法并且和所有的类、资源打包成一个JAR文件,这个JAR文件命名为JImageing.jar。用下面的命令进行打包:
jar cfm JImaging.jar m.txt com

  com目录包含包里的类,.properties资源和.gif图标。
  m.txt文件用Main-Class: com.devsphere.articles.desktop.Main简要说明了应用程序的主要类。
  jar工具拷贝m.txt文件到在JImageing.jar中自动创建的META-INF/manifest.mf文件。

  下面是Main的主要声明描述:

package com.devsphere.articles.desktop;
import com.devsphere.articles.desktop.frames.MainFrame;
import com.devsphere.articles.desktop.frames.MainPanel;
import javax.swing.UIManager;
import javax.swing.UnsupportedLookAndFeelException;
import javax.imageio.ImageIO;
import java.awt.image.BufferedImage;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.io.File;
import java.io.IOException;
import java.util.logging.Logger;

  main()方法调用Main()构造器,设置外观,创建主要窗口然后显示它:

public class Main {
 private String args[];
 private MainFrame mainFrame;
 private MainPanel mainPanel;
 private Main(String args[]) {
  this.args = args;
 }
 public static void main(String args[]) {
  Main main = new Main(args);
  main.setSystemLookAndFeel();
  main.createFrame();
  main.showFrame();
 }
 ...
}

  命令行可以包含一个或两个参数。用户能指定一个图片资源路径作为第一个参数。应用程序加载和显示图片,允许用户对它进行注释。如果第二个参数存在,那么应用程序保存注释过的图片到这个参数所给定的文件路径。运行应用程序,下面的命令行启动它:
java -jar JImaging.jar sourceImage annotatedImage

  J2SE能够加载GIF,JPEG和PNG文件,但是它仅仅能保存JPEG和PNG格式的图片。你可以不用GIF格式去保存注释过的图片。

  设置系统外观

  下面的setSystemLookAndFeel()方法调用了javax.swing.UIManager类的setLookAndFeel()方法:

  它要求Swing从默认的Metal外观转换为本地外观:

private void setSystemLookAndFeel() {
 try {
  UIManager.setLookAndFeel(
   UIManager.getSystemLookAndFeelClassName());
 } catch (UnsupportedLookAndFeelException x) {
  log(x);
 } catch (ClassNotFoundException x) {
  log(x);
 } catch (IllegalAccessException x) {
  log(x);
 } catch (InstantiationException x) {
  log(x);
 }
}

  通常,因为setLookAndFeel()参数都有一个可用值所以不会抛出异常。然而用标准日志API任何异常都可以作为严重错误信息被记录:

private static void log(Exception x) {
 Logger.global.severe(x.getMessage());
}

  原型安例中用全局日志是可以的,但是一个产品应该用它自己的日志,保存错误信息在文件中。

  创建并显示主要窗口

  createFrame()方法创建一个MainFrame实例,并且加载了图片:

private void createFrame() {
 mainFrame = new MainFrame();
 mainPanel = mainFrame.getMainPanel();
 mainPanel.updateSize();
 mainFrame.pack();
 loadImage();
}

  updateSize()设置了由getMainPanel()获得的主要面板的合理大小。pack()方法使得主框架调整大小从而让主面板和应用程序工具栏调整到合适的大小。注重到getMainPanel()和updateSize()方法是MainFrame和MainPanel类实现的应用方法。pack()方法是从java.awt.Window中继续下来的。

  showFrame()方法显示应用程序的主框架并且调用主panel的requestFocus()方法。没有调用requestFocus(),焦点将被工具栏中是缩放下拉框获得,这个组件不是框架的主要组件。当应用程序开始的时候,它的主要组件应该获得焦点,即使主要panel没有处理任何键盘事件。

  在窗口关闭的时候调用setDefaultCloseOperation(),禁用这个方法的默认动作而是传递DO_NOTHING_ON_CLOSE作为参数。showFrame()方法注册自己拥有的窗口监听器以便处理窗口关闭事件。当用户关闭主要框架,监听器保存一个做过注释的图片,释放框架所占用的资源并且用System.exit(0)结束应用程序的执行。

private void showFrame() {
 mainFrame.setDefaultCloseOperation(
  MainFrame.DO_NOTHING_ON_CLOSE);
 mainFrame.addWindowListener(new WindowAdapter() {
  public void windowClosing(WindowEvent e) {
   saveImage();
   mainFrame.dispose();
   System.exit(0);
  }
 });
 mainFrame.show();
 mainPanel.requestFocus();
}

  加载和保存图片

  一个完成的产品将用文件对话框去加载一个源图片并且保存一个注释过的图片。在观念上,“文件打开”对话框将让拥护预览图片,“文件保存”对话框将答应他们去提供不同的参数,例如保存图片的压缩质量。Swing的标准文件对话框是基于组件JFileChooser,这个组件能够通过setAccessory()方法进行自定义,让你在文件对话框上加载你的组件。

  在原型安例中,注重力应该在主要功能上。因此,原型通过从命令行获得加载和保存路径代替用自定义的文件对话框。javax.imageio.ImageIO类简单的read()和write()方法被用于加载和保存图片。注重,Image IO API让你知道哪种图象格式是支持的,并且你能设置例如压缩质量的参数。对于自定义文件对话框也将需要这些性质。

  loadImage()方法读取一个图片文件,路径是由命令行第一个参数提供的,并且设置主要panel的背景图片:

private void loadImage() {
 if (args.length >= 1)
 try {
  File file = new File(args[0]);
  BufferedImage image = ImageIO.read(file);
  mainPanel.getPaintView().getModel().setBackImage(image);
 } catch (IOException x) {
  log(x);
 }
}

  saveImage()方法获得一个主要panel的注释过的图片,并且把这个图片保存到一个文件里,路径是由命令行提供的第二个参数给出的:

private void saveImage() {
 if (args.length >= 2)
 try {
  File file = new File(args[1]);
  String name = file.getName();
  int k = name.lastIndexOf('.') + 1;
  String ext = name.substring(k);
  BufferedImage image= mainPanel.getAnnotatedImage();
  ImageIO.write(image, ext, file);
 } catch (IOException x) {
  log(x);
 }
}

  做技术决定

  在开发过程中,我不得不去解决一些技术问题并且要做一些技术决定。下面的代码片段仅仅简单的进行了解释,但是他们将在我以后的文章中被具体描述。在这里重要的是去理解原型充当的角色。用你的原型去寻找技术问题的解决方案,去测试不常用的APIs,并且保证你的应用程序的性能。

  用多层Panels

  构建一个例如windows中的画板的图形应用程序不是非常复杂的任务。你必须处理鼠标事件、画线、画矩形和画椭圆。还要处理变形功能,比如从一个基础应用程序到一个专业级的图形编辑器要具有对图片的移动,缩放,重新排序、删除、复制、剪切和粘贴等更多的工作。你也可以想要包含一个可以进行编辑、重新控制大小和文字包装功能的文字框等等。构建自己的风格文本编辑器是没有必要的,因为Swing已经提供了一些文本组件。

  你怎么将Swing的文本编辑器和你自己的绘图组件相集成?我考虑了两个解决方案。一个是实现一个类似于JTable所用的cell编辑器,但是假如你想改变文本框大小或者移动它就需要一点技巧了。另个一个解决方案是用JDesktopPane,把文本组件放在JInternalFrame之内。

  用第二种解决方案的话,Swing已经提供了改变大小和移动功能,但是下面的问题是你怎么在包含文本注释的内置frame下绘制图象?并且你怎么在JDesktopPane上绘制其他简单图形,例如直线、矩形和椭圆?幸运的是,有一个简单的解决方案,因为JDesktopPane是真正的多层Panel。原型的MainPane类扩展了JDesktopPane,有两层。它们中的一个包含PaintView自定义组件,答应你绘制简单图形。另一层包含文本注释。当然,假如一个注释图片不能被程序获得,那么这个解决办法是没有意义的。MainPanel的getAnnotatedImage()方法利用下面的代码做这件事:

BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
Graphics2D g = image.createGraphics();
printAll(g);
g.dispose();

  在paint()外部进行绘制

  Swing组件的绘制通常都是在paint()内部进行或者在paint()内部调用绘制方法。当用鼠标在屏幕上绘制一个对象,可是,你不想重绘其他组件,因为这将引起应用程序运行效率低下。例如,用户用铅笔进行绘制,每个鼠标事件都让应用绘制一个小线段。在MOUSE_PRESSED和MOUSE_RELEASED之间有上百个MOUSE_DRAGGED事件。

  当用户在屏幕仅仅绘制了一些图形时,重绘PaintView组件几百次这样的事情是不能被接受的。注重一下,PaintView处理大多数的绘制操作并且一个repaint需要所有注释包括文本注释进行重绘。正确的解决方案是当每个鼠标事件被处理时在paint()外部利用getGraphics()获得图形上下文。

protected void toolAction(MouseEvent e) {
 e.consume();
 Graphics2D g2 = (Graphics2D) getGraphics();
 float zoomFactor = model.getZoomFactor();
 g2.scale(zoomFactor, zoomFactor);
 float x = e.getX() / zoomFactor;
 float y = e.getY() / zoomFactor;
 currentTool.action(e.getID(), x, y, g2);
 g2.dispose();
}

  PaintView组件利用鼠标监听去处理鼠标事件。上面的方法被每一个事件所调用,委托绘制currentTool对象。当鼠标释放的时候,repaint()被调用去请求整个组件的刷新。因此,用户完成图形对象绘制后paint()仅仅被调用一次。这是注册鼠标监听的代码:

protected void registerListeners() {
 addMouseListener(new MouseAdapter() {
  public void mousePressed(MouseEvent e) {
   if (SwingUtilities.isLeftMouseButton(e)) {
    requestFocus();
    currentTool = model.createTool(AbstractTool.DRAW_STYLE);
    toolAction(e);
   }
  }

  public void mouseReleased(MouseEvent e) {
   if (SwingUtilities.isLeftMouseButton(e)) {
    toolAction(e);
    model.setLastTool(currentTool);
    currentTool = null;
    repaint();
   }
 }
});

addMouseMotionListener(new MouseMotionAdapter() {
 public void mouseDragged(MouseEvent e) {
  if (SwingUtilities.isLeftMouseButton(e))
   toolAction(e);
 }
});

...
}

  PaintView类的完整代码将在以后的文章中讲述。上面代码片段仅仅展示了怎么利用原型去做技术决定。

  总结

  原型在应用程序开发过程中有着重要的角色,答应你测试你的想法并且尽早的获得用户反馈。我没有把原型看成是当“真正”开发开始时可以被丢弃的代码片段。反而,原型应该是你产品或者着应用的基础。这意味着你应该小心的对它进行编码,尽管你的类或方法在以后要被重写。

...... [阅读全文]

原文:
http://blogs.sun.com/Swing/entry/awt_swt_swing_java_gui
译者:Matthew Chen

Overview概述

Java GUI 工具包一直是一个倍受争议的话题。同样的争论也发生在其他编程语言如Smalltalk。实际上每个平台无关的语言都存在着这样的争论。Java作为当前最受广泛使用的编程语言而尤为突出。

这场争论在支持模拟组件(如widgets和control,在下文中也称之为仿造组件)和支持本地组件(在下文中也称之为原生组件)的人们之间展开,于是Java开发者形成了两个不同的阵营,提倡使用模拟组件的Swing,和提倡使用原生组件的SWT。

历史

Internet上有许多围绕这一争论的故事。你可能已经听说过它们中的大多数了,其中之一有助于让你理清头绪,让我们就从这里开始,Amy Fowler是Swing阵营的一个倡导者。

回到上个世纪90年代,曾几何时有3家庞大的Smalltalk公司——IBM、Parc-Place和 Digitalk。在90年代初期3家公司的市场份额大致相等,生活是美好的。Parc-Place采用仿窗口部件(emulated widgets)的设计(即Swing的设计),IBM和Digitalk则采用原生窗口部件(native widgets)。后来IBM压倒了另外两家,因此他们打算合并成一家,假设叫做Parc-Place Digitalk。随后当他们试图将他们的产品融合到一个叫做Jigsaw的计划中时爆发了一场大战,计划由于政治原因失败了(开发人员实际上已经能让它运转起来),就因为原生和仿造两派的死战。

Amy赢得了精神上的胜利,不过IBM赢得了他们所有的生意,因为这两家公司在一整年里除了吵架什么都没做。当尘埃落定之后PPD(Parc-Place Digitalk当时已改名为Objectshare,跟Windscale改名为Sellafield的原因相同——让人们淡忘之前发生的灾难)的股票价格从60美元掉到了低于1美元1股。他们因为伪报收入被NASDAQ摘牌,从此消失。

当时,AWT已经出现了。SUN当时已经建立了一套基本的可移植控件类,这些类映射到不同操作系统上的原生窗口组件(native widget),当时的AWT还满是漏洞,远不能称为可靠,还需要SUN的coder们去修补。然后Amy被雇佣了,她承诺通过轻量级方案解决所有窗口组件的问题,以此说服SUN管理层让她当了GUI开发部门的头头。随后Amy雇佣了所有她过去在Parc-Place的旧朋友,让他们来开发Swing。

在IBM,VisualAge for Java最初是用Smalltalk(用的是原生窗口组件)写的,当将这些工具向Java代码库迁移时,他们需要一套窗口组件。IBM这边的开发人员都是原来搞Smalltalk的那一批人,他们对管理层要求用Swing来构建WebSphere Studio工具都非常不情愿。“Swing是个可怕的充满缺陷的怪兽“。因此开始了一个新的项目,把他们的Smalltalk原生窗口组件移植到Java上去。这个工具集后来被成为SWT,S开始是Simple的缩写,不过后来变成了Standard的缩写。这个项目获得了成功,被运用在发布的 VisualAge Micro Edition产品中。他们当时发现在Swing读事件队列的时候用了一种可能留下内存漏洞的方式,而不得不采用他们自己的查询 Windows事件队列的循环,以纠正这个错误。这促成了他们关于SWT和 AWT/Swing不能共存的决定。他们把这个工具包放到了Eclipse中,这是一个来自于早期Visual Age的工具平台。

你应该已经从上述的故事中对三者的历史有了大概的了解,尤其是SWT。现在你也许会觉得,IBM创建SWT的理由是合理的而Swing应该沿用SWT采用的方式。这样的观点是片面的,当你深入了解到Java的本质之后,你会发现其实并不像你想象的那么简单。

先决条件

什么才是Java本质的,影响到工具集设计的特征呢?或者说,什么才是Java GUI工具集设计的先决条件呢?

答案来自于Sun对Java的承诺之一:write once, run anywhere(一次编写,随处运行)。这是Java不同于其他语言的优势所在。在Java被创建之前,软件的跨平台性能是开发者,特别是那些希望对多平台提供支持的开发者的梦魇。在当今的生活中Internet的使用已经相当的普遍了,在世界不同角落的人们在不同的平台上工作着。软件提供商为不同的操作系统提供支持是再平凡不过的事情。Java的write-once-run-anywhere(WORA)承诺显然减轻了开发者的负担,极大地提高了软件开发的生产力。

然而编写跨平台的应用程序,你必须使用支持平台无关性的标准库。这些标准库包括语言支持,公共用途,网络,I/O和GUI工具集等。所以当Sun开始设计GUI工具集的时候,首要任务就是考虑一个设计良好的平台无关的API。AWT和Swing都被小心地设计以保证平台兼容性。SWT则相反,它在设计之初并不以扩展性为原则,它为一个专有的IDE Visual Age for Java而设计,Windows作为这个IDE的首选运行环境拥有很高的优先级考量。SWT API类似于WIndows,通常它并不如Swing的扩展性好,尽管Steve Northover,SWT之父,辩称SWT是平台无关的,你可以很容易地发现许多Windows API的痕迹。

区别

GUI应用程序是软件的一种主要类型,所以Java的GUI库应该是标准化并被集成到JRE平台中的。然而不同的操作系统有不同的GUi风格和组件集。有一些组件在所以平台上有相似的观感。这些共有组件如按钮,标签,文本域,单选框等被称为标准组件。不同的GUI工具集提供了不同的组件集。GUI工具集总是遵循不同的原则来选择组件类型和特征以实现。考察一个工具集,有两个不同的要素:组件类型和组件特征。

Terms

首先让我图解两个数学概念:最大公约数和最小公倍数。如下图,三个集合代表不同的操作系统。相交的部分是最大公约数,合并的部分是最小公倍数。

现在让我们来考察Java GUI工具集AWT,SWT和Swing的组件类型和特征

AWT

AWT组件集遵循最大公约数原则,即AWT只拥有所有平台上都存在的组件的公有集合。所以你在AWT中无法获取如表或树等高级组件,因为它们在某些平台上不支持。AWT的组件特征同样遵循这一原则。它只提高平台上公有的特征。例如AWT按钮不能附着图片,因为在Motif平台上,按钮是不支持图片的。

由于它低劣的组件集和特征,AWT无法吸引开发者。它是Sun不推荐使用的,只是为了确保向下兼容和支持Swing。

SWT

SWT最初的目标之一是为了提供比AWT更为丰富的组件集。它遵循最小公倍数原则以提供一个各个平台上包含的组件的并集。思路是如果一个组件在某个平台上包含,那么SWT就会包装它并用java代码和JNI来调用它。如果一个组件在某一平台上不存在,它就会用继承并绘制Composite的方式来模拟组件。一个SWT Composite类似于AWT的Canvas。以这种方式,SWT提供了较AWT更为丰富的组件集。值得指出的是SWT的JNI封装不同于AWT,它的模拟也不同于Swing。

在组件特征方面,SWT类似于AWT。它遵循最小公倍数原则。在早期的SWT版本中,SWT按钮因为和AWT同样的原因不支持附着图片。在之后的版本中,许多缺失的特征采用模拟的方式补全。但仍有许多特征无法采用纯粹的模拟实现。SWT将组件的控制交给本地操作系统。它难以扩展。只有例如图形装饰等特征可以借助模拟绘制来自定义实现。所以严格意义上将,SWT组件的组件集和特征因其难于扩展而不如Swing来得丰富。

Swing

Swing是三者中最强大和灵活的。在组件类型上,它遵循最大公约数原则。由于Swing可以控制自身GUI系统的全部并有很好的可扩展和灵活性,它几乎可以创建所有你想象得到的组件。唯一的限制是它的AWT容器。在Swing中你还不能跨平台地实现真正的透明化和不规则矩形窗口,因为Swing依赖于AWT顶层容器例如Applet, Window, Frame and Dialog等。除此之外,Swing几乎实现了所有平台上的标准组件。

在组件特征上,Swing遵循最小公倍数原则。它拥有所有平台上可提供的组件特征。不仅如此,你还可以继承已有的Swing组件并添加新的特性。

上面比较主要是在API级别上的。让我们将比较的焦点转移到实现细节上。Swing和SWT/AWT的区别是Swing是纯Java实现,而SWT和AWT是Java和JNI的混合。当然,它们的目标都是相同的,提供一个跨平台的APIs。然而为了达到这一点,SWT和AWT不得不牺牲一些组件和特性以提供一个通用的APIs。

AWT

一个AWT组件通常是一个包含了对等体接口类型引用的组件类。这个引用指向本地对等体实现。举java.awt.Label为例,它的对等体接口是LabelPeer。LabelPeer是平台无关的。在不同平台上,AWT提供不同的对等体类来实现LabelPeer。在Windows上,对等体类是WlabelPeer,它调用JNI来实现label的功能。这些JNI方法用C或C++编写。它们关联一个本地的label,真正的行为都在这里发生。作为整体,AWT组件由AWT组件类和AWT对等体提供了一个全局公用的API给应用程序使用。一个组件类和它的对等体接口是平台无关的。底层的对等体类和JNI代码是平台相关的。

SWT

SWT也使用JNI的方法论来实现。但细节不同于AWT。SWT的拥护者听到人们拿SWT和AWT相提并论可是会很生气的,Steve Northover,SWT之父,就曾为此抱怨过。

没错,它们是不同的。让我们深究SWT的代码。在SWT中,各个平台上唯一相同的部分是组件的接口,是类和方法的定义签名。所有的底层代码都是平台差异的。SWT为每个平台提供了OS类。这个类用JNI封装了许多本地APIs。SWT组件类通过把这些JNI方法黏合在一起提供一个有意义的功能。

例如,在Windows上,文本域的选择是由一个系统调用处理的。这个系统调用在Windows的OS类中作为一个本地方法实现。所以在Windows平台的Text的setSelection方法中只用到了一个JNI调用。

然而,在motif上,文本域的选择包含两个本地调用。SWT就在motif的OS类中实现了两个调用。所以在motif上组件类需要作两次调用来实现文本的选择。

现在你应该能看出SWT和AWT的最大不同了,它们使用了不同的对等体编程方式来消除平台差异。SWT用java代码或有JNI实现的java对等体来黏合系统调用。而AWT把代码包含在对等体中,使情况复杂化了,我个人觉得SWT的方法更加明智。

SWING

到了Swing这里,一切就变得清晰和直接了。除了顶层容器,Swing的实现不依赖于具体平台。它掌管了所有的控制和资源。Swing所需要的是事件输入来驱动系统,以及承接自顶层AWT容器的图形处理,字体和颜色。普通的Swing组件可以看作是AWT容器的一块逻辑区域。它们并没有注册对等体。所有添加到同一顶层容器的Swing组件共享它的AWT对等体以获取系统资源,如字体,图形处理等。Swing将组件自己的数据结构存储在JVM的空间中。它完全由自己管理画图处理,事件分发和组件布局。

由于AWT和SWT都持有对本地组件的引用,它们必须以正确的方式释放这些引用以避免内存泄露和JVM崩溃。AWT将绝大多数资源管理任务交给系统,将开发者从单调乏味的资源管理中解救出来。然而这使得AWT的实现复杂化了。一旦它实现了,开发者很少有机会犯错误并使他们的程序崩溃。

SWT用的是另一种方法。大体上,SWT让开发者自己来管理资源。它的一条著名的规则是:谁创建,谁释放。因此开发者必须谨慎地显式调用dispose方法释放每一个由他创建的组件和资源。这简化了SWT的实现模型,但把开发者摆在了因错误编码而易于造成程序崩溃这一风险之上。

模拟方式的区别

Swing和SWT在它们的实现上都使用了模拟。SWT只模拟平台上缺失的组件。区别是SWT的模拟更像是AWT的Canvas实现的模拟。SWT的Composite类有它自己在操作系统中相应的对等体。它从自己的对等体中获得所有它所需要的资源如图形处理的对象,字体和颜色等。它直接从操作系统获取所有的事件并进行处理。然而,Swing组件在操作系统中没有相应的对等体。它只是一块顶层容器中的逻辑区域,实际上它从顶层容器的对等体中借用资源。Swing的事件并不是底层系统产生的事件。它们实际是由顶层容器处理AWT事件所产生的伪事件。我们会在稍后的事件部分中详细介绍它。

图形层结构

另一个不同之处是Swing组件的z-order系统是来自于AWT组件的。如上所述,Swing组件与顶层AWT容器共享一个对等体。因此,Swing组件也和顶层容器有相同的z-order。SWT和AWT组件都有不同于顶层容器的z-order,通常是高于顶层容器。故而如果AWT组件和Swing组件混合在一起的话,Swing组件将可能被AWT组件遮住。当操作系统开始更新UI的时候,顶层容器和Swing组件总是先于AWT组件绘制。当它们完成绘制,AWT组件会覆盖Swing可能绘制过的地方。因此不提倡Swing和AWT组件的混用。如果有一个浮动的Swing组件如菜单,AWT组件很可能遮盖菜单。

布局管理器

并不是三者中的所有部分都是不同的。布局管理器是一个例外。开发GUI应用程序,当容器改变大小的时候,组件需要重定位或改变大小。在传统的编程语言中,这依靠监听大小改变的事件来实现。相应的片段散落在源代码的各个角落降低了程序的可读性。Java引入了将布局代码封装的思路,称之为布局管理器。当布局管理器对象被设置到一个容器中,它自动处理大小改变的事件。当大小改变时,管理器的布局方法被调用以重定位子组件或调整它们的形状。

AWT,SWT和Swing都以这样的方式来组织,而都有它们各种独特的布局管理器。由于AWT和Swing拥有一个共同的超类java.awt.Component,它们的布局管理器可以交替地使用。

Look And Feel观感

包括SWT和AWT在内的本地工具集并不支持Look And Feel机制。它们将组件捆绑在操作系统上,有其优势和劣势。其中的一个劣势是它们不支持可插拔的Look And Feel。将绘制处理交由操作系统完成剥夺了它们实现自定义组件Look And Feel的能力,也就使得它们无法提供这种机制。Look And Feel机制越来越成为GUI工具集中不可缺少的一部分。

Swing拥有很好的Look And Feel支持。你甚至可以动态地改变Swing应用程序的Look And Feel,鉴于AWT和SWT将组件控制完全交给操作系统处理,这是它们所无法超越的任务。我曾经听很多人抱怨过Sun在Swing上的设计。他们觉得Swing为什么不像SWT那样沿用AWT的思路呢?事实上,Look And Feel机制正是Swing走到这个方向上的原因之一。如果Swing遵循的是包装已有的组件并模拟不存在的组件的路线,那它就无法提供Look And Feel机制。因为提供Look And Feel机制是本地策略所无法完成的任务。

Graphics and Fonts图形和字体

Swing作为一个仿生系统,它的图形工具集较之AWT和SWT强大许多。Swing基于其自身系统中的两个基础组件群:Java 2D和AWT。Java 2D在Java中是强大的类库,它为高级图像处理,颜色管理,图形绘制和填充,坐标系变换和字体生成提供丰富的特性。相较之下,AWT和AWT仅对这些特性提供有限访问,它们是相对原始和低级的。

JavaBeans Specification Conformity JavaBeans规范一致性

Swing和AWT在设计之初就秉承了JavaBeans规范,它们的组件类与JavaBeans规范一致。然而SWT并没有很好的遵循这一规范。例如,在SWT的组件类中没有无参的构造器。每个组件都必须至少拥有一个单参数的构造器。这个参数就是父组件的引用。这意味着无论何时组件被创建,它都直接被添加到一棵组件树中。一个组件无法脱离于已注册的本地对等体而存在。这样,SWT就能让由编程者创建的组件在display的dispose方法被调用的时候自动被释放。

More on Resource Management更多在资源管理方面的内容

SWT的组件构造器策略可以排除某些内存泄露的可能性。AWT在资源管理方面也有类似的问题。但它采用了不同的方式解决。当AWT组件被创建的时候,相应的对等体并不会立即被创建。即便它被添加到一棵组件树,而如果这棵树还不可见,那么对等体仍不会被创建。只有当顶层容器被设为可见,这些对等体才会被创建。创建对等体的方法通常在addNotify中,它们通常递归地调用父组件的addNotify直到整棵组件树上的对等体都被创建了。当顶层容器由dispose方法销毁的时候,一个对应的方法removeNotify将会被递归地调用以释放这些对等体。这样,AWT在不由开发者介入的情况下管理了它的资源。

Event System事件系统

一个事件要求特定的动作被执行,它被作为消息由外界或系统自身发送给GUI系统。这些事件包括来自计算机设备如鼠标键盘和网络端口的I/O中断,以及GUI系统的逻辑事件触发,比如一个按钮的ActionEvent事件。

Single-Threaded vs Multiple-Threaded 单线程 vs 多线程

事件分发遵循两种不同的模型。单线程分发模型和多线程分发模型。

在单线程分发模型中,一个事件从队列中抽出并在同一个线程中被立即处理。事件处理后,紧跟着的下一个事件再被抽出并继续下一轮的循环。在多线程分发模型中,从队列中获取事件的线程启动另一个被称作任务线程的线程,并把事件交给它处理。而获取事件的线程并不等待处理线程的结束。它简单的获取下一个线程并分发它。

事件处理通常涉及应用程序的数据变化。而且这些数据经常是组件需要显示的。多线程分发很容易产生同步问题,它产生多个可能互相干扰的事件处理线程。在一个稳定的GUI系统中,组件应该能够保持视图与模型间的同步。由于同步问题的出现,多线程模型要求开发者拥有更多并发编程的经验。而对于普通编程人员,造成同步错误是很容易的。因此许多GUI系统并不使用这一模型。

单线程模型通过强制事件序列化地被处理提供了实际上的同步。AWT,SWT和Swing 都采用了这一模型来分发事件。但单线程模型也会有它自己的问题。其中之一就是线程专注。既然所有的事件都在一个线程中被分发,如果其中的一个事件的处理费时过久,将会拖延下一个事件的抽取和执行。如果有一个PAINT事件被延后,那么在屏幕上就会呈现为无法响应。这经常使用户感觉到软件很慢。许多这样的低效程序是由于开发者的经验不足造成的。他们的做法是将耗时任务填充到监听器方法中。由于这种错误的编程方式在Swing中大量被使用而尤为突出,这也是它慢而丑陋的坏名声的由来之一。实际上,如果你懂得使用线程,Swing应用程序可以表现出很高的响应度。

Thread Safety线程安全

上述问题的解决方案是启动一个单独的工作者线程来完成耗时处理,这样就能把事件分发线程释放处理以继续运作。如多线程模型中所做的那样,然而这同样会引入在多线程模型中出现的同步问题。许多GUI工具集都有自己先天性的机制来解决这一问题,例如,在组件树上的组合锁。开发者不需要为如何安全编程而操心。这样的工具集被成为线程安全的。AWT就是其中之一。

然而,由于不必要的同步使得建立这样的GUI系统过于负责并造成了额外的开销。因此,Swing和SWT被设计为非线程安全的,这意味着开发者必须谨慎地实现他们的多线程任务。SWT和Swing在运行时线程安全行为上有一个小小的区别。SWT总是检查改变组件的操作是否在事件分发线程上执行。这样,开发者就能够发现同步问题。而Swing不这样,这是Swing的一个不知之初,这其实并不难实现。

Event Dispatching Thread事件分发线程

AWT读取操作系统中的基本事件并在java代码中处理它们。AWT事件分发线程被命名为?AWT-{OS}-Thread。这个线程由AWT系统隐式启动。当AWT应用程序启动时,这个线程在背后启动,在操作系统上抽取和移除事件。当诸如按钮动作这样的逻辑事件被触发时,它传递给注册在按钮上的操作监听器。开发者也能为AWT组件编写鼠标,键盘和绘制事件的事件监听器。这通常通过扩展AWT Canvas组件来完成。这一组件支持了所有已提供的事件,而且你可以通过重写事件处理方法,实现一个自定义的组件。

然而,在Swing中,这是一个不同的线程。Swing把AWT事件作为自身事件系统的一个输入。它获取AWT事件并做一些初始化处理,产生一个对应的Swing事件并把它放到自己的事件队列上。Swing也有自己的事件分发线程,通常命名为EventQueue-0。这个线程从事件队列中抽取Swing事件,就如同AWT从操作系统中抽取那样。然后它把事件分发给目标组件。通常事件首先被分发给组件的顶层容器,然后由顶层容器的dispatch方法处理,它可能被再分发或重定向到一个Swing组件,在那里继续由自己的监听器进行处理。

例如,当一个鼠标移过一个JButton或JFrame时,一个指向JFrame的AWT事件在AWT线程上触发。AWT线程检查它是否需要作更多的处理,然后把它包装成一个Swing的MouseEvent对象并把它添加到EventQueue队列中。当获得MouseEvent事件后,EventQueue-0抽取这个事件并判断出目标Swing组件。这里,这个组件是JButton。然后它产生了一个包含相对坐标位置和事件源的新的MouseEvent重定向到这个JButton上,然后调用这个JButton的dispatch以继续分发。JButton的dispatch过滤事件给特定的方法最终实现由鼠标监听器在该点上的分发的点击。

SWT更类似于AWT。唯一的区别是它要求开发者显式地书写事件循环代码。然而底层的实现细节是不同于AWT的。看看SWT的读取和分发事件代码,它会让你想起MFC的代码风格。

Event Listener事件监听器

AWT,SWT和Swing都有相似的事件监听器模型。它们都使用观察者模式,组件和监听器的连接方式是把监听器添加到组件上,这组成了一个对象网络的模型。当事件被触发并分发给组件,组件调用它的监听器以处理事件。一个监听器也可以继续分发事件给后续的处理,或产生一个新的事件并把它广播到网络中的其他节点上。基本上有两种不同的广播事件方式。一种是同步调用监听器。另一种是异步地将事件发送回队列,它将在新一轮的事件分发中被分发出去。

除了直接发送给队列的方式,Swing还有一些其他的分发异步事件的方法。其中之一是调用SwingUtilities 或EventQueue 的invokeLater,这一方法包装一个Runnable对象到事件中并把它发送给事件队列。这确保了Runnable的run方法能在事件分发线程上执行,保证了线程安全。实际上,Swing的Timer好SwingWorker基于这一机制实现。SWT也有相应的发送异步事件的方式。它的invokeLater的对应方法是display.asyncExec,它以一个Runnable对象作为参数。

我从一个技术层面给出了他们优劣势上的一个清单,以结束本文。

AWT

AWT是Sun不推荐使用的工具集。然而它在许多非桌面环境如移动或嵌入式设备中有着自己的优势。
更少的内存。它对运行在有限环境中的GUI程序的开发,是合适的。
1.更少的启动事件。由于AWT组件是本地由操作系统实现的。绝大多数的二进制代码已经在如系统启动的时候被预装载了,这降低了它的启动事件。
2.更好的响应。由于本地组件由操作系统渲染。
3.从java 1.x时代就为JRE支持的标准GUI工具集,你不用单独安装它,你不用担心平台差异的问题。
4.成熟稳定的。它能够正常工作并很少使你的程序崩溃。

然而,事物都有它们不好的一面。让我们来例数它吧。
1. 更少的组件类型。表和树这些重要的组件缺失了。它们是桌面应用程序中普遍使用的。
2.缺乏丰富的组件特征。按钮不支持图片附着。这很明显是它遵循的设计原则造成的。
3.不支持Look And Feel。AWT被设计为使用本地组件。因此,它依赖系统来提供Look And Feel支持。如果目标系统并不支持这一特性,那么AWT将无法改变它的Look And Feel。
4.无扩展性。AWT的组件是本地组件。JVM中的AWT类实例实际只是包含本地组件的引用。唯一的扩展点是AWT的Canvas组件,你可以从零开始创建自定义组件。然而无法继承和重用一个已有的AWT组件。


SWT

SWT有如下优势:
1.丰富的组件类型。SWT提供了种类繁多的组件,从基础组件如按钮和标签到高级的表格和树。
2.相对的丰富组件特性。尽管SWT也遵循最大公倍数原则,它采用模拟的方式重新设计了对更多组件特性的支持。所以同AWT相比,它有着相对丰富的组件特性。
3.更快的响应时间。基于和AWT同样的原因,SWT组件包装了本地组件,由操作系统实现渲染。操作系统通常对渲染处理做了优化,保存GUI二进制代码为标准库,减少了内存的使用,提高了响应性能。
4.更少的内存消耗。既然操作系统为本地组件提供了优化,这一点就容易理解了。

不足之处:
1.不在JRE的标准库中。因此你必须将它和你的程序捆绑在一起,并为你所要支持的每个操作系统创建单独的安装程序。
2.不够成熟和稳定。SWT因其设计上的一些缺陷,如资源管理,Windows友好等,被认为是不稳定的。它可以在Windows上表现得很好,但在其他操作系统上,它经常是不稳定且容易崩溃的。这很大程度上是因为它把资源管理交给开发者来处理,而并不是所有的开发人员能够正确地处理这些。
3.在非Windows平台下的性能不高。如同第2点提到的,SWT被设计为与Windows API相协调的,这导致了在非Windows平台上的性能问题,糟糕的UI感官,不稳定甚至内存泄露。
4.无Look And Feel 支持。和AWT同样的原因。
5.不可扩展,和AWT同样的原因。在SWT中你可以通过有限的方式扩展一个组件,例如,监听PAINT事件并添加自定义绘图到组件上,但鉴于你只能控制绘制处理的一部分,这是十分有限的。你也只能在操作系统绘制完组件后补充,这并不能很好支持自定义。许多应用程序在自定义行为上有很高的要求。


SWING

Swing是三者中最强大的GUI工具集。它和另外两者相比同样有自己的优劣势。

1、丰富的组件类型。Swing提供了非常广泛的标准组件。这些组件和SWT一样丰富。基于它良好的可扩展性,除了标准组件,Swing还提供了大量的第三方组件。许多商业或开源的Swing组件库在开发多年后都已经可以方便地获取了。
2、丰富的组件特性。Swing不仅包含了所有平台上的特性,它还支持根据程序所运行的平台来添加额外特性。Swing组件特性遵循特定原则,易于扩展,因此能够提供较SWT和AWT更多的功能。
3、好的组件API模型支持。Swing遵循MVC模式,这是一种非常成功的设计模式。它的API成熟并设计良好。经过多年的演化,Swing组件APIs变得越来越强大,灵活和可扩展。它的API设计被认为是最成功的GUI API之一。较之SWT和AWT更面向对象,也更灵活而可扩展。
4、出色的Look And Feel支持。MVC设计模型允许Swing分离组件视图和它的数据模型。它有高级的UI委托来将UI渲染委托给UI类。这些类被注册到一个展现特定的Look And Feel的对象上。已经有上百个Look And Feel 可以提高各种各样的GUI风格。你甚至可以基于其他人的成果编写组件的Look And Feel 。
5、标准的GUI库。Swing和AWT一样是JRE中的标准库。因此,你不用单独地将它们随你的应用程序一起分发。它们是平台无关的,所以你不用担心平台兼容性。
6、成熟稳定。Swing已经开发出来7年之久了。在Java5之后它变得越来越成熟稳定。由于它是纯Java实现的,不会有SWT的兼容性问题。Swing在每个平台上都有相同的性能,不会有明显的性能差异。
7、可扩展和灵活性。Swing完全在Java空间中实现。它可以控制它所需要的一起。Swing基于MVC的结构使得它可以发挥Java作为一门面向对象语言的优势。它提供了许多扩展组件的方法。让我们来列举一下:
A.继承已有组件;
B.靠复合组件的方式扩展。
C.从零开始使用JComponent编写自定义组件;
D.使用渲染器和编辑器机制扩展复制的Swing组件,如JList,JComboBox,JTable,JTree等;
E.基于已有Look And Feel 或从零开始创建新的Look And Feel;
F.使用LayeredPane,GlassPane或拖放机制开发高级的组件,例如浮动的固定组件,自定义弹出窗口,自定义菜单等。

8、总体上良好的性能。Swing的速度是其为人诟病的一点。然而随着JRE的开发,Swing的性能如今已经有了很大的提高。特别是Java5之后,Swing的总体速度能够接近本地小控件系统。


一个GUI的速度总是从两个方面被衡量:响应时间和数据反馈时间。

响应事件指从事件任务出现到组件更新UI的这段时间。例如按下一个按钮,拖动一个组件,改变一个多标签面板等。在这个方面本地组件总能比模拟组件有更好的响应。AWT和SWT通常比Swing表现出更好的响应时间。然而事实并非总是如此。这取决于操作系统。如果本地组件没有被良好的实现,那结果就是相反的。例如Windows开发了不错的GUI库,而Linux平台通常差得较远。SWT可能在Windows上表现得比Swing好,而在Linux上表现得比Swing差。也就是说,AWT/SWT的性能决定于底层平台。随着JRE的开发,Swing的响应性能能够随着JVM的优化,更好的实现方式,以及图形硬件加速而得到长足的改进。在Windows上,Java6的Swing可以媲美SWT的性能。在非Windows环境中,Swing可以表现出更好的响应时间。

数据输送时间是指用于将应用程序数据传递给UI组件所需要的时间。例如,一个学生管理系统要求从数据库中装载学生信息并在一个表格中显示出来。花费在从内存到表格组件的数据传递时间被称为数据输送时间.在这个方面,Swing通常比其他二者的性能更好。或许当数据量不大的情况下并不明显。但当海量的数据被输送给表格的时候,这一点就显而易见了。为了理解这一点,提醒你注意JVM和本地操作系统是两个分离的运行时环境。由于JNI的调用在两个环境中跨越式地发生,通常比一个普通的Java调用花费更长的时间。通常这包含两个处理。一个是Java数据结构转换为本地数据结构,另一个是方法返回时的本地数据结构转换为Java对象。其他的性能开销暂时忽略不计。当一个大范围数组的数据从本地组件中输送过来,大量反复的JNI调用将极大地拖垮性能。

Swing的另一个优势是它有许多的组件模型以提高输送的性能。例如TableModel被映射为两个维度上的数组。这样,在Swing组件中甚至不需要进行数据方式的转换。Swing直接将应用程序数据显示在屏幕上,节省了在数据转换上所花费的事件。

Swing也有不足之处:

比AWT和SWT更多的内存消耗。Swing自己实现了所有组件。因此,它在运行时装载了大量的类。一些其他的问题来源于小的可变对象的创建,如Rectangle,Point,这些对象基于同步的考虑通常不可重用。Java在堆上创建所以对象。小的对象通常导致了额外的堆空间消耗。许多小的对象较之大对象更难以有效地被垃圾回收。因此,Swing应用程序通常无法及时回收大而小的对象。这种情况的普遍就会导致性能下降。

更多的启动时间。现在JVM已经快得多了。许多人甚至扬言它可以媲美C++的实现。但多数的Java应用程序还是看上去很慢。实际上,Java性能的很多问题来源于类装载机制。这是一个I/O操作,故而能够明显地降低Java应用程序的速度。也许这是每个动态链接系统中都要面对的问题吧。Swing通常包含了上千个Swing类的使用,在Swing应用程序可以显示它的主窗口之前,它比AWT或SWT装载了多得多的类。这严重降低了Swing的启动时间。这种问题也许会相对好一点如果Swing的类是以共享系统库的方式预加载的。

上述的比较总的来说是技术上的总结。相对其他方面的因素也会影响你对一个工具集的选择。例如,文档,支持,学习曲线和社区等,但既然我们关注的是技术层面,就不在这里讲的太多了。
-------------------------------------------------------------------------------------
1、AWT和Swing由sun开发,符合JAVA的跨平台原则,理念上更加支持移植;

2、SWT由IBM资助的eclipse团队开发,采用较为实用的用户体验原则,界面与各个操作系统平台更加接近;

3、AWT直接使用各个平台共有的图形界面控件,导致控件类型少,功能过于简单,实用性不强。例如:由于有一种平台的按钮没有图标,所有AWT的按钮就不能有图标,在所有平台上都没有;

4、Swing使用了最少的AWT控件,尽可能多的将控件用JAVA实现,在不损失可移植性的基础上,增加了很多的功能,但在操作系统的透明控件、非矩形控件方面有些力不从心;

5、SWT使用尽可能多的操作系统控件,在此基础编程上实现附加功能,优点是界面风格与操作系统本地系统非常接近,缺点是必须为每个操作系统单独开发控件,作者认为仅有微软windows等少数几个系统上的SWT较为好用。

-------------------------------------------------------------------------------------

AWT的优势在于,简单,稳定,兼容于任何一个java版本。也支持GUI组件的自动disposal。同时也是线程安全的。在AWT 中的图形用户界面是通过本地方法来实现的,每个AWT 方法都有一个与其对应的本地方法,称为peer。由于平台无关性的需要,AWT 所能够实现的功能是各种不同操作系统的图形库所提供的功能的交集。

而SWING,则是为了解决AWT的很多缺点。SWING 提供许多比AWT更好的屏幕显示元素。它们用纯Java写成,所以同Java本身一样可以跨平台运行,这一点不像AWT。 它们是JFC的一部分。 它们支持可更换的观感和主题(各种操作系统默认的特有主题),然而不是真的使用原生平台提供的设备,而是仅仅在表面上模仿它们。这意味着你可以在任意平台上使用JAVA支持的任意观感。 轻量级元件的缺点则是执行速度较慢,优点就是可以在所有平台上采用统一的行为。

Eclipse项目用称为SWT的的图形库和工具包取代了Java标准中的AWT和Swing。SWT直接调用了操作系统的图形库,从而使得Java应用程序的Look & Feel 与操作系统的习惯完全一致;更为重要的是,对本地方法的直接调用大幅度的提高了基于SWT 的Java应用程序的运行速度。SWT 的缺点主要在于两点:
(1) 不是Java语言标准
(2) 支持的平台太少

...... [阅读全文]

  让我们从简单的 HelloWorld 应用程序开始。

  一、将SWT添加到工程的类路径中

  首先建立一个java工程。在开始使用SWT之前,需要将SWT库文件添加到工程的类路径中。步骤如下:

  1. 下载SWT。在Eclipse SDK的下载页面中,提供了独立版本的SWT下载。找到标有SWT Binary and Source 的栏目。下载适合你操作系统的版本,不用解压,直接保存到硬盘中。

  2. 在Eclipse菜单栏,选择File -> Import...打开导入向导

  3. 选择Existing Projects into Workspace ,点击Next按钮

  4. 选择 Select archive file并使用 Browse...按钮来找到你刚才下载的SWT文件。

  5. 点击Finish按钮,完成SWT导入。

  6. 右键点击你建立的工程,选择Properties 来打开Properties对话框。

  7. 选择 Java Build Path tab并点击Add按钮 -> Projects

  8. 选择 org.eclipse.swt工程, 点击 OK,完成添加SWT库到你的工程中(见图1).


图 1


  二、 SWT 代码

  现在在你建立的java工程中,新建一个java文件,取名为 HelloWorld。在HelloWorld.java文件中把main()方法覆盖为以下代码:

public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
shell.setText( " Hello World " );
shell.setBounds( 100 , 100 , 200 , 50 );
shell.setLayout( new FillLayout());
Label label = new Label(shell, SWT.CENTER);
label.setText( " Hello World " );
Color red = new Color(display, 255 , 0 , 0 );
label.setForeground(red);
shell.open();
while ( ! shell.isDisposed()) {
if ( ! display.readAndDispatch()) display.sleep();
}
red.dispose();
display.dispose();
}

  注:

  在覆盖了上述代码后, 选择菜单栏中的 Source -> Organize Imports命令 (或者按Ctrl+Shift+O) 来把需要引用的SWT包导入到HelloWorld.java文件中 。

  以下是对各行代码的详细解释:

  第2行:每个基于SWT的应用程序都有一个Display类的实例。用来将低层平台和SWT进行链接。除了管理SWT的事件循环,还能访问SWT需要的平台资源。在16行,display实例将会提交给垃圾收集器。

  第3行:每一个窗口都有一个Shell窗口框架,来与用户进行交互。Shell像所有的windows系统一样来处理动作行为,并作为窗口控件的放置场所。

  第4行: setText()方法设置窗口的标题.

  第5行: setBounds() 方法设置窗口的大小和放置的位置. 在这个例子中, 设置窗口为200个像素宽,50个像素高,并放在离屏幕的左上角100x100像素的位置上。

  第6行: setLayout()方法 设置窗口框架的布局. FillLayout,充满式布局管理器,使得组件大小会尽量的充满整个容器.SWT的布局管理器会在以后详细介绍。

  第7行:在shell上新建一个简单的label组件并居中显示label的文本内容。

  第8行: setText() 方法 设置label的文本内容。

  第9行:创建一个红色的颜色类的实例。你也可以使用以下语句获得系统红色的实例:

  Color red = display.getSystemColor(SWT.COLOR_RED);

  第10行: setForeground() 方法 设置label的前景色

  第11行:到目前为止,窗口框架还是不可见的。通过open()方法使得窗口可见。

  第12行: while语句循环检测窗口有没有关闭。

  第13行:display 控制事件的循环. readAndDispatch() 方法从平台的事件队列中读取事件,并分配他们到合适的处理程序(接收者)。只要队列中一直有事件可以处理,这个方法一直返回true,当事件队列为空时,则返回false(因此允许用户界面UI线程出于sleep状态直到事件队列不为空)。

  第15,16行:当循环检测到窗口被关闭时,需要将color,display和一些相关联的平台资源释放。注意到系统颜色实例(colors)将会被提交释放。

  二、 运行这个例子

  通常情况下,为了启动一个java应用程序,会使用Run As -〉 Java Application 命令。在这里,如此运行将会抛出 UnsatisfiedLinkError 异常,说明没有找到 SWT 的本地库。如果运行 Run As > SWT Application 命令,将会弹出 SWT 启动配置窗口,见图 2 ,在图 2 中可以点击 run 按钮。


图 2


  点击 run ,运行结果图 3 。


图 3

...... [阅读全文]

  可以使用标准窗口小部件工具箱(Standard Widget Toolkit,SWT)和 JFace 库来开发用于 Eclipse 环境的图形用户界面,而且还可以将它们用于开发单独的 GUI 本机应用程序。在本文中,我将介绍一些基本的 SWT(基本 GUI 对象的名称)类型,并展示如何综合使用它们来创建有用的应用程序。

  关于 Eclipse、SWT 和 JFace

  正如 Eclipse 的 Web 站点上所提到的,Eclipse 是一种通用工具平台。它是一个开放的、可用于任何东西的可扩展 IDE,没什么特别之处,它为工具开发人员提供了灵活性以及对软件技术的控制。

  Eclipse 为开发人员提供了生产大量 GUI 驱动的工具和应用程序的基础。而这项功能的基础就是 GUI 库 SWT 和 JFace。

  SWT 是一个库,它创建了Java 版的本地主机操作系统 GUI 控件。它依赖于本机实现。这意味着基于 SWT 的应用程序具有以下几个关键特性:

它们的外观、行为和执行类似于“本机”应用程序。
所提供的窗口小部件(widget)反映了主机操作系统上提供的窗口小部件(组件和控件)。
主机 GUI 库的任何特殊行为都在 SWT GUI 中得到反映。
  这些目标使得 SWT 不同于 Java 技术的 Swing,Swing 的设计目标是消除操作系统的差异。

  SWT 库反映了主机操作系统的基本窗口小部件。在许多环境下,这种方法太低级。JFace 库有助于向 SWT 应用程序中添加大量服务。JFace 并没有隐藏 SWT,它只是扩展了 SWT。正如您将在这一系列的后面部分中看到的,SWT 最重要的扩展之一是,将应用程序的数据模型与显示及更改它的 GUI 隔离开来。

  在开始之前,我需要介绍一些 SWT 术语:

Widget —— 基本的 SWT GUI 组件(类似于 Java AWT 中的 Component 和 Swing 中的 JComponent)。Widget 是一个抽象类。
Control —— 拥有操作系统的对等物的窗口小部件(换句话说,在操作系统中具有同一身份)。Control 是一个抽象类。
Composite —— 包含其他控件的控件(类似于 Java AWT 中的 Container 和 Swing 中的 JPanel)。
Item —— 其他控件包含的窗口小部件(该控件可能不是复合控件),比如列表和表。注意,包含一些项的控件很少包含其他控件,反之亦然。Item 是一个抽象类。
   这些窗口小部件被安排在继承层次结构中。参见图 1、图 2 和图 3,了解它们是如何安排的。在图 2 中,Basic1 类是来自本文的类,而其他所有类都是标准的 SWT 窗口小部件。


图 1. SWT Widget 树


图 2. SWT Composite 树


图 3. SWT Item 列表


  注意,Eclipse 具有跨平台特性(因此可以在许多操作平台上运行),本文基于 Eclipse 的 Microsoft? Windows? 版本。因此,本文包含的每个例子都应该能够不加任何更改地在其他平台上使用。还要注意的是,本文是基于 Eclipse V3.0 的。Eclipse V3.1 中添加了少许 GUI 窗口小部件类型和特性。

...... [阅读全文]

博客订阅

feedsky Technorati Join My Community at MyBloglog!
抓虾 pageflakes
Rojo google reader
netvibes my yahoo
newsgator bloglines
鲜果 哪吒
有道 分享到饭否

标签云集

Heartnn@饭否

日志归档

最新日志

最新评论

我的收藏夹

门户
技术
游戏

关注者