There are a number of GUI toolkit options available for developers using the Mono platform, at various degrees of completion and various degrees of functionality. I present here some of the options available.

Gtk#: http://gtk-sharp.sf.net

This toolkit is a .NET binding for the Gtk+ toolkit. It is in active development, and there are various applications in the Mono world that use it: Monodoc, Monocov, Mono's Debugger, Muine, Tomboy, Dashboard, F-Spot, iFolder and various smaller applications, a more complete list is available on the Gtk# Wiki.

Platforms: Unix, Windows, GPE, MacOS X (using the X server).

Pros:

• The official toolkit of the Mono project.
• Maintained by Novell.
• Good support for accessibility through its Gtk+'s heritage.
• Layout engine ideal for handling internationalized environments, and adapts to font-size without breaking applications.
• Applications integrate with the Gnome Desktop.
• API is familiar to Gtk+ developers.
• Large Gtk+ community.
• A Win32 port is available, with native look on Windows XP and Windows 2000.
• The API is fairly stable at this point, and syntactic sugar is being added to improve it.
• Unicode support is exceptional.
• HTML control (rendering and editing).
• Integrates with Mozilla on Unix.
• GUIs can be prototyped with Glade, and embedded into the executable as a resource.
• Supports both System.Drawing and Cairo for painting.

Cons:

• Binding largely automatically generated, it requires an audit to be performed, sometimes problems are found by writing sample code for it.
• Gtk+ apps run like foreign applications on MacOS X. Immendio is working on supporting Gtk+ natively on OSX without X.
• Gtk+ is less polished on Windows than it is on Linux.
• Partial documentation.
• No data-bound controls.

Windows.Forms

This is part of the standard Mono distribution.

This is a work-in-progress effort to implement the Microsoft System.Windows.Forms API. The API is not complete enough for many tasks, so developers (in particular third-party developers that provide custom controls) resort to use the underlying Win32 subsystem on Windows to provide features which are not exposed by Windows.Forms.

In some cases it is necessary to provide support for the Wndproc method and the various messages associated with it, and support extra functionality available in Win32 through P/Invoke, as well as exposing and sharing various kinds of handles (fonts, drawing contexts, drawing surfaces, windows).

There are two levels of conformance in this API: The full Windows.Forms from the .NET Framework 1.0 and 1.1, and the subset exposed by the Compact Framework.

Pros:

• Extensive documentation exists for it (books, tutorials, online documents).
• Visual Studio .NET IDE and Sharp Develop IDE.
• Data bound controls.

Cons:

• Not very complete API, developers have to resort to underlying implementation to achieve certain things.
• Bad layout mechanisms: font size changes, and internationalization require manual relayout most of the time.
• All the Windows.Forms efforts are under heavy development, they are unstable and lack plenty of features at this point.

The Windows.Forms API has a poor layout engine, which is based on absolute positioning.

Implementation: Mono's Managed Windows.Forms

Our Windows.Forms implementation is implemented on top of the GDI+ API for rendering and a relatively small driver to interact with the host windowing system. Our GDI+ implementation on Unix (Linux and OSX) uses Cairo as the rendering engine. As for the windowing system drivers, today we have two complete drivers (Unix/X11 and Win32) and one driver under development (OSX).

Pros:

• Few dependencies.
• Thin version of Windows.Forms.
• Heavy lifting done in C#.

Cons:

• Partial compatibility with Windows.Forms: simple programs will run, but programs using P/Invoke will likely fail.
• Large Windows.Forms applications unlikely to work.
• Although a rendering interface exists, today only two stock themes exist: Win32-look is one of them.
• By not using an existing toolkit, there are plenty of problems found on early from-scratch toolkits: like poor rendering speed and accessibility.

Sharp WT: http://sourceforge.net/projects/sharpdevelop

This is a project started by the developers of SharpDevelop.

The project started due to the limitations on Windows.Forms and the need to port their large application to Linux. They picked the SWT toolkit which is part of Eclipse and ported it from Java to C#.

SWT uses native widgets on each one of its target platforms, so the look and feel matches the underlying operating system.

Pros:

• Native look and feel on various platforms (Windows, Linux and MacOS).
• Clean design.
• The Java version has been successfully used by the Eclipse project.

Cons:

• Little or no documentation.
• Authoring new widgets is either hard (due to testing on multiple platforms), or the look and feel is unique.
• Still under heavy development.
• Common denominator subset API problem.
• No data-bound controls.
• The project has been abandoned at of May 2004.

Qt#: http://qtcsharp.sourceforge.net/

This is a binding to the Qt toolkit. This toolkit used to be under development, but its development has pretty much stopped.

Pros:

• Native look on each platform, and partial feel on each platform.
• Substrate (Qt) is well documented, .NET bindings lack documentation.

Cons:

• Toolkit is licensed under the GPL, and the Qt substrate has further licensing limitations. It is not suitable for proprietary or non-GPL development.
• Binding is not actively developed.
• Currently its layered on top of the C binding to Qt.

wxNet: http://wxnet.sourceforge.net/

wxNet is a .NET binding for the wxWindows cross-platform toolkit.

Pros:

• Native look and feel on each platform.
• Substrate (wxWindows) is well documented, .NET binding lacks documentation.

Cons:

• Binding to non-supported extra widgets is hard.
• Custom-authored widgets look and feel is not preserved across platforms.
• Common denominator subset API problem.
• No data-bound controls.