望江门外——谢穷的Blog

分享别人的经典 不如自己缔造经典

  BlogJava :: 首页 :: 联系 :: 聚合  :: 管理
  6 Posts :: 1 Stories :: 1 Comments :: 0 Trackbacks

1.2.2 新贵:SWT/JFace

    Eclipse的设计者注意到了Swing的灵活性和其执行问题。他们想要一个套件可以确保Java的用户可以象使用操作系统一样运行一个桌面程序。在实际上,他们是如此之迫切需要,以至于他们编制了他们自己的类库:SWT JFace

无论SwingSWT/JFace都会产生一个基于Java的平台无关的GUI,但他们的实现方法又是迥异的。

    SWTJFace的最显著的特征是其介入了直接调取操作系统,使用底层平台的重量级组件,而不是自己重建。这一决策使得SWTJFace的表征和运行速度接近于地层平台,在下一章我们会就此展开更为深入的讨论。当然在此的短暂描述也是有所裨益的。

    由于当初Java的初创者一开始就意识到Java应用程序最总会需要使用到传统代码或是操作系统,所以他们提供了从Java类内部去调取其他语言(如CFortran)调取过程的类库。

     SWT/JFace依靠JNI来管理操作系统的渲染而不是由其自己来实施。

     SWT/JFace的资源管理

     SWT/JFace的另一个重要特性就是其不依赖于垃圾自动回收机制。一开始,这很容易让人以为这会产生错误代码。然而,你只需在接触到操作系统资源是加以小心,一般不会出现重大问题。Eclipse决定将AGCSWT/JFace中移走主要有两方面的原因:

    1) 内存自动分配的过程在程序运行时是不可预测的,没有任何征兆说明资源何时被释放(可得),当处于分配过程中时,如果异常情况发生,则过程就可能无法关闭。如果你仅是在处理一些简单数据结构时,可能这是小事一件。但,如果是在处理一些大型的图形程序时,内存的分配和回收就是不得不要小心谨慎对待的重大问题了。

    2)对操作系统资源使用AGC是困难的,由于Swing在高端层次建立了其轻量级的组件,所以这还不成为一个问题。然而,如果在低端层次如SWT小部件同样去使用自动回收机制,那么在跨平台环境下错误的易发性和不确定性将会是个灾难。如果要花费太多的时间去清理对象,那么内存泄漏问题就会拖垮程序;或者如果这些资源是以一种错误的方式来释放资源的,那么整个操作系统也要跟着倒霉(宕机)了。

    为了预防此类与对象自动回收机制相关联的错误的发生,SWT/JFace让你自己来自主决定何时释放资源。这一工具套件通过其组件类中内置的dispose()方法来简化这一处理过程。同时,一旦你释放了某一父(上级)资源,其子(下级)资源也会被自动释放。

    在以后的章节中,你将看到这意味着在大部分的应用程序中几乎不需要直接的内存释放的必要。你也可以以半自动方式来调取SWT/JFace来管理内存。

    设计和开发的简化

   swingGUI是以模型代理架构产生的,由此会对GUI的每一个组件产生不同的对象以表征其不同的特性。但这一复杂方法不是任何情况下都适用。对于那些刚开始起步学习构建按钮、标签的新手来说不需要如此复杂。而在其他的极端情况下,程序员在构建复杂的图形编辑器和计算机辅助设计工具是,需要与GUI功能更多地分离,以取得不同的试图和设计模式。?

     SWTJFace对其组件的设计架构没有强加任何规则,这意味着你可以随心所欲地极端复杂化地或是极端简化地构筑你的GUIs。因为Eclipse极易扩展,同时其源代码又是开放的,你可以随你所愿地添加工具或作修改。事实上,已经有大量的插件为SWTJFace组件的MVC封装而开发出来了。

 

1.2.3 SWT/Swing之争

    随意在网上搜索一下SWTSwing,都会看到关于这两者孰优孰劣的热烈争论。这一论战是毫无必要也是没有实际意义的。SWT是作为Swing之外的另一选择而产生的,而不是为了去替代Swing。我们撰写本节的目的并不在于褒扬某一工具较另一工具有优势,而是为了解释说明如何运作,为何运作的一种机理。在Java开发者中的这种争斗只会伤害到为构建自由的平台无关的应用程序的热忱。这世界给予了SWTSwing同样广阔的天地,我们希望这两大阵营求同存异,共创Java社区的大同世界。

 

1.3 SWT/JFace的许可证和支持平台

    在正是开始编写代码之前,我们很乐意谈及SWTJFace开发应用程序的两个要点:第一、如同在通用公共许可协议中概要的那样,Eclipse和其开发库的条件(?)太缺乏,当你在考虑开发商业应用程序时很重要;第二、需要关注EclipseSWT/JFace当前所支持的平台。

 

1.3.1 CPL通用许可协议

     Eclipse软件基金会是在CPL框架下向公众发布Eclipse的。这一许可协议和开放源代码组织的许可协议方案是完全兼容的,并且通过授权免特许权使用费的代码允许作完全的商业使用并可以在全球范围内再发布。这意味着任何人可以使用源代码,修改源代码并且销售其最终产品。

   虽然某些平台部件是在特殊许可条件下发布的,但是由于整个SWTJFace是在CPL框架范围内的,所以这使得在全部可支持平台内开发商业SWTJFace应用程序成为了可能。

 

1.3.2 支持平台

    在撰写本书时,在不少平台上都已经开始支持SWTJFace开发了。因为其依赖于特殊的窗体功能,因此在某些平台需要多个SWT应用实施。表1.1列举了支持SWTJFace的操作系统和用户界面。

   linux操作系统中,尚不能支持KDE,然而但是如果在KDE系统内安装有GTK的运行库,那么SWT/JFace应用程序同样可以运行在KDE桌面。由于KDE是构建在Trolltech Qt套件基础之上的,而Qt套件的发布许可协议比CPL有着更多的限制。如果在将来开发了一个KDE版本的SWT类库,那么现存的所有的SWT/JFace应用程序就可以支持它,并继承获得KDE的原生的外观。

     SWT还有一个秘密武器就是其对微软Pocket PC 2002系统的支持。SWT发行版提供了对于基于StrongARM体系处理器的Pocket PC 2002Smartphone 2002设备的支持。正是由于SWT的极大灵活性,使得Pocket Pc版本的SWT可以运行于大家熟知的J2SE(标准Java)和J2SE连接首先设备配置的嵌入式设备上。关于和IBM J9虚拟机相联系的如何在CLDC上构建SWT库的问题不在本书讨论范围之内。详情可见Eclipse基金会新闻组的网址:news://news.eclipse.org/eclipse.platform.swt

    对于Windows平台的支持还有一个预想不到的好处:你可以在SWT容器小部件内直接嵌入ActiveX控制。Eclipse平台使用这一工具方式嵌入微软网页浏览器控制来获得嵌入的网页浏览功能。你可以在附录B的“在SWT/JFaceOLEActiveX”中获得更多的关于ActiveX的技术细节。

     Table 1.1 SWT/JFace支持的平台

     Operating system User                                   interface

     Windows XP, 2000, NT, 98, ME                        Windows

     Windows PocketPC 2002 Strong ARM                Windows

     Windows PocketPC 2002 Strong ARM (J2ME)      Windows

     Red Hat Linux 9 x86                                       Motif, GTK 2.0

     SUSE Linux 8.2 x86                                        Motif, GTK 2.0

     Other Linux x86                                             Motif, GTK 2.0

     Sun Solaris 8 SPARC                                       Motif

     IBM PowerPC                                                Motif

     HP-UX 11i hp9000 PA-RISC                              Motif

     QNX x86                                                      Photon

     Mac OS                                                       Carbon

 

1.4 The WidgetWindow

    学习SWT/JFace工具套件的最佳途径就是通过使用器类来构建GUIs。有了这种倾向性的意识,我们将努力以一个扩张性的项目来触及SWT/JFace开发的各个不同方面。最先,我们需要构建一些激动人心的东西,如一个web驱动的数据库显示。

    但细一考虑我们又觉得不妥,因为这样一来我牵涉到太多无关的代码,这无形之中给了读者一个不小的负担。

因此,我们选择了一个简单的应用程序来合成尽可能夺得GUI元素,以此来减少代码数量。我们认为选项卡折叠器对象(在第三章我们会详细讨论)是在本书中演示用的最简洁的方式。然后在书中接下来的每一章,然后我们就可以一个新的添加含有该章的主题内容选项卡。图1.4展示了一个设计好的程序的全部,我们称其为小部件窗口。

    小部件窗口的开发有着诸多功效。当然,表面上看它仅是一个简单的应用程序集成有SWTJFace类库不同的组件。另一方面,它事实上是给了你一个可重用的SWTJFace代码的知识库。由于它是一个多类单一项目,相对于单一类多库,小部件窗口可以确保你可以在你自己的用户界面中重用它的每一个部份。

   1.4 小部件窗口应用程需这一扩张性的项目将会集成本书中谈到的每一个GUI和图形组件。

 

1.5 小结

     SWTJFace类库对于构建用户界面是高效的,但对于它们自己而言,它们并不能作任意简化。就像在其他工具套间中一样,还是需要定位和操控诸如按钮、容器、标签和菜单等。好在,这一工具套件背后蕴涵的哲学使得其具有革命性。

     SWTJFace或许并不完全遵循Java意识形态的各项规则,但通过其假疏丝组织的发展,它比Java在更大程度上贯彻和实践了开放源代码软件的宗旨与目标。

     SWT/JFace不仅无需要任何的许可证或是授权,还允许你程序员可以基于它作开发并收取费用。如果你开发了一个新的操作系统并且需要一套开发工具来吸引程序员到你的平台上来,那么你所需作的就是为你的系统适当裁减SWTJFace。如果你正在构建一个新的编程语言,并且不满足于简单的行命令或是连接,那么带有SWTJFaceEclipse平台对于你的任务来说是相当合适的。

 

   java开发者们在争论相较与其他套件SWT/JFace的优点时,他们事实上仅考虑到当前或者时接下来6个月的能力。这一思维定式忽视了SWTJFace的这么一个事实,就是:象Eclipse一样,因为有着来自全球的公司的、个人的贡献,EclipseSWT/JFace的发展几近于一个流行市场。如果在将来继续积聚开发人员的大量时间,

SWTJFace就可以象它正在进行的革新一样,唾手可得取得胜利。

    历史上,软件开发始终未能成为IBM的强项,但我们对于IBM的这种通过向开放源代码贡献力量来提升IBM硬件价值的理念心存感激。

     EclipseSWT/JFace的自由和灵活性以及其开发人员的激情,使得我们有理由相信这一工具套件会在今后数年内不断助益开放源代码开发社区。

    闲语少说,我们开始我们的编程吧
posted on 2011-05-19 09:54 望江门外 阅读(331) 评论(0)  编辑  收藏 所属分类: SWT/JFace in Action

只有注册用户登录后才能发表评论。


网站导航: