FAQ mods
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@1432 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Julian Smart
parent
1ccbb61aba
commit
b953bdc293
@ -32,7 +32,7 @@ Welcome to the wxWindows FAQ. Please select a category:<P>
|
||||
|
||||
<P>
|
||||
|
||||
For further information, please see the <a href="http://wxwin.home.ml.org" target=_top>wxWindows Web site</a>,
|
||||
For further information, please see the <a href="http://web.ukonline.co.uk/julian.smart/wxwin" target=_top>wxWindows Web site</a>,
|
||||
plus install.txt (per port), todo.txt (per port), and bugs.txt (all ports).
|
||||
<P>
|
||||
|
||||
|
||||
@ -61,6 +61,170 @@ 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>
|
||||
|
||||
<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; an
|
||||
<a href="http://web.ukonline.co.uk/julian.smart/wxwin/wxide.htm">IDE</a>;
|
||||
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>
|
||||
|
||||
@ -25,7 +25,7 @@ See also <a href="faq.htm">top-level FAQ page</a>.
|
||||
|
||||
<h3>When is wxMac 2 due to be released?</h3>
|
||||
|
||||
There is a <a href="http://wxwin.home.ml.org/wxwin/dl_mac2.htm">preview</a> available.
|
||||
There is a <a href="http://web.ukonline.co.uk/julian.smart/wxwin/dl_mac2.htm">preview</a> available.
|
||||
A beta release can be expected by early Q2 1999. The author of this port
|
||||
is Stefan Csomor (csomor@advancedconcepts.ch).
|
||||
<P>
|
||||
|
||||
@ -23,17 +23,41 @@ wxWindows 2 for Windows FAQ
|
||||
See also <a href="faq.htm">top-level FAQ page</a>.
|
||||
<hr>
|
||||
|
||||
<h3>Is Windows 3.1 supported?</h3>
|
||||
<h3>Which Windows platforms are supported?</h3>
|
||||
|
||||
Yes! Unlike Microsoft, we have not forgotten users of 16-bit Windows. Most features
|
||||
wxWindows can be used to develop and deliver applications on Windows 3.1, Win32s,
|
||||
Windows 95, Windows 98, and Windows NT. A Windows CE version is being looked into (see below).<P>
|
||||
|
||||
wxWindows 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft,
|
||||
we have not forgotten users of 16-bit Windows. Most features
|
||||
work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation.
|
||||
However, don't expect Windows 95-specific classes to work, such as wxTaskBar. The wxRegConfig
|
||||
However, don't expect very Windows-specific classes to work, such as wxTaskBarIcon. The wxRegConfig
|
||||
class doesn't work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit
|
||||
makefiles to see what other files have been left out.
|
||||
<P>
|
||||
16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
|
||||
<P>
|
||||
|
||||
wxWindows 2 for Windows will also compile on Unix with gcc using TWIN32 from <a href="http://www.willows.com" target=_top>Willows</a>,
|
||||
although TWIN32 is still in a preliminary state. The resulting executables are
|
||||
Unix binaries that work with the TWIN32 Windows API emulator.<P>
|
||||
|
||||
You can also compile wxWindows 2 for Windows on Unix with Cygwin or Mingw32, resulting
|
||||
in executables that will run on Windows. So in theory you could write your applications
|
||||
using wxGTK or wxMotif, then check/debug your wxWindows for Windows
|
||||
programs with TWIN32, and finally produce an ix86 Windows executable using Cygwin/Mingw32,
|
||||
without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.<P>
|
||||
|
||||
<h3>What about Windows CE?</h3>
|
||||
|
||||
This is under consideration, though we need to get wxWindows Unicode-aware first.
|
||||
There are other interesting issues, such as how to combine the menubar and toolbar APIs
|
||||
as Windows CE requires. But there's no doubt that it will be possible, albeit
|
||||
by mostly cutting down wxWindows 2 API functionality, and adding a few classes here
|
||||
and there. Since wxWindows for 2 produces small binaries (less than 300K for
|
||||
the statically-linked 'minimal' sample), shoehorning wxWindows 2 into a Windows CE device's limited
|
||||
storage should not be a problem.<P>
|
||||
|
||||
<h3>What compilers are supported?</h3>
|
||||
|
||||
Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
|
||||
@ -83,13 +107,27 @@ However, the issues surrounding Unicode support have been looked into so we know
|
||||
what we need to do, and have some header files ready to use containing appropriate
|
||||
type definitions. Just about every file in wxWindows will need changes, due to the
|
||||
pervasive nature of characters and character arrays. Unicode support is needed
|
||||
for the port to Windows CE (see below).<P>
|
||||
for the port to Windows CE (see above).<P>
|
||||
|
||||
<h3>What about Windows CE?</h3>
|
||||
<h3>Can you compile wxWindows 2 as a DLL?</h3>
|
||||
|
||||
This is under consideration, though we need to get wxWindows Unicode-aware first.
|
||||
There are other interesting issues, such as how to combine the menubar and toolbar APIs
|
||||
as Windows CE requires.<P>
|
||||
Yes (using the Visual C++ makefile), but be aware that distributing DLLs is a thorny issue
|
||||
and you may be better off compiling statically-linked applications, unless you're
|
||||
delivering a suite of separate programs, or you're compiling a lot of wxWindows applications
|
||||
and have limited hard disk space.<P>
|
||||
|
||||
With a DLL approach, and with different versions and configurations of wxWindows
|
||||
needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory,
|
||||
negating the point of using DLLs. Of course, this is not a problem just associated with
|
||||
wxWindows!
|
||||
<P>
|
||||
|
||||
|
||||
<H3>Will wxWindows be compatible with MFC?</H3>
|
||||
|
||||
There is a sample which demonstrates MFC and wxWindows code co-existing in the same
|
||||
application. However, don't expect to be able to enable wxWindows windows with OLE-2
|
||||
functionality using MFC.<P>
|
||||
|
||||
|
||||
</font>
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
|
||||
Welcome to wxWindows 2.0, the premiere cross-platform C++ framework. This is an index of
|
||||
the plain text and HTML documentation. Documentation is also available in Acrobat (PDF) and Windows Help,
|
||||
from the <a href="http://wxwin.home.ml.org">wxWindows Web site</a>.<P>
|
||||
from the <a href="http://web.ukonline.co.uk/julian.smart/wxwin">wxWindows Web site</a>.<P>
|
||||
|
||||
<h3>Installation and release notes</h3>
|
||||
|
||||
|
||||
@ -194,7 +194,7 @@ Applications Institute by anonymous FTP and World Wide Web:
|
||||
|
||||
\begin{verbatim}
|
||||
ftp://www.remstar.com/pub/wxwin
|
||||
http://wxwin.home.ml.org
|
||||
http://web.ukonline.co.uk/julian.smart/wxwin
|
||||
\end{verbatim}
|
||||
|
||||
\section{Acknowledgments}
|
||||
|
||||
@ -159,13 +159,6 @@ LIB_CPP_SRC=\
|
||||
../generic/textdlgg.cpp \
|
||||
../generic/treectrl.cpp
|
||||
|
||||
# If you're not using the generic ones, you
|
||||
# may wish to define platform-specific ones
|
||||
# dirdlg.cpp \
|
||||
# treectrl.cpp \
|
||||
# listctrl.cpp \
|
||||
# imaglist.cpp \
|
||||
|
||||
ZLIB_SRC=\
|
||||
../zlib/adler32.c ../zlib/deflate.c ../zlib/infblock.c\
|
||||
../zlib/inflate.c ../zlib/zutil.c ../zlib/compress.c \
|
||||
|
||||
Loading…
Reference in New Issue
Block a user