diff options
Diffstat (limited to 'web/winforms')
| -rw-r--r-- | web/winforms | 129 |
1 files changed, 60 insertions, 69 deletions
diff --git a/web/winforms b/web/winforms index 2d8c1e3d79d..a9a5e8ae54c 100644 --- a/web/winforms +++ b/web/winforms @@ -1,90 +1,81 @@ * 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. - - 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 - - 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. + <p>Currently Windows.Forms support is under heavy development. Check Mono's <a + href = "http://www.go-mono.com/mono-roadmap.html">Roadmap</a> for more + details on when it is going to be available. + + <p>System.Windows.Forms in Mono is implemented using System.Drawing. All controls + are natively drawn through System.Drawing. System.Windows.Forms implements it's own + driver interface to communicate with the host OS windowing system. Currently, + we have a driver for Win32 and a driver for X11. + The drivers translate the native window messages into WndProc compatible messages, + to provide as much compatibility with native .Net as possible. + + <p>In terms of integrating visually with the desktop, we have a (still incomplete) + themeing interface, currently with a classic Win32 theme and a Gtk theme. -* System.Drawing + <p>The current implementation is still very incomplete, with several large controls + (Edit, ListBox, ComboBox, Menus), etc, still being developed. It is too early to + file bugs if you cannot compile or run a certain application because of controls + missing. - Using existing libraries to implement some of the functionality required +* Why not use Wine? <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. + <li>Debugging with Wine was extremely hard, and Wine was a moving target, + some of the calls we relied on changed from release to release. + <li>Wine/GDI+ interactions were not efficient. + <li>Too many cooks contributed to the core, so it was hard to maintain. + <li>To many dependencies on install, many people where having problems getting + the very strict winelib requirements right. + </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. + The driver interface should allow us to also create a Wine based driver for + System.Windows.Forms, to support applications performing Win32 P/Invokes, but + for now this is not a priority. + - 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). +* Installation - A few things to keep in mind: + <p>To get the Windows.Forms support working, you need: <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). + <li> The latest <a href = "http://www.go-mono.com/download.html">Mono</a> package. + <li> The latest <a href = "http://www.go-mono.com/download.html">libgdiplus</a> library. + <li> The latest <a href = "http://www.cairographics.org/download">Cairo</a> vector graphics library. + </ul> -* Directory Layout + The current source of System.Windows.Forms resides in mcs/class/Managed.Windows.Forms. + The previous version of System.Windows.Forms, based on Wine, still can be found in + mcs/class/System.Windows.Forms, but it is no longer being worked on. - System.Drawing (assembly directory) - System.Drawing.Blah - Common code for "Blah" - Stubs for "Blah" to ease ports. + <p>To use the latest version, go into Managed.Windows.Forms and issue a 'make clean', + followed by a 'make install'. Afterwards, the new implementation should be available + in the GAC for your use. - 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" +* Contributing - Then we use nant targets to include/exclude the right set of - files to create the assembly. + <p>The Winforms effort is being coordinated in the <a + href="mailto:mono-winforms-list@ximian.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">mono-winforms-list-request@ximian.com</a>. + + <p>If you want to help, you can pick a control and start implementing it's + methods. You can do this either on Windows or on Linux. All controls must be drawn + using System.Drawing calls, tied into the themeing interface, and not stubbed. + + <p>If you choose a particular control to work on, send a note to the + winforms list to avoid duplication of effort. + + +* System.Drawing -* Open questions: + <p>For details, see the <a + href="drawing.html">System.Drawing implementation notes</a> + section of the web site. - 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. |