* System.Windows.Forms
- System.Windows.Forms eventually will support multiple
- toolkits. Ximian will be delivering a product that will allow
- for System.Windows.Forms applications to integrate with GNOME
- through Gtk and MacOS X using Cocoa.
+ Currently Windows.Forms support is not finished.
- 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:mono-hackers-list@ximian.com">let us know</a>
-
-* Contributing
+ The System.Windows.Forms effort is taking two paths:
- Currently Ximian developers are busy making our JIT engine
- feature complete, and dealing with the low-level details of
- the Mono runtime.
-
- If you are interested in contributing, you can start stubbing
- out classes and providing enumerations. That will help us
- significantly when we start working on the actual bindings.
-
- Christian Meyer is currently organizing this effort.
+ <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>
-* System.Drawing
+* Win32/Wine edition.
+
+ 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). For more information, see the <a
+ href="http://www.nullenvoid.com/mono/wiki/index.php/MonoWinePackages">Mono
+ Wine Packages</a> page in the Mono Wiki.
+
+ <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 a 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>
- Using existing libraries to implement some of the functionality required
+* Gtk# based
- <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.
+ The code is contained in CVS.
- * Libart is a general framework for rendering RGB/RGBA
- buffers into RGB buffers and rendering postscript-like paths into
- RGB/RGBA buffers.
- </ul>
+ 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:mono-hackers-list@ximian.com">let us know</a>
- 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.
+* Contributing
- 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).
+ The Winforms effort is being coordinated in the <a
+ href="mailto:mono-winforms-list@ximian.com:.com">mono-winforms-list@ximian.com</a>.
+ If you are interested in helping out with this effort,
+ subscribe to it by sending an email message to <a
+ href="mailto:mono-winforms-list-request@ximian.com:.com">mono-winforms-list-request@ximian.com</a>.
- 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>
+ 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).
-* Directory Layout
+ See the file mcs/class/System.Windows.Forms/CheckOutList for
+ details on who is working on which class.
- System.Drawing (assembly directory)
- System.Drawing.Blah
- Common code for "Blah"
- Stubs for "Blah" to ease ports.
+ Please read the README document in the
+ System.Windows.Forms/WINElib directory for details about how
+ to build the Windows.Forms support for Mono.
- Gtk
- System.Drawing.Blah.
- Gtk ports of "System.Drawing.Blah"
- MacOS
- System.Drawing.Blah
- MacOS ports of "System.Drawing.Blah"
- Win32
- System.Drawing.Blah
- Win32 ports of "System.Drawing.Blah"
+* System.Drawing
- Then we use nant targets to include/exclude the right set of
- files to create the assembly.
+ We currently have two code paths: the Wine-based
+ System.Drawing and the Cairo-based one. We will eventually
+ unify everything to use Cairo, but currently the effort can
+ continue with the approach we have.
-* 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.