Table of Contents
Quick Resources
- Guide: Getting Started
- Guide: Porting Winforms Applications to Mono
- Guide: Debugging Winforms Applications with Visual Studio
- Frequently Asked Questions about WinForms
- Bugs Current (http://bugzilla.novell.com/buglist.cgi?product=Mono%3A+Class+Libraries&component=Windows.Forms&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_id), Submit New (http://bugzilla.novell.com/enter_bug.cgi?alias=&assigned_to=&blocked=&bug_file_loc=http%3A%2F%2F&bug_severity=Normal&bug_status=NEW&cf_foundby=---&cf_nts_priority=&cf_nts_support_num=&cf_partnerid=&comment=Description%20of%20Problem%3A%0D%0A%0D%0A%0D%0ASteps%20to%20reproduce%20the%20problem%3A%0D%0A1.%20%0D%0A2.%20%0D%0A%0D%0A%0D%0AActual%20Results%3A%0D%0A%0D%0A%0D%0AExpected%20Results%3A%0D%0A%0D%0A%0D%0AHow%20often%20does%20this%20happen%3F%20%0D%0A%0D%0A%0D%0AAdditional%20Information%3A%0D%0A%0D%0A%0D%0A&component=Windows.Forms&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&deadline=&dependson=&description=&estimated_time=0.0&flag_type-2=X&form_name=enter_bug&keywords=&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Other&priority=P5%20-%20None&product=Mono%3A%20Class%20Libraries%20&qa_contact=&rep_platform=Other&short_desc=&version=unspecified)
- Some Winforms Samples
Code Status
Support for Windows Forms 2.0 is complete. At this point, we are largely just fixing bugs and polishing our code.
About System.Windows.Forms
System.Windows.Forms (aka Managed.Windows.Forms, MWF, Winforms) is one of the many GUI Toolkits for use with Mono, working towards compatibility with Microsoft's System.Windows.Forms. Support for Winforms 1.1 and 2.0 has been completed, and is now in a maintenance/bug fixing state.
System.Windows.Forms in Mono is implemented using System.Drawing. All controls are natively drawn through System.Drawing. System.Windows.Forms implements its own driver interface to communicate with the host OS windowing system. Currently, we have drivers for X11, Win32, and OSX. These drivers translate the native window messages into WndProc compatible messages, to provide as much compatibility with native .Net as possible.
In terms of integrating visually with the desktop, we currently ship with a classic Win32 theme.
Contributing
The Winforms effort is being coordinated on the Mono-Winforms-List mailing list. If you would like to contribute, or need help using Winforms, it is suggested that you subscribe to this mailing list. (See Mailing Lists for details.)
Currently, all of the controls are pretty much complete. We are now mainly fixing bugs in our implementation. See Bugs.
If you would like to contribute, you can:
- If you find a bug in one of our methods, you can file a bug with a small test case.
- You can fix a bug in one of our methods, either that you found or from our bugs page.
Please note there are a few rules for contributing to Winforms:
- The general rules from Contributing, especially the Special Notes at the bottom.
- Controls must be drawn using System.Drawing code.
- Drawing code must be tied into the theming interface.
- If your method can be tested by an automated NUnit test, please include a test as well.
If you are working on a large feature, you may wish to post your intent on the mailing list to prevent duplication of effort.
Drivers
There is a per-windowing system driver which performs the following tasks:
- Keyboard input
- Window creation
- Event translation
Mono's Windows.Forms implementation translates the native system events such as X11 into Win32 WM_ messages and dispatches them using the WndProc mechanism. This allows applications that depend on overriding WndProc to get some features not exposed by the APIs to still run.
Accessibility
Currently Windows.Forms does not support accessibility, this is being worked on in a separate project that started in January of 2008. See the Accessibility page for details about how this will integrate into the system.
Sample Code
Sample applications for Mono's Windows.Forms are available from:
Winforms Samples
On Mono's Public SVN.
SVN: svn://anonsvn.mono-project.com/source/trunk/winforms
Web: web access (http://anonsvn.mono-project.com/viewvc/trunk/winforms)
Ports of OpenSource applications
On Mono's SVN (requires SVN account)
SVN: svn+ssh://username@mono-cvs.ximian.com/extras/trunk/wf-apps
Theming
This section discusses the theming issues in Mono's implementation of Windows Forms as these questions are asked frequently:
Why Not Use Native Widgets?
It is not feasible to use native widgets on all operating systems. Each OS/Windowing system has different behavior/properties/features for what on the surface looks like the same widget. A RadioButton in Gnome is different from a RadioButton in Win32, which is different from a RadioButton in OS X. To use the native widgets means to reduce the functionality of MWF to the least common denominator of all supported operating systems. If we were designing our own GUI toolkit, this might even be acceptable, however we are implementing an already defined API with defined behavior (and even with application relied-upon side-effects). A RadioButton has to behave exactly like it behaves on Win32 with MS.Net, or else applications written for it may not work properly anymore. And that's the whole point of Winforms: to allow existing .Net SWF apps to run on Mono. For other uses, there are other choices that may be more appropriate, such as Gtk#.
Fitting In
Although we cannot use native widgets, we still would like to make a reasonable effort to achieve a more native "look and feel" on different platforms. To accomplish this, we have created a theming interface with the hope that in the future it will facilitate our controls looking more native. Having a separate theme class from the get-go forces those who are writing the controls to design code where the drawing code is not integrated and intermingled with the control code.
Maturity of the Theming Interface
The theming interface is required to skin applications to meet the look and feel of their host operating system, but it is by no means complete today.
It is very conceivable that we will redesign parts of it. We knew from the get-go that the theming interface wasn't gonna work the way it is. However, until all controls are written and we can look at what the drawing requirements for each control are, there was no point in designing a complete theming interface (short of an academic exercise, where the API is discussed for several years in committee hell, and we were planning on having a usable toolkit this decade).
The solution is that we came up with something very simple, played a bit with a proof-of-concept Gtk theme to ensure that what we had was somewhat realistic, and went on to write the controls. Obviously, some people got a bit sloppy and put control logic into the drawing code, but that will be taken care of once we start work on the themes. Today, all controls are written to match the classic Win32 interface. There are some other themes of varying completeness. See the FAQ for details.
History
There were two previous attempts to implement System.Windows.Forms in Mono. These initial attempts were done on top of other toolkits: first Gtk, then Wine. Each one had its share of problems, causing it to be abandoned.
The Gtk effort had the following problems:
- Mapping one toolkit's semantics to another was very hard.
- It would be very cumbersome to map all events into WndProc events, the messaging system at the core of Windows.Forms.
- The development effort happened early in the Mono life, with this very sporadic development effort, the code quickly became obsolete or bit-rotted.
- Using this on other systems required a Gtk+ installation on the target system (OS X and embedded devices would have suffered the most).
The Wine effort could have been a successful approach, however there were several technical obstacles:
- Multithreading support. Wine has a specific thread setup that is not compatible with Mono. While this was solvable, it would have required larger patches to Wine.
- Dependencies. To have Mono and Wine interoperate, a glue library was required. This library required to know where Wine was installed to (we had a Wine patch that eased this requirement, but it was not accepted into Wine).
- Moving target. Key functions in Wine changed often enough that with every Wine release we had to start over making our glue code work again, sometimes becoming incompatible with previous Wine versions.
- Wine/Gdi+ interactions: The way System.Drawing had to be made compatible with Wine was extremely inefficient. Wine uses the GDI model (raster painting), while our System.Drawing implementation, built on top of Cairo, uses the GDI+ model (compositing model). Making them both talk was extremely inefficient as every transition from one model to the other required the bitmaps to be copied.
The current approach is to implement all controls fully in managed code, and uses an abstract theme interface to paint the widgets. The default theme interfaces renders the widgets using System.Drawing.
WinForms Designer
For more information check here.
