Loonframwork到SWT的移植测试(JAVA GAME TEST SOURCE)

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

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

Loonframwork到SWT的移植测试(JAVA GAME TEST SOURCE)_第1张图片

Loonframwork到SWT的移植测试(JAVA GAME TEST SOURCE)_第2张图片

Loonframwork到SWT的移植测试(JAVA GAME TEST SOURCE)_第3张图片
(用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更容易些……我就一新人菜鸟,有什么认识不对的地方,还望中国亿万万高手(专家)或自诩高手(专家)的同志们谅解。

你可能感兴趣的:(source)