web/winforms

   1 * System.Windows.Forms
   2
   3         Currently Windows.Forms support is not finished.
   4
   5         The System.Windows.Forms effort is taking two paths:
   6
   7         <ul>
   8                 <li>Win32/Wine-based: This effort will use the Win32
   9                 API, and use a stub program to run the with Wine.
  10                 This allows applications that use P/Invoke to
  11                 function, and event delivery through the Wndproc
  12                 method to work for the most advanced and custom
  13                 applications.  This is the path of best compatibility.
  14
  15                 Also, work on a Gtk-based rendered for Wine will be
  16                 done, to make the user interface integrate with your
  17                 desktop look.
  18
  19                 <li>Gtk# based: This effort will build a subset of
  20                 Windows.Forms that uses Gtk#.  This gives a better
  21                 integration with the desktop, but will not be
  22                 completely compatible with the Windows edition.  In
  23                 particular code that uses P/Invoke to call into Win32
  24                 or overwrite the Wndproc method to achieve special
  25                 effects will not work.
  26         </ul>
  27
  28 * Win32/Wine edition.
  29
  30         Currently (May 21st, 2003) to get the Windows.Forms support
  31         working, you need a Mono installation from CVS, and you need
  32         to install Wine plus the <a
  33         href="http://www.openlinksw.com">OpenLink patch</a>, and
  34         define the environment variable "SWF" (export SWF=1 from your
  35         shell).
  36
  37         <table>
  38         <tr>
  39         <td>
  40         System.Windows.Forms is currently being implemented using the
  41         Win32 API, we will be using <a
  42         href="http://www.winehq.com">WineLib</a> on Unix systems to
  43         emulate the Win32 API.
  44
  45         This means that those who want to contribute to the effort can
  46         develop and test classes today using Windows and P/Invoke
  47         calls to Win32 and we will then just run the result on Unix.
  48
  49         In terms of integrating visually with the desktop, we are
  50         hoping to contribute to the Wine project an mechanism to make
  51         it use the Gtk+ themes on X11 and Cocoa on MacOS to render the
  52         widgets, and get the native look and feel on each of these
  53         platforms.
  54         </td>
  55         <td>
  56         <a href="images/WINESWF.JPG"><img src="images/WINESWF-mini.JPG"></a>
  57         </td>
  58
  59         </table>
  60
  61 * Gtk# based
  62
  63         The code is contained in CVS.
  64
  65         There are no current plans to support embedded devices, but
  66         Gtk/FrameBuffer is an option.  If you have suggestions or
  67         recommendations, please let us <a
  68         href="mailto:mono-hackers-list@ximian.com">let us know</a>
  69
  70 * Contributing
  71
  72         The Winforms effort is being coordinated in the <a
  73         href="mailto:mono-winforms-list@ximian.com:.com">mono-winforms-list@ximian.com</a>.
  74         If you are interested in helping out with this effort,
  75         subscribe to it by sending an email message to <a
  76         href="mailto:mono-winforms-list-request@ximian.com:.com">mono-winforms-list-request@ximian.com</a>.
  77
  78         If you want to help, you can start by writing a control and
  79         testing it with Windows today (or you can also try to build
  80         the existing library on Linux, but this is a bit more
  81         complicated).
  82
  83         See the file mcs/class/System.Windows.Forms/CheckOutList for
  84         details on who is working on which class.
  85
  86         Please read the README document in the
  87         System.Windows.Forms/WINElib directory for details about how
  88         to build the Windows.Forms support for Mono.
  89
  90 * System.Drawing
  91
  92         Using existing libraries to implement some of the
  93         functionality required:
  94
  95         <ul>
  96                 * gdk-pixbuf is a generic image loader that loads an image
  97                   and leaves it into an RGB buffer.  It hides all the details
  98                   about what image file format is being loaded.
  99
 100                 * Libart is a general framework for rendering RGB/RGBA
 101                   buffers into RGB buffers and rendering postscript-like paths into
 102                   RGB/RGBA buffers.
 103         </ul>
 104
 105         We want to use gdk-pixbuf as the image loader for the image
 106         classes, and then we need operations to render that into the
 107         windowing system (Gtk+, MacOS, etc).  But notice how there is
 108         very little dependnecies in Gdk-pixbuf on gtk, and libart has
 109         none.
 110
 111         They are pretty independent from a windowing system
 112         (gdk-pixbuf comes with some "helper" routines for rendering
 113         data into a pixmap and to load pixmaps into RGB buffers).
 114
 115         A few things to keep in mind:
 116
 117         <ul>
 118
 119                 * gdk-pixbuf can be used to load images for Gtk+,
 120                   MacOS X and Windows, it should be pretty portable,
 121                   although we might need in the future to back-port
 122                   some new features from Gtk head.
 123
 124                 * Libart is probably only going to be used with X11,
 125                   as the MacOS X provides the same features in Quartz,
 126                   and Win32 *probably* has that in GDI+.  If not, we
 127                   should use libart in Win32 as well (or for older
 128                   Windows systems).
 129         </ul>
 130
 131 * Directory Layout
 132
 133 <pre>
 134         System.Drawing  (assembly directory)
 135                 System.Drawing.Blah
 136                         Common code for "Blah"
 137                         Stubs for "Blah" to ease ports.
 138
 139                 Gtk
 140                         System.Drawing.Blah.
 141                                 Gtk ports of "System.Drawing.Blah"
 142                 MacOS
 143                         System.Drawing.Blah
 144                                 MacOS ports of "System.Drawing.Blah"
 145                 WineLIB
 146                         System.Drawing.Blah
 147                                 Win32 ports of "System.Drawing.Blah"
 148 </pre>
 149
 150         Notice that there is a proof of concept Gtk-backend for
 151         Windows.Forms, but nobody is working on it, and for the
 152         reasons stated before it is not a long term strategy.
 153
 154 * Open questions:
 155
 156         I believe that the graphics contexts that are used to render
 157         can accept either libart-like rendering operations and
 158         X11-like rendering operations.  This complicates matters, but
 159         I am not sure.  Someone needs to investigate this.
 160
 161 * Historical
 162
 163         Although the original plans were to use Gtk on X and Cocoa on
 164         MacOS X, it would be very hard to emulate the event model in
 165         which some Winforms applications depend, and it would be very
 166         hard to implement the Wndproc method.
 167