[Mono-list] Windows forms.

[Miguel de Icaza]

Hello everyone,

    I have received plenty of e-mails about people who want to see
Windows Forms supported by Mono.  As I said in my mail, I am still thorn
about what should we do about this.  In one hand, I can see how many
people would be able to write applications in Windows and move them over
to Linux.  

    In the other hand, Windows.Forms is packed with quirks and is not
that great of a toolkit in the first place.  Up to the point of the
unconfirmed rumor that Microsoft is working on a replacement for it. 

    As things stand right now, Ximian will focus on getting the Mono
runtime feature complete and then work on optimizing the JIT engine (the
current JIT is not even taking advantage of the instruction selection,
as we wanted to be feature complete before we would work on
optimizations).

    Once the runtime is done, we will very likely start contributing to
the Gtk# project ourselves, and we will likely start doing feasibility
work on getting Mono used by Gnome developers: full gnome apps and
extending existing applications [1].

    That being said, as any other open source effort, if there is enough
interest to make Windows.Forms happen, it will happen, but keep in mind
that it will be hard, and that Windows.Forms is *not that great* to
begin with.

    Those interested in hacking on Windows.Forms are welcome to do so,
but Ximian will not likely look at it in the near future;  if there is
enough demand, or I can be convinced that Windows.Forms is useful for
something Ximian might re-evaluate our resource allocation for this
task.

    Problems I see with Windows.Forms as the poorness of the toolkit:

	* Not everything can be done with the API binding,
	  so we will have to fall back to some kind of emulation 
	  of WndProc for *some* things.  People already depend on this.

	* Any app that uses P/Invoke for Win32 calls to do GUI stuff
	  will not work.

	* It is not designed for internationalization:

		* With Gtk, every widget is sized appropriately, based
	  	  on the size of the children widgets.  This means that
	 	  running translated applications "just works", and you
		  never, ever, *ever* encounter the broken behavior
		  you get in Windows (resize font, and get chopped
		  fonts, or fonts overwriting pieces of your apps,
	 	  hidden text, etc).

		* Gtk has semantic information about your dialog, and is
		  possible to do things like:

			http://www.pango.org/gallery.shtml

		  In Arabic countries, the dialog will "flow" correctly
		  for right-to-left reading (see the "Set Tree
		  Parameters" screenshots on that page).

		* In Gnome/Gtk we do not really hardcode the size of the
		  dialogs and locations in the source code, we use an 
		  external XML file that describes the dialog layout.

		  There is a clean separation from the UI design from
		  the "controller" in the C code.

	  In the GNOME world we write the app once, and we get it
	  running in 30-something languages at once (modulo translations
	  which is done by our contributors).

The hard problems will be to:

	* Figure out the event propagation model for widgets in
	  Windows.Forms and map that to the toolkit (which has its
	  own event propagation system).

	* Someone will have to architect the work in a per-toolkit
	  fashion.  I do not believe this is going to be very simple,
	  for one, the documentation is poor, and you will very likely
	  have to learn things by writing a lot of Windows.Forms code
	  and investigate what it does.

	* The Petzold book might be of help, but it is as usual on the
	  verbose/teaching side, so it takes quite a long time to read. 

	* Wrapping the various widgets should be no problem, as I said
	  the hard problem will be to convert the windowing system
 	  events back and forth to what the derived classes expect.

	* In some cases, if people expect to overwrite the widget
	  behavior you will have to either re-implement the widget
	  "natively" to Windows.Forms, or you will have to do
	  the above mentioned event translation: from your toolkit to
	  Windows.Forms and back.

If people want to move on, go ahead, but I think it is going to be
hard.  Sample applications will probably require little work, but as
soon as you move into the hard problems, you might find yourself
replacing a lot of the code (the sample Windows.Forms code that we have
in CVS can handle "simple" applications, but not complex ones).

From the Ximian perspective, Gtk# fits our needs, and is what we want to
do.  For cross platform development some people are looking at doing
native ports of Gtk to MacOS X and Win32 (currently on Windows, we still
draw our own controls, so it looks "foreign").

By doing native ports, we could use the same API on all those systems. 
Also, Gtk is mature enough, we know this because we have built an entire
desktop (and all sorts of very window system-specific hacks), and we
have built a bunch of productivity applications with it. 

Someone mentioned VCL.  The only problem with the VCL is that it can
only be used for GPL applications (or I guess you could license it from
Borland for your app), and would have to be ported from Delphi to C# (or
someone would have to write a CIL compiler for it).

Miguel.

[1] I believe it is more important for Gnome to get a nice OO language
than it is for KDE (since they already have C++).  This is my one
pathetic attempt to get Adam to help us with Gtk# ;-)