wxWidgets常规FAQ

英文原文：http://wxwidgets.org/docs/faqgen.htm

 

wxWidgets常规FAQ

 

一、什么是wxWidgets？
wxWidgets是一个类库，可以用来在多种平台（操作系统）下编译图形化C++程序。
wxWidgets定义了一（组）跨平台通用API，却在每个平台下使用了（该平台的）本地图形用户接口（GUI），使得你的程序“看上去感觉”就是用户熟悉的本地（程序）。大多数GUI应用程序都是用（对话框开发）程序所构建，有几个对话框编辑程序可以构建漂亮的对话框和面板。除了Rober Roebling的wxDesigner和Anthemion软件（公司）的DialogBlocks两个有代表性的商业（对话框编辑程序）之外，还有其他的几个，（详情）参阅wxCommunity页面。
为了使用wxWidgets，并不一定非要使用C++，wxWidgets还有Python（语言）和Perl（语言）接口。

二、我能在商业项目和GPL项目中使用wxWidgets吗？
是的。请参阅licence（许可证）获取详情。基本上，你可以发布（使用了wxWidgets的）商业可执行文件而不用发布任何源代码。而且wxWidgets（的许可证）不和你所使用或是开发的GPL代码（的许可证）相矛盾。
无论个人、大学生或是商业开发者使用wxWidgets的条款都是一致的。
三、 有技术支持吗?

没有官方的技术支持, 但是邮件列表可以给你很大帮助，很多人都说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(框架)里面是否有丰富文本编辑、标记的控件？

目前来说(实现你的目的)是可能的：

*请参考：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!
 
英文原文：

What is wxWidgets?
wxWidgets is a class library that allows you to compile graphical C++ programs on a range of different platforms. wxWidgets defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform, so your program will take on the native 'look and feel' that users are familiar with.

Although GUI applications are mostly built programmatically, there are several dialog editors to help build attractive dialogs and panels. Robert Roebling's wxDesigner and Anthemion Software's DialogBlocks are two commercial examples, but there are others: see the wxCommunity pages.

You don't have to use C++ to use wxWidgets: there is a Python interface for wxWidgets, and also a Perl interface.

Can I use wxWidgets for both proprietary (commercial) projects, and GPL'ed projects?
Yes. Please see the licence for details, but basically you can distribute proprietary binaries without distributing any source code, and neither will wxWidgets conflict with GPL code you may be using or developing with it.

The conditions for using wxWidgets are the same whether you are a personal, academic or commercial developer.

Is there support?
No official support, but the mailing list is very helpful and some people say that wxWidgets support is better than for much commercial software. The developers are keen to fix bugs as soon as possible, though obviously there are no guarantees.

Who uses wxWidgets?
Many organisations - commercial, government, and academic - across the world. It's impossible to estimate the true number of users, since wxWidgets is obtained by many different means, and we cannot monitor distribution.

See the Users page for a list of some users and their applications, and also the Feedback page for comments.

Our highest-profile user yet is industry veteran and Lotus Corp. founder Mitch Kapor and his Open Source Applications Foundation.

What platforms are supported by wxWidgets?
Windows 95/98/ME, NT, 2000, XP, and Vista.
Linux and other Unix platforms with GTK+.
Unix with Motif or the free Motif clone Lesstif.
Mac OS X 10.3 and above (10.2 with the older 2.6 versions).
Embedded platforms are being investigated, see the wxUniversal project.
An OS/2 port is in progress, and you can also compile wxWidgets for GTK+ or Motif on OS/2.
How does wxWidgets support platform-specific features?
This is a hotly-debated topic amongst the developers. My own philosophy is to make wxWidgets as platform-independent as possible, but allow in a few classes (functions, window styles) that are platform-specific. For example, Windows metafiles and Windows 95 taskbar icons have their own classes on Windows, but nowhere else. Because these classes are provided and are wxWidgets-compatible, it doesn't take much coding effort for an application programmer to add support for some functionality that the user on a particular platform might otherwise miss. Also, some classes that started off as platform-specific, such as the MDI classes, have been emulated on other platforms. I can imagine that even wxTaskBarIcon may be implemented for Unix desktops one day.

In other words, wxWidgets is not a 'lowest common denominator' approach, but it will still be possible to write portable programs using the core API. Forbidding some platform-specific classes would be a stupid approach that would alienate many potential users, and encourage the perception that toolkits such as wxWidgets are not up to the demands of today's sophisticated applications.

Currently resources such as bitmaps and icons are handled in a platform-specific way, but it is hoped to reduce this dependence in due course.

Another reason why wxWidgets is not a 'lowest common denominator' toolkit is that some functionality missing on some platform has been provided using generic, platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.

Does wxWidgets use STL, or the standard string class?
No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in wxWidgets' best interests to avoid use of templates. Not all compilers can handle templates adequately so it would dramatically reduce the number of compilers and platforms that could be supported. It would also be undesirable to make wxWidgets dependent on another large library that may have to be downloaded and installed. In addition, use of templates can lead to executable bloat, which is something wxWidgets is strenuously trying to avoid.

The standard C++ string class is not used, again because it is not available to all compilers, and it is not necessarily a very efficient implementation. Also, we retain more flexibility by being able to modify our own string class. Some compatibility with the string class has been built into wxString.

There is nothing to stop an application using templates or the string class for its own purposes. With wxWidgets debugging options on, you may find you get errors when including STL headers. You can work around it either by switching off memory checking, or by adding this to a header before you include any STL files:

#ifdef new
#undef new
#endifIs there a rich edit/markup widget for wxWidgets?
These are the possibilities so far:

See www.scintilla.org for a very nice syntax-highlighting editor widget. Robin Dunn has written a wxWidgets wrapper for this widget, available in the wxWidgets distribution under contrib/src/stc.
If you only need to display marked-up information, rather than edit it, then wxHTML will suit your needs. wxHTML is built into wxWidgets - please see the reference manual for details, and samples/html.
There are rich edit widgets in both WIN32 and GTK+, but there is currently no wxWidgets wrapper for these (but text attribute functions are being added in the wxWidgets 2.3.x series).
How to use C++ exceptions with wxWidgets?
wxWidgets library itself is unfortunately not exception-safe (as its initial version predates, by far, the addition of the exceptions to the C++ language). However you can still use the exceptions in your own code and use the other libraries using the exceptions for the error reporting together with wxWidgets.

There are a few issues to keep in mind, though:

You shouldn't let the exceptions propagate through wxWidgets code, in particular you should always catch the exceptions thrown by the functions called from an event handler in the handler itself and not let them propagate upwards to wxWidgets.
You may need to ensure that the compiler support for the exceptions is enabled as, considering that wxWidgets itself doesn't use the exceptions and turning their support on results in the library size augmentation of 10% to 20%, it is turned off by default for a few compilers. Moreover, for gcc (or at least its mingw version) you must also turn on the RTTI support to be able to use the exceptions, so you should use --disable-no_rtti --disable-no_exceptions options when configuring the library (attention to the double negation).
How is wxWidgets being developed?
We are using the SVN system to develop and maintain wxWidgets. This allows us to make alterations and upload them instantly to the server, from which others can update their source.

To build source from SVN, see the BuildSVN.txt file in the top-level wxWidgets distribution directory.

How is wxWidgets distributed?
You can download wxWidgets from our downloads page. If you are feeling adventurous, you may also check out the sources directly from SVN.

What is wxBase?
wxBase is a subset of wxWidgets comprised by the non-GUI classes. It includes wxWidgets container and primitive data type classes (including wxString, wxDateTime and so on) and also useful wrappers for the operating system objects such as files, processes, threads, sockets and so on. With very minor exceptions wxBase may be used in exactly the same way as wxWidgets but it doesn't require a GUI to run and so is ideal for creating console mode utilities or server programs. It is also possible to create a program which can be compiled either as a console application (using wxBase) or a GUI one (using a full featured wxWidgets port).

What is wxUniversal?
The main difference between wxUniversal-based ports (such as wxX11, wxMGL) and other ports (such as wxMSW, wxGTK+, wxMac) is that wxUniversal implements all controls (or widgets) in wxWidgets itself thus allowing to have much more flexibility (for example, support for themes even under MS Windows). It also means that it is now much easier to port wxWidgets to a new platform as only the low-level classes must be ported which make for a small part of the library.

You may find more about wxUniversal here.

What about Java?
The Java honeymoon period is over :-) and people are realising that it cannot meet all their cross-platform development needs. We don't anticipate a major threat from Java, and the level of interest in wxWidgets is as high as ever.

What about .NET/Mono?
Microsoft is spending a lot on promoting the .NET initiative, which is a set of languages, APIs and web service components for Windows. Ximian has started an open source version of .NET, mostly for Linux. C# is Microsoft's alternative to Java, supporting 'managed code', garbage collection and various other Java-like language features.

Although this may be attractive to some developers, there is a variety of reasons why the .NET/Mono combination is unlikely to make wxWidgets redundant. Please note that the following comments are Julian Smart's opinions.

Not everyone wants or needs net services.
C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain.
Mono Forms may only target Winelib (at least to begin with), so the end result is not as native as wxWidgets (I'm aware there is GTK# for use with the C# language).
C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer that wxWidgets does not require.
Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now.
You may not wish to buy into Microsoft marketing spin and APIs.
Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all, platform-independence is not in Microsoft's interest.
.NET might never be implemented on some platforms, especially Mac and embedded variants of Linux.
wxPython and other language variants provide further reasons for wxWidgets to continue.
The same issue exists for Qt: if Qt sales remain strong, it's a good indication that the market for a C++ based approach is still there. (Either that, or everyone's turning to wxWidgets!)
There is nothing to stop folk from developing a C# version of the wxWidgets API. We already have bindings to Python, Perl, JavaScript, Lua, Basic, and Eiffel. Update: A wx.NET project is now in progress.

How can I help the project?
Please check out the Community pages, in particular the suggested projects, and mail the developers' mailing list with your own suggestions.

How do I start a new port?
Please subscribe to the developers' mailing list (wx-dev) and ask if anyone else is interested in helping with the port, or has specific suggestions. Also please read the coding standards.

Each port consists of a platform-specific part (e.g. src/msw, include/wx/msw), a generic set of widgets and dialogs for when the port doesn't support them natively (src/generic, include/wx/generic) and the common code that all ports use (src/common, include/wx). By browsing the source you should get a good idea of the general pattern.

Take a port that most closely matches your port, and strip out the implementation so you have a skeleton port that compiles. Ask on wx-dev first for the wxStubs port - however, any such predefined skeleton port may be out of date, so make a judgement on whether to use it. Perhaps it will still save you time to clean up wxStubs, and others may benefit from this too.

You will need to define a symbol for the new port, e.g. __WXXBOX__. Look at files such as wx/defs.h, wx/wxchar.h for areas where you'll need to add to existing conditionals to set up wide character support and other issues. If the GUI runs on a Unix variant, define the __UNIX__ variable in your makefile.

Then you can start implementing the port, starting with wxWindow, wxTopLevelWindow, wxFrame, wxDialog so you can get the minimal sample running as soon as possible.

If GDI objects (wxPen, wxBrush, etc.) are not concepts in your native GUI, you may wish to use very generic versions of some of these - see the wxX11 port.

Consider using the wxUniversal widget set as a quick way to implement wxWidgets on your platform. You only need to define some basic classes such as device contexts, wxWindow, wxTopLevelWindow, GDI objects etc. and the actual widgets will be drawn for you. See wxX11, wxMGL, and wxMSW/Univ for sample wxUniversal ports.

To begin with, you can use whatever makefiles or project files work for you. Look at existing makefiles to see what generic/common/Unix files need to be included. Later, you'll want to integrate support for your port into configure (Unix-like systems and gcc under Windows), and bakefile (for other makefiles on Windows).

Submit your port as patches via SourceForge; you might wish to separate it into one patch that touches common headers and source files, and another containing the port-specific code, to make it much easier for us to review and apply the patches.

Good luck!
 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/qiqi5521/archive/2008/07/22/2691395.aspx