常规FAQ
三、 有技术支持吗?
没有官方的技术支持, 但是邮件列表可以给你很大帮助,很多人都说wxWidgets 的技术支持比很多商业软件都好.很明显,虽然没有任何担保,但wxWidgets 的开发者们都是非常热心的以最快的速度修复Bug。
四、谁使用wxwidgets ?
许多组织-世界各地的商业机构,政府和学府。因为可以有很多不同的途径来获得wxwidgets,我们不能监测分布状况,所以无法估计真正的用户数量。
参见
用户页,列出了一些用户和他们写的应用程序,还有
反馈页面,有一些评论。
我们的资历最高的用户,是业界资深的、Lotus公司的创建人Mitch Kapor和他的
Open Source Applications Foundation.。
五、wxWidgets 都支持哪些操作系统平台?
Windows 95/98/ME, NT, 2000, XP, and Vista.
Linux 和其他包含 GTK+ 的 Unix 平台.
包含 Motif 或 较少的Motif免费克隆版 的 Unix.
Mac OS X 10.3 和更高的版本 (10.2 和2.6版本(应该是指wxWidgets) ).
嵌入式平台的支持情况正在研究, 参考
wxUniversal 工程.
支持OS/2 的接口正在开发完善中, 你也可以把 wxWidgets 针对 OS/2上的GTK+或Motif 进行编译.
六、
wxWidgets 通过什么方式支持平台独有的特性?
这是开发者之间争论很激烈的一个论题. 我自己的观点是: 尽可能的保证它(wxWidgets)的平台无关性, 但是允许少数的类(函数、窗口样式)是某些平台所独有的. 比如,在windows平台上,图元文件和任务栏图标有它们自有的类, 其他平台就没有这些类. 因为这些类已被提供并且兼容于wxWidgets, 编写应用程序的程序员添加对某些功能的支持是非常容易的,不需要在编码上花费太多努力,但是其他平台下却不是这样. 此外, 一些由于平台特性而产生的类, 比如与 MDI 有关的那些类, 在其他平台上已经有了仿真的实现. 我可以想象在某一天,连 wxTaskBarIcon 这样的类都可能会在 Unix 桌面版上面实现.
换言之, wxwidgets 不是按照"最低共同特征"设计的,但使用核心API仍可以写出可移植的代码。禁用那些平台特有的类是一个愚蠢的做法,这将会失去许多潜在用户,并且会引起这么一种感觉:象wxWidgets这类的工具包是达不到今天设计日益复杂的应用程序的要求的。
目前,象位图、图标这类的资源都是用具体平台特有的的方式处理的,但是我们都希望用适当的手段去减少这种平台依赖。
wxwidgets不是'最低共同特征'工具包的另一个原因是:针对在某些平台下没有的功能,已提供通用的、独立于平台的代码,如wxtreectrl和wxlistctrl类。
七
wxWidgets使用了STL(标准模板库)、标准的字符串类了吗?
没有。这是一个广为讨论的话题,这个话题(不止一次的)得出了最终结论:避免使用模板对wxWidgets来说是最有利的方式。并不是所有的编译器都可以充分的支持模板,因此(如果使用模板的话)将会大大的减少wxWidgets可以支持的编译器和平台。同时,使wxWidgets依赖于另一个大型的类库,并且需要另外的下载和安装这个类库,是不可取的。此外,使用模板将使可执行程序体积变大,而这正是wxWidgets所极力避免的事情。
标准的C++字符串类也没有使用,原因是并非所有的编译器都支持它,并且它也未必是一个非常高效的实现(字符串的)方式。同时,我们能够修改我们自己的字符串类,这样就可以有更大的灵活性。与标准字符串类的一些兼容性已经被加入wxString中。
这并不妨碍应用程序为了完成自己的目标而使用模板和标准字符串类。在wxWidgets的调试开关打开的情况下,如果包含了STL的头文件,你可能会发现编译有错误。你可以通过关掉内存检测,或是在包含STL的头文件之前把如下内容添加到一个头文件里来通过编译:
#ifdef new
#undef new
#endif
八
wxWidgets(框架)里面是否有丰富文本编辑、标记的控件?
目前来说(实现你的目的)是可能的:
*请参考:
http://www.scintilla.org ,这里有一个非常好的语法突出显示的文本框组件。罗宾邓恩为这个组件写了一个wxWidgets封装,你可在wxWidgets 的发布中找到,在contrib/src/stc路径下。
*如果你仅仅是需要显示带有标记的信息,而并不需要编辑它,那么wxHTML可以满足你的要求。wxHTML内建在wxWidgets框架里,请参阅参考手册里的详细介绍,和samples/html路径下的例子程序。
*其实Win32和GTK+都有RichEdit组件,但是目前还没有对应的wxWidgets封装(但是文本框的属性函数正在被添加进 wxWidgets 2.3.x 系列中)。
九
wxWidgets编程中怎么使用C++的异常处理?
很遗憾的是wxWidgets库本身不是“异常安全”的(因为wxWidgets的最初版本的出现远远的早于C++语言添加异常机制的时间)。然而在你自己的代码中仍然可以使用异常机制,并且可以使用其他用异常机制来报告错误的库和wxWidgets协同工作。
然而,有几个问题是要记住的:
* 你不能让“异常”传递到wxWidgets的代码中,尤其是,你应该捕获这样的异常:被事件处理函数调用的函数抛出的异常,你应该在事件处理函数内部就捕获它,这样才能避免“异常”被向上传递到wxWidgets的代码中。
(个人注解:如果在一个函数中异常没有被捕获,那么异常是沿着函数调用栈一直向上传递的,直到被捕获、处理为止,如果整个栈都没有捕获,那么要传递给系统的全局异常处理函数来处理。)
*考虑到wxWidgets本身不使用异常处理机制而且开启了编译器对异常处理机制的支持将会使库的编译后体积膨胀10%至20%,因此少数编译器本身默认是不打开对异常处理机制的支持的,这就需要你去手动的打开这个开关来保证你能够处理异常。此外,对于gcc编译器(或者至少是mingw版本),你必须开启RTTI(Run-Time Type Identification运行时类型识别)以保证你能够使用异常处理,所以当你配置库的时候你需要这样配置: --disable-no_rtti --disable-no_exceptions (注意,这是双重否定)。
十
wxWidgets是怎样开发的?
我们使用SVN系统来开发和维护wxWidgets。这个系统允许我们修改代码并且及时的把修改后的代码上传到服务器上,其他人可以通过这个服务
器来升级他们的wxWidgets源代码。
想要编译从SVN获得的代码,请参考wxWidgets的发布目录的根目录下的BuildSVN.txt。
十一
wxWidgets是怎样发布的?
你可以从我们的下载页面下载wxWidgets。如果大胆一些,你可以直接从SVN上获取源代码。
十二
wxBase是什么?
wxBase是由无界面的类组成的一个wxWidgets子集。它包括wxWidgets的容器和基本数据类型类(包括wxString,wxDateTime等等),还有对操作系
统的有效封装,比如文件处理,进程,线程,套接字等等。除了少数例外的情况,wxBase和wxWidgets的基本用法是一样的,但是wxBase的运行
不要求GUI,所以用来创建控制台方式或服务器程序是一个理想的选择。创建一个可同时编译为控制台应用程序(使用wxBase)或图形界面应用
程序(用包含全部特性的wxWidgets接口)的程序也是可以做到的。
十三
wxUniversal是什么?
基于wxUniversal的接口和其它接口(像wxMSW,wxGTK+,wxMac)的主要区别在于:wxUniversal自身实现了 wxWidgets 的所有控件,这就提供了
更多了灵活性(比如,甚至在MS Windows下支持主题)。
这同时也意味着现在要把wxWidgets移植到一个新的平台上要容易多了,因为只须移植那些底层的类,而它们只占wxWidgets类库的很小一部分。
你可以从
这里得到wxUniversal的更多信息。
十四
Java怎么样?
Java已经降温了
人们逐渐意识到,它不能满足所有的跨平台开发的需要。
我们并不认为Java 将来会是一个主要威胁,人们对wxwidgets感兴趣的程度比以往任何时候都高。
十五
.NET/Mono怎么样?
微软为推动 .NET 的发展花了很大力量,.NET是编程语言、API、网络服务组件的集合。Ximian 开发了一个开源版本的.NET,主要是用在linux 下。C#是微软推出与java 竞争的产品,它在很多方面类似于java,比如“托管代码”、“垃圾回收机制”等等。
以上这些特性也许会对开发者有很大吸引力。但是绝不会因为有.NET/Mono的存在,就使wxWidgets失去了存在的价值。请留意一下下面这些观点,出自Julian的独到见解:
1 并不是所有的人都需要网络服务。
2 在未来很长一段时期内,C++仍将会广泛的应用。和C++比起来,C#是最近才发展起来的,并且前景也不明朗。
3 Mono表单只能够用在Winelib上面(至少开始是这样),这得到的结果肯定不如原生代码的wxWidgets。(据我所知,有使用C#语言的GTK#)
4 C#通常是字节编译,因此运行的更慢。另外,.NET需要客户端上有一个解释层(指.NET框架),wxWidgets不需要。
5 Mono还没有证明其有长久的生命力(这是一个复杂的组件系统)。WxWidgets则已经证明了。
6 你不希望被微软的市场战略和API牵着鼻子走。
7 微软可能随时因为.NET的非微软的实现而去起诉开发商/开发者。毕竟,跨平台其实不符合微软的利益。
8 .NET也许永远不会在某些平台上实现,比如Mac、Linux的嵌入式版本。
9 wxPython和其他的变体都是wxWidgets继续发展下去的理由。
10 Qt也面临着同样的问题:只要Qt的销售势头仍然很好,那就说明,C++开发阵营仍然占有一席之地。(如果Qt不流行了,大家转到wxWidgets来吧
没有什么会阻碍民间自发的开发wxWidgets API的C#版本。现在,我们已经绑定了Python、Perl、JavaScript、Lua、Basic、Eiffel语言。更新:一个
wx.NET项目现在正在进行中。
十六
我怎么才能够为wxWidgets贡献自己的力量?
请查看
开发者社区, 特别是
suggested projects,你可以把自己的意见、好的建议发到邮件列表上去.
十七
我怎么开发一个新的接口?
请订阅开发者邮件列表(wx-dev),并询问有没有人对开发这个接口感兴趣,或者是有一些特别的建议也行。你也需要看看代码编写规范
每一个接口都由三部分组成:1、平台相关部分(例如:src/msw , include/wx/msw);2、一些控件、对话框的集合 (src/generic, include/wx/generic),接口不是以原生的方式支持他们;3、所有接口都使用的公用代码(src/common, include/wx)。通过浏览这些代码,你会对整体的架构有深入的理解。
找一个和你要定义的接口最接近的现有接口,剥离出实现代码,编译得到一个框架。先在wx-dev上面获得wxStubs接口。当然,象这类预定义的框架接口可能已经过期,所以需要你做出判断来决定是否使用它。先整理一下wxStubs,可能接下来会更省时,其他的工作可能也会附带收益的。
你需要为新的接口定义一个标识符,例如 __WXXBOX__ 。参考象 wx/defs.h, wx/wxchar.h 这类的文件,你可以知道在哪里添加条件编译指令来支持宽字符集编译和其他问题。如果GUI(图形用户界面)运行在Unix的变体版,请在makefile中定义 __UNIX__ 变量。
接下来你就可以实现你的新接口的代码了,在wxWindow, wxTopLevelWindow, wxFrame, wxDialog 的基础上,很快就可以创建出你的小型示例程序。
如果在你的本地平台上有GDI对象(wxPen, wxBrush, etc.) 不被支持,那么你可能希望去使用他们的通用版本,参考 wxX11 接口。
可以考虑使用wxUniversal控件集来加快在你的平台上实现控件的开发速度。你只需要定义一些基本的类,就像是 device contexts, wxWindow, wxTopLevelWindow, GDI objects 等等,然后实际的控件就会自动的绘制出来。参考wxUniversal 接口中的 wxX11,wxMGL, 和 wxMSW/Univ。
开始的时候,你可以随便找makefile或者工程文件来用。可以参考现成的makefile,来看看generic/common/Unix 里的哪些文件需要囊括在内。然后,你需要把对你的接口的支持整合在配置文件 (Unix系的系统和Windows下的gcc)和bakefile中(for other makefiles on Windows)。
通过SourceForge,把你的编写的接口作为一个补丁提交上去。你可以把它分割成两个部分:一个是提供公共的头文件和源代码的包,另外的一个则包含接口专有的代码,这样做使得我们去看代码、使用这些包都会变得更容易一些。
Good luck!