XWT 是一个我们需要重点关注的项目

我们只是在这里探讨一下 XWT 的设计（快过年了，休息一下，来坐而论道），并不是推荐大家明天就用起来。如果要用起来，中文问题是首先要解决的问题，我还没有做相关的测试。

刚才我试验过，XWT 现在就已经可以完全不依赖于浏览器了。为什么作者要使用 gcj 来编译，有几方面的考虑。首先 gcj 可以编译出来真正 native 的代码，可以提高运行时的性能。其次 gcj 现在在几乎任何平台上都可以使用。与 XAML、XUL、Flash 这些 Rich Client 的解决方案不同，作者这套 Widget 库是为 Thin Client 而设计的，因此其设计是很轻的。作者的意图可能是想让这些应用可以运行于手持设备（PalmOS，etc.）之中，因此使用 gcj 编译为 native 的代码就尤其重要了。

这两天研究 XWT 有一个副产品，在 Readonly 的帮助下，我搞清楚了如何用 Java 来调用 COM/ActiveX 的功能了。就是使用 JACOB 这个开发包来做这件事情，完全可以不使用 M$ 的 JVM 和 SDK 的。
http://danadler.com/jacob/
我使用 gcj 进一步将 JACOB 编译成了 native 的代码，并且做成一个库文件，可以和 gcj 编译的 native 应用程序连接。经测试可以正常调用 COM 的功能（调用 Excel 的 COM 控件的功能）。感兴趣的朋友可以和我联系。

gcj for win32 最新的版本（3.4.2）已经可以正常地做字符集转换了，就是以前我说的使用 iconv 的功能来做转换。gcj 编译的时候可以加
--encoding=GBK 的选项，现在支持中文已经没有任何问题了。

关注ing, 期待更多信息！

thx dlee，用JACOB比DW上介绍的IBM的RJCB简单，不过RJCB还支持从com调用java接口

让人热血澎湃，支持并努力着！！

我连DEMO都看不了，一直是XWT is loading; please wait...

这年头，这个东西做出来的东西要适合每台电脑，万一哪天在某台电脑上出不来，便会出来个牛人喊，看！XXX就是BUG多，该淘汰了！

不是很明白为什么不能用ActiveX控件或者XSLT来在IE里解释XUL？我觉得这是一个很可行的途径。

帮规第 7 条，指名道姓要求别人的帮助的，杖责 30。:evil:
目前仅仅是我的另外的一个新玩具，我不负责义务提供技术支持的。
建议：
1、学习 gcj 如何使用。方法：本论坛内搜索，然后再去 Google。
2、看懂附件这个 Makefile。当然前提是你知道 Makefile 究竟是什么东西。

这个 Makefile 中，需要把 gcc_path 改掉。
源代码自己到 sourceforge 上面去找。

自己没有能力解决问题的，还是不要玩了。这个可是另外一个吹着笛子的恶魔哦。

眼睛不要只盯着 IE，其实这个世界很大的。
不要光说说，自己去做一遍就知道是否可行了。

没错，可是IE毕竟还占着浏览器90%的市场份额，大部分客户都不知道还有别的浏览器。让他们安装一个Firefox与安装一个客户端感觉上没什么区别 。我觉得XUL + RDF是一种相当优秀的UI解决方案，简单易学、功能强大，可以和Web Service很好地结合，更重要的是背后有整支Mozilla团队的支持。它眼下最大的问题只是受到了Firefox的局限，被微软抵触。只要能解决IE不支持这个问题，发展潜力是相当大的。而XWT已经很长时间没有更新了，我对原作者能否坚持下去表示怀疑。

至于XWT应用能直接编译成exe文件，我个人以为意义不是特别大。我认为浏览器日后发展的方向实际上就是一个UI的容器，主要负责把UI描述资源里的内容体现出来，形成统一的UI组件、风格和布局支持（如javascript、css等技术），并提供安全性支持（如cookie等技术）以及服务访问支持（如http、ftp、https、activex、applet、xmlhttp等技术）。离开了UI的容器（就是浏览器）以后的XWT应用从使用上说已经和常规的客户端应用已经区别不大了，相应的却未必能体现出传统客户端应用对计算机控制能力强的优势。



我从接触到XUL开始一直有这个想法，可惜一直挤不出时间，唉 。有些时候觉得在中国当研发人员其实很可怜，平时都在赶项目，没有太多时间真正研究点新的不成熟的技术；等到新的技术成熟了项目要用上了，又得挤时间去学习，永远处于这种追赶状态中 ，不知道各位牛人有什么好的办法没有？