Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Doc updates

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@33695 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Julian Smart
2005-04-17 10:34:19 +00:00
parent 23eaaaaf5f
commit 5147354ced
8 changed files with 166 additions and 112 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/html/faqgen.htm
View File

@@ -1,4 +1,3 @@
<HTML>
<HEAD>
@@ -54,7 +53,7 @@ so your program will take on the native &#39;look and feel&#39; that users are f
Although GUI applications are mostly built programmatically, there are several dialog editors to help
build attractive dialogs and panels. Robert Roebling&#39;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&#39;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&#39;t have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets 2,
@@ -277,29 +276,29 @@ from Java, and the level of interest in wxWidgets is as high as ever.<P>
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&#35; is Microsoft's alternative to Java, supporting 'managed code',
C&#35; is Microsoft&#39;s alternative to Java, supporting &#39;managed code&#39;,
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&#39;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&#35; 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&#35; for use with the C&#35; language).
wxWidgets (I&#39;m aware there is GTK&#35; for use with the C&#35; language).
<li>C&#35; 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&#39;t proven its long-term viability yet (it&#39;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&#39;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&#39;s a good indication that
the market for a C++-based approach is still there. (Either that, or everyone&#39;s turning to wxWidgets!)
</ol>
There is nothing to stop folk from developing a C&#35; version of the wxWidgets API;
@@ -322,7 +321,7 @@ has specific suggestions. Also please read the <a href="standard.htm">coding sta
<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&#39;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>
@@ -335,7 +334,7 @@ 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
Look at files such as wx/defs.h, wx/wxchar.h for areas where you&#39;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>
@@ -357,7 +356,7 @@ 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
generic/common/Unix files need to be included. Later, you&#39;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>