web/winforms

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