15a2de7e4f
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@30914 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
376 lines
18 KiB
HTML
376 lines
18 KiB
HTML
|
|
<HTML>
|
|
|
|
<HEAD>
|
|
<TITLE>wxWidgets 2 FAQ: General</TITLE>
|
|
</HEAD>
|
|
|
|
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
|
|
|
|
<font face="Arial, Lucida Sans, Helvetica">
|
|
|
|
<table width=100% border=0 cellpadding=3 cellspacing=0>
|
|
<tr>
|
|
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
|
|
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
|
|
<b>wxWidgets 2 FAQ: General</b>
|
|
</font>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<P>
|
|
|
|
See also <a href="faq.htm">top-level FAQ page</a>.
|
|
<hr>
|
|
<h3>List of questions in this category</h3>
|
|
<ul>
|
|
<li><a href="#whatis">What is wxWidgets?</a></li>
|
|
<li><a href="#licence">Can I use wxWidgets 2 for both proprietary projects, and GPL'ed projects?</a></li>
|
|
<li><a href="#support">Is there support?</a></li>
|
|
<li><a href="#users">Who uses wxWidgets?</a></li>
|
|
<li><a href="#platforms">What platforms are supported by wxWidgets?</a></li>
|
|
<li><a href="#specific">How does wxWidgets support platform-specific features?</a></li>
|
|
<li><a href="#stl">Does wxWidgets use STL? or the standard string class?</a></li>
|
|
<li><a href="#richedit">Is there a rich edit/markup widget for wxWidgets?</a></ li>
|
|
<li><a href="#exceptions">How to use C++ exceptions with wxWidgets?</a></ li>
|
|
<li><a href="#dev">How is wxWidgets being developed?</a></li>
|
|
<li><a href="#distrib">How is wxWidgets distributed?</a></li>
|
|
<li><a href="#future">What are the plans for the future?</a></li>
|
|
<li><a href="#base">What is wxBase?</a></li>
|
|
<li><a href="#univ">What is wxUniversal?</a></li>
|
|
<li><a href="#jave">What about Java?</a></li>
|
|
<li><a href="#dotnet">What about .NET/Mono?</a></li>
|
|
<li><a href="#help">How can I help the project?</a></li>
|
|
<li><a href="#newport">How do I start a new port?</a></li>
|
|
</ul>
|
|
<hr>
|
|
|
|
<H3><a name="whatis">What is wxWidgets?</a></H3>
|
|
|
|
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.<P>
|
|
|
|
Although GUI applications are mostly built programmatically, there are several dialog editors to help
|
|
build attractive dialogs and panels. Robert Roebling's <a href="http://www.roebling.com">wxDesigner</a>
|
|
and Anthemion Software's <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a>
|
|
are two commercial examples, but there are others: see the <a href="lnk_tool.htm">Useful Tools</a> page.<P>
|
|
|
|
You don't have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets 2,
|
|
and also a <a href="http://wxperl.sourceforge.net" target=_top>Perl interface</a>.
|
|
<P>
|
|
|
|
<h3><a name="licence">Can I use wxWidgets 2 for both proprietary (commercial) projects, and GPL'ed projects?</a></h3>
|
|
|
|
Yes. Please see the <a href="newlicen.htm">licence</a> 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.
|
|
<P>
|
|
The conditions for using wxWidgets 2 are the same whether you are a personal, academic
|
|
or commercial developer.
|
|
<P>
|
|
|
|
<h3><a name="support">Is there support?</a></h3>
|
|
|
|
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.
|
|
<P>
|
|
|
|
<H3><a name="users">Who uses wxWidgets?</a></H3>
|
|
|
|
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. The mailing list contains around 300-400 entries which is
|
|
quite large for a list of this type.<P>
|
|
|
|
See <a href="users.htm">Users</a> for a list of some users and their applications, and
|
|
also <A href="feedback.htm">Feedback</a> for comments.<P>
|
|
Our highest-profile user yet is industry veteran and Lotus Corp. founder Mitch Kapor
|
|
and his <a href="http://www.osafoundation.org" target=_new>Open Source Applications Foundation</a>.
|
|
<P>
|
|
|
|
<H3><a name="platforms">What platforms are supported by wxWidgets 2?</a></H3>
|
|
|
|
<ul>
|
|
<li>Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME.
|
|
<li>Linux and other Unix platforms with GTK+.
|
|
<li>Unix with Motif or the free Motif clone Lesstif.
|
|
<li>Mac OS.
|
|
<li>Embedded platforms are being investigated. See the <a href="wxuniv.htm">wxUniversal</a> project.
|
|
<li>An OS/2 port is in progress, and you can also compile wxWidgets for GTK+ or Motif
|
|
on OS/2.
|
|
</ul>
|
|
<P>
|
|
|
|
<H3><a name="specific">How does wxWidgets 2 support platform-specific
|
|
features?</a></H3>
|
|
|
|
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.
|
|
<P>
|
|
|
|
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.<P>
|
|
|
|
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.<P>
|
|
|
|
Another reason why wxWidgets 2 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.<P>
|
|
|
|
<H3><a name="stl">Does wxWidgets use STL? or the standard string class?</a></H3>
|
|
|
|
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 undersirable 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 2 is strenously trying to avoid.<P>
|
|
|
|
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.<P>
|
|
|
|
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:<P>
|
|
|
|
<PRE>
|
|
#ifdef new
|
|
#undef new
|
|
#endif
|
|
</PRE>
|
|
|
|
<P>
|
|
|
|
|
|
<H3><a name="richedit">Is there a rich edit/markup widget for wxWidgets 2?</a></H3>
|
|
|
|
These are the possibilities so far:<P>
|
|
|
|
<ul>
|
|
<li>See <a href="http://www.scintilla.org" target=_top>www.scintilla.org</a> 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.
|
|
<li>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.
|
|
<li>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).
|
|
</ul>
|
|
|
|
<P>
|
|
|
|
<h3><a name="exceptions">How to use C++ exceptions with wxWidgets?</a></h3>
|
|
|
|
wxWidgets library itself is unfortunately <i>not</i> 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.
|
|
|
|
<p>
|
|
There are a few issues to keep in mind, though:
|
|
<ul>
|
|
<li>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.
|
|
|
|
<li>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 <tt>--disable-no_rtti --disable-no_exceptions</tt> options
|
|
when configuring the library (attention to the double negation).
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<H3><a name="dev">How is wxWidgets being developed?</a></H3>
|
|
|
|
We are using the <a href="cvs.htm">CVS</a> 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.<P>
|
|
|
|
To build source from CVS, see the file BuildCVS.txt in the top-level wxWidgets distribution
|
|
directory.<P>
|
|
|
|
<H3><a name="distrib">How is wxWidgets distributed?</a></H3>
|
|
|
|
By ftp, and via the <a href="cdrom2.htm">wxWidgets CD-ROM</a>.
|
|
<P>
|
|
If you are feeling adventurous, you may also check out the sources directly
|
|
from <a href="cvs.htm">cvs</a>.
|
|
<p>
|
|
|
|
<H3><a name="future">What are the plans for the future?</a></H3>
|
|
|
|
Currently we're working too hard on getting wxWidgets finished (are GUI toolkits ever
|
|
finished?) to think very far ahead. However, we know we want to make wxWidgets as robust
|
|
and well-publicised as possible. We also want to aim for better platform-independence of
|
|
resources such as icons and bitmaps, standardising on PNG and XPM for all platforms.<P>
|
|
|
|
Other possibilities include: DCOM/CORBA compatibility; a wxWidgets book;
|
|
<a href="http://wxworkshop.sourceforge.net/">wxWorkshop</a>, an IDE;
|
|
other platforms, especially embedded systems; other interface abilities such as speech output.<P>
|
|
|
|
We will investigate the possibility of compiler or operating system vendors bundling wxWidgets with
|
|
their product.<P>
|
|
|
|
The high-level goal of wxWidgets is to be thought of as the number one C++ framework,
|
|
for virtually any platform. Move over, MFC!<P>
|
|
|
|
<h3><a name="base">What is wxBase?</a></h3>
|
|
|
|
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).
|
|
|
|
<H3><a name="univ">What is wxUniversal?</a></H3>
|
|
|
|
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.
|
|
<p>
|
|
You may find more about wxUniversal <a href=wxuniv.htm>here</a>.
|
|
|
|
<H3><a name="jave">What about Java?</a></H3>
|
|
|
|
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.<P>
|
|
|
|
<H3><a name="dotnet">What about .NET/Mono?</a></H3>
|
|
|
|
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.<P>
|
|
|
|
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.<P>
|
|
|
|
<ol>
|
|
<li>Not everyone wants or needs net services.
|
|
<li>C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain.
|
|
<li>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).
|
|
<li>C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer
|
|
that wxWidgets does not require.
|
|
<li>Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now.
|
|
<li>You may not wish to buy into Microsoft marketing spin and APIs.
|
|
<li>Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all,
|
|
platform-independence is not in Microsoft's interest.
|
|
<li>.NET might never be implemented on some platforms, especially Mac and embedded variants of Linux.
|
|
<li>wxPython and other language variants provide further reasons for wxWidgets to continue.
|
|
<li>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!)
|
|
</ol>
|
|
|
|
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 <a href="http://wxnet.sourceforge.net/" target=_new>wx.NET</a> project is now in progress.
|
|
|
|
<P>
|
|
|
|
<H3><a name="help">How can I help the project?</a></H3>
|
|
|
|
Please check out the <a href="http://www.wxwidgets.org/develop2.htm">Community</a> pages,
|
|
in particular the <a href="projects.htm">suggested projects</a>, and
|
|
mail the developers' mailing list with your own suggestions.<P>
|
|
|
|
<H3><a name="newport">How do I start a new port?</a></H3>
|
|
|
|
Please subscribe to the wx-dev <a href="maillst2.htm">developers' mailing list</a> and
|
|
ask if anyone else is interested in helping with the port, or
|
|
has specific suggestions. Also please read the <a href="standard.htm">coding standards</a>.
|
|
|
|
<P>
|
|
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.<P>
|
|
|
|
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.<P>
|
|
|
|
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.<P>
|
|
|
|
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.<P>
|
|
|
|
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.<P>
|
|
|
|
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.<P>
|
|
|
|
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).<P>
|
|
|
|
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.<P>
|
|
|
|
Good luck!
|
|
|
|
</font>
|
|
|
|
</BODY>
|
|
|
|
</HTML>
|