bb61a5aca8d7cf54c45b0c09b4802415bae7df2f
[mono.git] / web / 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         Although the original plans were to use Gtk on X and Cocoa on
9         MacOS X, it would be very hard to emulate the event model in
10         which some Winforms applications depend, and it would be very
11         hard to implement the Wndproc method.  
12
13         In terms of integrating visually with the desktop, we are
14         hoping to contribute to the Wine project an mechanism to make
15         it use the Gtk+ themes on X11 and Cocoa on MacOS to render the
16         widgets, and get the native look and feel on each of these
17         platforms. 
18
19         There are no current plans to support embedded devices, but
20         Gtk/FrameBuffer is an option.  If you have suggestions or
21         recommendations, please let us <a
22         href="mailto:mono-hackers-list@ximian.com">let us know</a>
23
24 * Contributing
25
26         The Winforms effort is being coordinated by <a
27         href="DENNISH@Raytek.com">Dennis Hayes</a>.  If you are
28         interested in helping out with this effort, get in touch with
29         him.
30
31 * System.Drawing
32
33         Using existing libraries to implement some of the
34         functionality required:
35
36         <ul>
37                 * gdk-pixbuf is a generic image loader that loads an image
38                   and leaves it into an RGB buffer.  It hides all the details
39                   about what image file format is being loaded.
40
41                 * Libart is a general framework for rendering RGB/RGBA
42                   buffers into RGB buffers and rendering postscript-like paths into
43                   RGB/RGBA buffers.
44         </ul>
45
46         We want to use gdk-pixbuf as the image loader for the image
47         classes, and then we need operations to render that into the
48         windowing system (Gtk+, MacOS, etc).  But notice how there is
49         very little dependnecies in Gdk-pixbuf on gtk, and libart has
50         none.
51
52         They are pretty independent from a windowing system
53         (gdk-pixbuf comes with some "helper" routines for rendering
54         data into a pixmap and to load pixmaps into RGB buffers).
55
56         A few things to keep in mind:
57         
58         <ul>
59         
60                 * gdk-pixbuf can be used to load images for Gtk+,
61                   MacOS X and Windows, it should be pretty portable,
62                   although we might need in the future to back-port
63                   some new features from Gtk head. 
64
65                 * Libart is probably only going to be used with X11,
66                   as the MacOS X provides the same features in Quartz,
67                   and Win32 *probably* has that in GDI+.  If not, we
68                   should use libart in Win32 as well (or for older
69                   Windows systems).
70         </ul>
71
72 * Directory Layout
73
74         System.Drawing  (assembly directory)
75                 System.Drawing.Blah
76                         Common code for "Blah"
77                         Stubs for "Blah" to ease ports.
78
79                 Gtk
80                         System.Drawing.Blah.
81                                 Gtk ports of "System.Drawing.Blah"
82                 MacOS
83                         System.Drawing.Blah
84                                 MacOS ports of "System.Drawing.Blah"
85                 WineLIB
86                         System.Drawing.Blah
87                                 Win32 ports of "System.Drawing.Blah"
88
89         Notice that there is a proof of concept Gtk-backend for
90         Windows.Forms, but nobody is working on it, and for the
91         reasons stated before it is not a long term strategy.
92
93 * Open questions:
94
95         I believe that the graphics contexts that are used to render
96         can accept either libart-like rendering operations and
97         X11-like rendering operations.  This complicates matters, but
98         I am not sure.  Someone needs to investigate this.