91c93c9927
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@3305 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
236 lines
10 KiB
HTML
236 lines
10 KiB
HTML
<HTML>
|
|
|
|
<HEAD>
|
|
<TITLE>wxWindows 2 FAQ: General</TITLE>
|
|
</HEAD>
|
|
|
|
<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000>
|
|
|
|
<font face="Arial, Lucida Sans, Helvetica">
|
|
|
|
<table width=100% border=4 cellpadding=5 cellspacing=0>
|
|
<tr>
|
|
<td bgcolor="#660000">
|
|
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
|
|
wxWindows 2 FAQ: General
|
|
</font>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<P>
|
|
|
|
See also <a href="faq.htm">top-level FAQ page</a>.
|
|
<hr>
|
|
|
|
<H3><a name="whatis">What is wxWindows?</a></H3>
|
|
|
|
wxWindows is a class library that allows you to compile graphical C++ programs on a range of
|
|
different platforms. wxWindows 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 is a dialog editor to help
|
|
build attractive dialogs and panels.<P>
|
|
|
|
You don't have to use C++ to use wxWindows: wxWindows 1 has been interfaced to several interpreted languages,
|
|
such as CLIPS, Python, Scheme, XLisp and Perl, and there is a Python interface for wxWindows 2.
|
|
<P>
|
|
|
|
<h3>Can I use wxWindows 2 for both proprietary (commercial) projects, and GPL'ed projects?</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 wxWindows
|
|
conflict with GPL code you may be using or developing with it.
|
|
<P>
|
|
The conditions for using wxWindows 2 are the same whether you are a personal, academic
|
|
or commercial developer.
|
|
<P>
|
|
|
|
<h3>Is there support?</h3>
|
|
|
|
No official support, but the mailing list is very helpful and some people say that
|
|
wxWindows 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 wxWindows?</a></H3>
|
|
|
|
Many organisations - commercial, government, and academic - across the
|
|
world. It's impossible to estimate the true number of users, since
|
|
wxWindows 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>
|
|
|
|
<H3>I am about to start a wxWindows 1.xx project. Should I use 2 instead?</H3>
|
|
|
|
wxWindows 2 is still in beta but it's actually pretty useable (Windows, GTK, Motif).<P>
|
|
|
|
Porting to wxWindows 2 from 1.xx will not be too painful; see the next question
|
|
for ways in which you can make it easier.<P>
|
|
|
|
<H3>Why would I want to use wxWindows 2 in preference to wxWindows 1.xx?</H3>
|
|
|
|
Some reasons:
|
|
|
|
<ul>
|
|
<li>In 2 there is far more flexibility, for example in the way windows can be
|
|
nested, and the way events are intercepted.
|
|
<li>There is more functionality for producing sophisticated applications,
|
|
for example using the wxTreeCtrl and wxListCtrl classes.
|
|
<li>There is better C++-conformance (such as usage of wxString and const) which
|
|
will make your applications more reliable and easier to maintain.
|
|
<li>wxWindows 2 will be better supported than 1.xx.
|
|
<li>The GTK version is attractive for people interested in writing Linux and GNOME
|
|
applications.
|
|
<li>The Mac version will be one of the best frameworks available on that platform.
|
|
</ul>
|
|
|
|
<H3>How can I prepare for wxWindows 2?</H3>
|
|
|
|
To make porting to wxWindows 2 easier in the future, take a look at some
|
|
<a href="http://web.ukonline.co.uk/julian.smart/wxwin/prepare.htm">tips</a> for writing existing code in a 2-compatible way.<P>
|
|
|
|
<H3>How much has the API changed since 1.xx?</H3>
|
|
|
|
It's difficult to summarize, but some aspects haven't changed very much. For example, if you have some
|
|
complex drawing code, you will mostly need to make sure it's parameterised with a device
|
|
context (instead of obtaining one from a window or storing it). You won't have
|
|
to completely rewrite the drawing code.<P>
|
|
|
|
The way that events are handled has changed, so for example, where you overrode
|
|
OnSize before, you now have a non-virtual OnSize with a single event class argument.
|
|
To make this function known to wxWindows, you add an entry in an 'event table' using macros. Addition of these macros
|
|
will eventually be made easier by a tool which will allow selection from a list
|
|
and copy-and-paste into your editor. This is extended to button presses, listbox selection
|
|
etc. so callbacks have gone (they may be added back for limited backward compatibility).<P>
|
|
|
|
The class hierarchy has changed to allow greater flexibility but it probably won't affect your
|
|
existing application. One exception to this is MDI applications which now use separate MDI classes instead of style
|
|
flags. As a result, it won't be possible to switch between MDI and SDI operation at run-time
|
|
without further coding, but a benefit is less interdependence between areas of code,
|
|
and therefore smaller executable size.<P>
|
|
|
|
Panel items (now called controls) no longer have labels associated with most of them,
|
|
and default panel layout has been removed. The idea is that you make greater use
|
|
of dialog resources, for better-looking dialogs.<P>
|
|
|
|
<H3>What classes have disappeared?</H3>
|
|
|
|
wxForm, wxTextWindow (subsumed into wxTextCtrl).
|
|
|
|
<H3>Does wxWindows 2 mean that wxWindows 1.xx is dead?</H3>
|
|
|
|
While wxWindows 2 is being developed, there will be further patches to wxWindows 1.xx.
|
|
Obviously we are investing most of our energy into the new code, but we're also trying
|
|
to fix bugs in the current version.<P>
|
|
|
|
<H3>What platforms will be supported by wxWindows 2?</H3>
|
|
|
|
<ul>
|
|
<li>Windows 3.1, Windows 95/98, Windows NT;
|
|
<li>Linux and other Unix platforms with GTK+;
|
|
<li>Unix with Motif or the free Motif clone Lesstif;
|
|
<li>Mac (coming later in 1999);
|
|
<li>A BeOS port is being investigated.
|
|
<li>A Windows CE port is being investigated.
|
|
<li>There are no plans to support OS/2 or XView. However,
|
|
you may be able to compile the GTK and Motif versions under OS/2 with X and GTK
|
|
installed, or the Windows version with IBM's Open32 extensions.
|
|
</ul>
|
|
<P>
|
|
|
|
<H3>How does wxWindows 2 support platform-specific features?</H3>
|
|
|
|
This is a hotly-debated topic amongst the developers. My own philosophy
|
|
is to make wxWindows 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 wxWindows-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, wxWindows 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 wxWindows 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 wxWindows 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>Does wxWindows use STL? or the standard string class?</H3>
|
|
|
|
No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in
|
|
wxWindows' 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
|
|
wxWindows 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
|
|
wxWindows 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.<P>
|
|
|
|
<H3>How is wxWindows 2 being developed?</H3>
|
|
|
|
We are using the <a href="cvs.htm">CVS</a> system to develop and maintain wxWindows. This allows
|
|
us to make alterations and upload them instantly to the server in Edinburgh, from
|
|
which others can update their source.<P>
|
|
|
|
To build source from CVS, see the file BuildCVS.txt in the top-level wxWindows distribution
|
|
directory.<P>
|
|
|
|
<H3>How is wxWindows 2 distributed?</H3>
|
|
|
|
By ftp, and via the <a href="cdrom2.htm">wxWindows CD-ROM</a>.<P>
|
|
|
|
<H3>What are the plans for the future?</H3>
|
|
|
|
Currently we're working too hard on getting wxWindows 2 finished (are GUI toolkits ever
|
|
finished?) to think very far ahead. However, we know we want to make wxWindows 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 the PNG for all platforms.<P>
|
|
|
|
Other possibilities include: DCOM/CORBA compatibility; a wxWindows book;
|
|
<a href="http://wxstudio.linuxbox.com/">wxStudio</a>, an IDE;
|
|
other platforms; other interface abilities such as speech output.<P>
|
|
|
|
We will investigate the possibility of compiler or operating system vendors bundling wxWindows with
|
|
their product.<P>
|
|
|
|
The high-level goal of wxWindows is to be thought of as the number one C++ framework,
|
|
for virtually any platform. Move over, MFC!<P>
|
|
|
|
<H3>What about Java?</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 wxWindows is as high as ever.<P>
|
|
|
|
<H3>How can I help the project?</H3>
|
|
|
|
Please check out the <a href="http://web.ukonline.co.uk/julian.smart/wxwin/develop.htm" target=main>Backroom</a> pages,
|
|
in particular the <a href="http://web.ukonline.co.uk/julian.smart/wxwin/projects.htm">suggested projects</a>, and
|
|
mail <a href="mailto:julian.smart@ukonline.co.uk">Julian Smart</a> or the developers' mailing list with your own suggestions.<P>
|
|
|
|
</font>
|
|
|
|
</BODY>
|
|
|
|
</HTML>
|