X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=web%2Fwinforms;h=a9a5e8ae54cd539a08ac0318e145162987b8534b;hb=feca28835d4e3cb2be67bdcbd4f54fee62c3797a;hp=9e46af61340675b2388134a6b6a586a6ee47466a;hpb=7a8db76c1648ea032baa8b75d723a41d41899ab5;p=mono.git
diff --git a/web/winforms b/web/winforms
index 9e46af61340..a9a5e8ae54c 100644
--- a/web/winforms
+++ b/web/winforms
@@ -1,158 +1,81 @@
* System.Windows.Forms
- The System.Windows.Forms effort is taking two paths:
-
-
- - 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.
-
-
- 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.
-
-
-* Win32/Wine edition.
-
-
-
- |
- 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.
- |
-
- 
- |
+ 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.
-* Gtk# based
+
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.
- 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 let us know
-
-* Contributing
+* Why not use Wine?
- 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).
+ - Debugging with Wine was extremely hard, and Wine was a moving target,
+ some of the calls we relied on changed from release to release.
+
- Wine/GDI+ interactions were not efficient.
+
- Too many cooks contributed to the core, so it was hard to maintain.
+
- To many dependencies on install, many people where having problems getting
+ the very strict winelib requirements right.
- 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.
+ 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.
-* System.Drawing
- Using existing libraries to implement some of the
- functionality required:
+* Installation
+ To get the Windows.Forms support working, you need:
+
- * 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.
+
+ - The latest Mono package.
+
- The latest libgdiplus library.
+
- The latest Cairo vector graphics library.
+
- 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 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.
- 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).
+ 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.
- A few things to keep in mind:
-
-
-
- * 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).
-
+* Contributing
-* 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 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.
-