X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fwinforms;h=a9a5e8ae54cd539a08ac0318e145162987b8534b;hb=831403d104705c81d2fdb98473855da2e3076311;hp=5d162147132bde0d51279eab62069c30eff5780c;hpb=ff5a77dee674b859f741e2cd495063cc52e98b35;p=mono.git diff --git a/web/winforms b/web/winforms index 5d162147132..a9a5e8ae54c 100644 --- a/web/winforms +++ b/web/winforms @@ -1,117 +1,81 @@ * System.Windows.Forms - System.Windows.Forms is currently being implemented using the - Win32 API, we will be using WineLib 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. - - There are no current plans to support embedded devices, but - Gtk/FrameBuffer is an option. If you have suggestions or - recommendations, please let us let us know - -* Contributing - - The Winforms effort is being coordinated in the mono-winforms-list@ximian.com. - If you are interested in helping out with this effort, - subscribe to it by sending an email message to mono-winforms-list-request@ximian.com. - - 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). - - Please read the README document in the - System.Windows.Forms/WINElib directory for details about how - to build the Windows.Forms support for Mono. +

Currently Windows.Forms support is under heavy development. Check Mono's Roadmap for more + details on when it is going to be available. + +

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. + +

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 +

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?

- 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: +

To get the Windows.Forms support working, you need:

-* Directory Layout - -
-        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"
-
- - 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 + 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. + +

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. + +* Contributing + +

The Winforms effort is being coordinated in the mono-winforms-list@ximian.com. + If you are interested in helping out with this effort, + subscribe to it by sending an email message to mono-winforms-list-request@ximian.com. + +

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. + +

If you choose a particular control to work on, send a note to the + winforms list to avoid duplication of effort. - 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. + +* System.Drawing + +

For details, see the System.Drawing implementation notes + section of the web site.