-
<HTML>
<HEAD>
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,
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>