<HTML>
<HEAD>
-<TITLE>wxWidgets 2 FAQ: General</TITLE>
+<TITLE>wxWidgets FAQ: General</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<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>
+<b>wxWidgets FAQ: General</b>
</font>
</td>
</tr>
<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="#licence">Can I use wxWidgets 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="#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>
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>
+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,
+You don't have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets,
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>
+<h3><a name="licence">Can I use wxWidgets 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
+The conditions for using wxWidgets are the same whether you are a personal, academic
or commercial developer.
<P>
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>
+<H3><a name="platforms">What platforms are supported by wxWidgets?</a></H3>
<ul>
<li>Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME.
</ul>
<P>
-<H3><a name="specific">How does wxWidgets 2 support platform-specific
+<H3><a name="specific">How does wxWidgets support platform-specific
features?</a></H3>
This is a hotly-debated topic amongst the developers. My own philosophy
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
+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.<P>
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
+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
2 is strenously trying to avoid.<P>
+wxWidgets
is strenuously 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
<P>
-<H3><a name="richedit">Is there a rich edit/markup widget for wxWidgets 2?</a></H3>
+<H3><a name="richedit">Is there a rich edit/markup widget for wxWidgets?</a></H3>
These are the possibilities so far:<P>
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>
+TODO
-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>
+<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>
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',
+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>
+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).
+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>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.
+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!)
+<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;
<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
+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>
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
+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>
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
+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>
projects / wxWidgets.git / blobdiff