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?
To get the Windows.Forms support working, you need:
- 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.