]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/html/faqgen.htm
Fixes to allow compilation with no wchar_t (djgpp probably has a real wchar_t
[wxWidgets.git] / docs / html / faqgen.htm
index 25fc5d82b46d951cc29f9ef504b20ba50d8d464e..90f2c41d1a8da65b06b31e4774e430fe460900b6 100644 (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>