Loonframwork到SWT的移植测试（JAVA GAME TEST SOURCE）

愚以为，用SWT作界面，是一种在用Java写VB的体验。

本周心情极度恶劣，一直不想说话，也不想写新代码，郁闷中尝试了一下将Loonframework的代码移植到SWT。（其实我觉得AWT,SWT,Swing用那个真的要根据需求决定，没有绝对的好与坏。）






(用SWT操作WINDOWS界面确实异常简单)

如 预料般，由于Loonframework以AWT白板为基础采取绘制开发，核心代码在SWT上近乎0修改。而借助于 org.eclipse.swt.awt.SWT_AWT，更是完全不用任何变更，因为SWT提供了SWT_AWT.new_Frame方法，而我在 Loonframework中是以.setup(Frame frame)[以及.setup(Applet applet)]方式等将图像描绘在指定窗体上的，所以能无差别使用。顺带一提，有SWT_AWT而无SWT_SWING，可见IBM对Swing的歧 视。（由于JFrame直接继承自Frame，当然也可以加载Swing的界面，但是那个效率啊……）

其实某些人因支持Swing而反 SWT的，或因SWT而反对Swing的做法，感觉真的没什么意义。愚以为Java体系，一脉相承，没有可能你基础很牢固，而对新的Java技术却牛不入 耳，一窍不通。我并不认为会象某些人想象的那样，研究两天没多少人理的Java GUI开发，我做J2EE方面就弱了。事实上，我本是J2EE程序员，业余研究一下游戏开发罢了^^。比如现在，我以爹不痛娘不爱的AWT为基础开发 Loonframework Game包，在转换底层时反而如鱼得水，完全不存在移植问题。（当然，日后向手机移植改的就比较多了。）而事实上，由于Swing以AWT为底层，而 IBM则以一直偏爱的AWT方式构建SWT，也决定了以AWT为基础开发的代码在Java GUI上通用性是最好的（我是说代码通用，而不是指UI通用……）。

顺便提一下，单从支持[&键名]这种定义快捷键的写法和支持 ico图标看，SWT就可说是Java中的怪胎，或者说它到底有多少算Java都要打个问号，我愚昧的认为把SWT技术彻底用在其他语言上可能表现得更 好，真的说起来，还是C#做GUI更容易些……我就一新人菜鸟，有什么认识不对的地方，还望中国亿万万高手（专家）或自诩高手（专家）的同志们谅解。