doc/winforms

   1 * System.Windows.Forms
   2
   3         System.Windows.Forms is currently being implemented using the
   4         Win32 API, we will be using <a
   5         href="http://www.winehq.com">WineLib</a> on Unix systems to
   6         emulate the Win32 API.
   7
   8         This means that those who want to contribute to the effort can
   9         develop and test classes today using Windows and P/Invoke
  10         calls to Win32 and we will then just run the result on Unix.
  11
  12         In terms of integrating visually with the desktop, we are
  13         hoping to contribute to the Wine project an mechanism to make
  14         it use the Gtk+ themes on X11 and Cocoa on MacOS to render the
  15         widgets, and get the native look and feel on each of these
  16         platforms.
  17
  18         There are no current plans to support embedded devices, but
  19         Gtk/FrameBuffer is an option.  If you have suggestions or
  20         recommendations, please let us <a
  21         href="mailto:mono-hackers-list@ximian.com">let us know</a>
  22
  23 * Contributing
  24
  25         The Winforms effort is being coordinated in the <a
  26         href="mailto:mono-winforms-list@ximian.com:.com">mono-winforms-list@ximian.com</a>.
  27         If you are interested in helping out with this effort,
  28         subscribe to it by sending an email message to <a
  29         href="mailto:mono-winforms-list-request@ximian.com:.com">mono-winforms-list-request@ximian.com</a>.
  30
  31         If you want to help, you can start by writing a control and
  32         testing it with Windows today (or you can also try to build
  33         the existing library on Linux, but this is a bit more
  34         complicated).
  35
  36         See the file mcs/class/System.Windows.Forms/CheckOutList for
  37         details on who is working on which class.
  38
  39         Please read the README document in the
  40         System.Windows.Forms/WINElib directory for details about how
  41         to build the Windows.Forms support for Mono.
  42
  43 * System.Drawing
  44
  45         Using existing libraries to implement some of the
  46         functionality required:
  47
  48         <ul>
  49                 * gdk-pixbuf is a generic image loader that loads an image
  50                   and leaves it into an RGB buffer.  It hides all the details
  51                   about what image file format is being loaded.
  52
  53                 * Libart is a general framework for rendering RGB/RGBA
  54                   buffers into RGB buffers and rendering postscript-like paths into
  55                   RGB/RGBA buffers.
  56         </ul>
  57
  58         We want to use gdk-pixbuf as the image loader for the image
  59         classes, and then we need operations to render that into the
  60         windowing system (Gtk+, MacOS, etc).  But notice how there is
  61         very little dependnecies in Gdk-pixbuf on gtk, and libart has
  62         none.
  63
  64         They are pretty independent from a windowing system
  65         (gdk-pixbuf comes with some "helper" routines for rendering
  66         data into a pixmap and to load pixmaps into RGB buffers).
  67
  68         A few things to keep in mind:
  69
  70         <ul>
  71
  72                 * gdk-pixbuf can be used to load images for Gtk+,
  73                   MacOS X and Windows, it should be pretty portable,
  74                   although we might need in the future to back-port
  75                   some new features from Gtk head.
  76
  77                 * Libart is probably only going to be used with X11,
  78                   as the MacOS X provides the same features in Quartz,
  79                   and Win32 *probably* has that in GDI+.  If not, we
  80                   should use libart in Win32 as well (or for older
  81                   Windows systems).
  82         </ul>
  83
  84 * Directory Layout
  85
  86 <pre>
  87         System.Drawing  (assembly directory)
  88                 System.Drawing.Blah
  89                         Common code for "Blah"
  90                         Stubs for "Blah" to ease ports.
  91
  92                 Gtk
  93                         System.Drawing.Blah.
  94                                 Gtk ports of "System.Drawing.Blah"
  95                 MacOS
  96                         System.Drawing.Blah
  97                                 MacOS ports of "System.Drawing.Blah"
  98                 WineLIB
  99                         System.Drawing.Blah
 100                                 Win32 ports of "System.Drawing.Blah"
 101 </pre>
 102
 103         Notice that there is a proof of concept Gtk-backend for
 104         Windows.Forms, but nobody is working on it, and for the
 105         reasons stated before it is not a long term strategy.
 106
 107 * Open questions:
 108
 109         I believe that the graphics contexts that are used to render
 110         can accept either libart-like rendering operations and
 111         X11-like rendering operations.  This complicates matters, but
 112         I am not sure.  Someone needs to investigate this.
 113
 114 * Historical
 115
 116         Although the original plans were to use Gtk on X and Cocoa on
 117         MacOS X, it would be very hard to emulate the event model in
 118         which some Winforms applications depend, and it would be very
 119         hard to implement the Wndproc method.
 120