Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mono/mono.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/web/faq
diff options
context:
space:
mode:
authorMiguel de Icaza <miguel@gnome.org>2003-09-16 05:13:14 +0400
committerMiguel de Icaza <miguel@gnome.org>2003-09-16 05:13:14 +0400
commitec34a29c664d9f44a083cd090272001337b86127 (patch)
tree2fdb1dc2ba906fc2bd0a96b50e521c0802e47633 /web/faq
parentb3e9ac2e86c03e43438f4a1d7f3ea32221166a6b (diff)
Flush
svn path=/trunk/mono/; revision=18121
Diffstat (limited to 'web/faq')
-rw-r--r--web/faq42
1 files changed, 18 insertions, 24 deletions
diff --git a/web/faq b/web/faq
index f7854b850ab..cfab926f71a 100644
--- a/web/faq
+++ b/web/faq
@@ -329,24 +329,24 @@ A: Gtk# is a set of bindings for the Gtk+ toolkit for C# (and other
Q: Why not implement System.Windows.Forms on top of Gtk# or Qt#?
-A: There are several reasons for this.
-
- First of all, Gtk+ and Qt are standard toolkits on Linux, and their
- proponents want to use their favorite toolkits when writing
- applications.
-
- Related to this is the idea that System.Windows.Forms is
- brain-dead in certain areas, such as internationalization.
- System.Windows.Forms uses explicit sizes for all controls, as opposed
- to Gtk+ and Qt which use a box/packing model, which can better deal with
- the different string lengths different languages will have.
-
- Next is compatibility. It is not possible to implement
- System.Windows.Forms on top of Gtk+/Qt and have 100% compatibility,
- because System.Windows.Forms exposes some Win32-isms, such as the
- Win32 message loop. In order to maintain compatibility, Wine must be used,
- and this is being done; see the
- <a href="/winforms.html">System.Windows.Forms effort page</a>.
+A: Compatibility.
+
+ Although it is possible to run simple Windows.Forms applications
+ with the Gtk#-based backend of Windows.Forms, it is very unlikely
+ that the implementation will ever implement everything needed for
+ full compatibility with Windows.Forms.
+
+ The reason is that Windows.Forms is not a complete toolkit, and to
+ work around this problem some of the underlying Win32 foundation is
+ exposed to the programmer in the form of exposing the Windows
+ message handler (WndProc). Any control can override this method.
+ Also developers often P/Invoke into Win32 to get to functionality
+ that was not wrapped.
+
+ To achieve full compatibility, we would have to emulate this, and
+ it would take too long.
+
+ For more details see the <a href="winforms.html">winforms page</a>
Q: Wine applications do not look like native applications, what are
you going to do about this?
@@ -633,12 +633,6 @@ A: Yes, with some reservations.
all dependent assemblies available on all desired platforms. (How to do so
is outside the bounds of this FAQ.)
- For example, since Mono's System.Windows.Forms implementation will use
- Wine, System.Windows.Forms is only as portable as Wine is. It's possible
- that Mono may run on a platform, but Wine will not, in which case a
- System.Windows.Forms app will not run on that platform. This is similarly
- true for all assemblies that are not 100% managed code.
-
Mono must also have an implementation for the .NET assemblies used. For
example the System.EnterpriseServices namespace is part of .NET, but it
has not been implemented in Mono. Thus, any applications using this