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