System.Windows.Forms (Was: RE: [Mono-list] Compiling Various Libraries under Cygwin)

[Richard Matthias]

> The API for GUI tools will be System.Windows.Forms.  Under that API, a
> magic trick is being cooked: we will be using Gtk+ on
> Windows, and Aqua on MacOS X.

I've been thinking about the windows forms package. Its certainly high level
enough that you could implement it using a non-windows related toolkit like
gtk. The GDI+ package might be more effort depending on how similar its
primitive operations are to the Windows GDI, but still do-able. If we see
mono as a tool for people who want to develop in C# (or other CLI compatible
language) on a non-Windows platform this is all OK.

If OTOH you want mono to run windows .NET programs unmodified (i.e.
commercial software) this approach will likely be unsatisfactory because the
windows forms package is not a complete solution for developing GUI
applications. Its incompleteness implies (and some of Microsoft's example
code explicitly directs) you to access the Win32 API directly. As such
System.Windows.Forms.Control class exposes its window handle as a property.
The System.Windows.Forms.Application object encapsulates the basic windows
message loop in such a way that advanced applications can alter the normal
behaviour.

This really gets to the core of why the .NET system was devloped - Sun took
legal action to stop MS 'embracing and extending' Java so that developers
would be tempted into writing software that would only run Windows. In .NET
they have a platform, most of which is just as portable as Java, but in a
crucial but subtle way they have made it difficult to implement 100% on an
OS other than Windows.

My view is that you should provide bindings for people that want to use
GTK+, exposing the GTK+ interfaces the way they were intended to be used so
that people who are targetting mono as their platform can get the best
performance. Then for running applications designed for Windows you will
have a much better chance of sucess if System.Windows.Forms and associated
packages are based on a Windows porting library like Winelib or similar.

Regards,

Richard

btw. I would offer to help with this but the speed mono is moving at the
moment someone else will probably have implemented System.Windows.Forms by
the time this email reaches you :)