mono/web/winforms

* System.Windows.Forms

	Currently Windows.Forms support is not finished.

	The System.Windows.Forms effort is taking two paths: 

	<ul>
		<li>Win32/Wine-based: This effort will use the Win32
		API, and use a stub program to run the with Wine.
		This allows applications that use P/Invoke to
		function, and event delivery through the Wndproc
		method to work for the most advanced and custom
		applications.  This is the path of best compatibility.

		Also, work on a Gtk-based rendered for Wine will be
		done, to make the user interface integrate with your
		desktop look.

		<li>Gtk# based: This effort will build a subset of
		Windows.Forms that uses Gtk#.  This gives a better
		integration with the desktop, but will not be
		completely compatible with the Windows edition.  In
		particular code that uses P/Invoke to call into Win32
		or overwrite the Wndproc method to achieve special
		effects will not work.
	</ul>

* Win32/Wine edition.

	Currently (May 21st, 2003) to get the Windows.Forms support
	working, you need a Mono installation from CVS, and you need
	to install Wine plus the <a
	href="http://www.openlinksw.com">OpenLink patch</a>, and
	define the environment variable "SWF" (export SWF=1 from your
	shell). 

	<table>
	<tr>
	<td>
	System.Windows.Forms is currently being implemented using the
	Win32 API, we will be using <a
	href="http://www.winehq.com">WineLib</a> on Unix systems to
	emulate the Win32 API.

	This means that those who want to contribute to the effort can
	develop and test classes today using Windows and P/Invoke
	calls to Win32 and we will then just run the result on Unix. 

	In terms of integrating visually with the desktop, we are
	hoping to contribute to the Wine project an mechanism to make
	it use the Gtk+ themes on X11 and Cocoa on MacOS to render the
	widgets, and get the native look and feel on each of these
	platforms. 
	</td>
	<td>
	<a href="images/WINESWF.JPG"><img src="images/WINESWF-mini.JPG"></a>
	</td>
	
	</table>

* Gtk# based

	The code is contained in CVS.  

	There are no current plans to support embedded devices, but
	Gtk/FrameBuffer is an option.  If you have suggestions or
	recommendations, please let us <a
	href="mailto:[email protected]">let us know</a>

* Contributing

	The Winforms effort is being coordinated in the <a
	href="mailto:[email protected]:.com">[email protected]</a>.
	If you are interested in helping out with this effort,
	subscribe to it by sending an email message to <a
	href="mailto:[email protected]:.com">[email protected]</a>.

	If you want to help, you can start by writing a control and
	testing it with Windows today (or you can also try to build
	the existing library on Linux, but this is a bit more
	complicated).  

	See the file mcs/class/System.Windows.Forms/CheckOutList for
	details on who is working on which class.

	Please read the README document in the
	System.Windows.Forms/WINElib directory for details about how
	to build the Windows.Forms support for Mono.

* System.Drawing

	Using existing libraries to implement some of the
	functionality required:

	<ul>
		* gdk-pixbuf is a generic image loader that loads an image
		  and leaves it into an RGB buffer.  It hides all the details
		  about what image file format is being loaded.

		* Libart is a general framework for rendering RGB/RGBA
		  buffers into RGB buffers and rendering postscript-like paths into
		  RGB/RGBA buffers.
	</ul>

	We want to use gdk-pixbuf as the image loader for the image
	classes, and then we need operations to render that into the
	windowing system (Gtk+, MacOS, etc).  But notice how there is
	very little dependnecies in Gdk-pixbuf on gtk, and libart has
	none.

	They are pretty independent from a windowing system
	(gdk-pixbuf comes with some "helper" routines for rendering
	data into a pixmap and to load pixmaps into RGB buffers).

	A few things to keep in mind:
	
	<ul>
	
		* gdk-pixbuf can be used to load images for Gtk+,
		  MacOS X and Windows, it should be pretty portable,
		  although we might need in the future to back-port
		  some new features from Gtk head. 

		* Libart is probably only going to be used with X11,
		  as the MacOS X provides the same features in Quartz,
		  and Win32 *probably* has that in GDI+.  If not, we
		  should use libart in Win32 as well (or for older
		  Windows systems).
	</ul>

* Directory Layout

<pre>
        System.Drawing  (assembly directory)
                System.Drawing.Blah
                        Common code for "Blah"
                        Stubs for "Blah" to ease ports.

                Gtk
                        System.Drawing.Blah.
                                Gtk ports of "System.Drawing.Blah"
                MacOS
                        System.Drawing.Blah
                                MacOS ports of "System.Drawing.Blah"
                WineLIB
                        System.Drawing.Blah
                                Win32 ports of "System.Drawing.Blah"
</pre>

	Notice that there is a proof of concept Gtk-backend for
	Windows.Forms, but nobody is working on it, and for the
	reasons stated before it is not a long term strategy.

* Open questions:

	I believe that the graphics contexts that are used to render
	can accept either libart-like rendering operations and
	X11-like rendering operations.  This complicates matters, but
	I am not sure.  Someone needs to investigate this.

* Historical 
	
	Although the original plans were to use Gtk on X and Cocoa on
	MacOS X, it would be very hard to emulate the event model in
	which some Winforms applications depend, and it would be very
	hard to implement the Wndproc method.