[Mono-list] Windows.Forms, KDE

[Miguel de Icaza]

Hello,

> Couldn't we just use conditional compilation in the wrapper-dependent
> parts? A lot of #ifs (and a few #defines) might uglify the code a bit,
> but IMO it would simplify things greatly. The wrapper-dependent parts
> could be quickly and easily identified just by skimming the code for
> #if-#endif blocks and we wouldn't have to maintain multiple copies of
> mostly redundant code. Each file could have a maintainer for the general
> code and maintainers for each wrapper, and so long as they stay in their
> own areas we won't have to worry about things like a change in QT#
> breaking GTK# support.

There are two problems with the approach above:

	* Using defines to maintain two very different code bases is
	  a pain.  Everyone who has done it, has suffered.  What you 
	  want is something like the setup that the kernel has,
	  common code is shared, and code which is toolkit specific
	  is placed in separate files.

	  Then depending on your target, you compile or link with the
	  proper set of files.  That is a lot cleaner.

	* Windows.Forms in general.

	  Although I was very excited about Windows.Forms initially,
	  Windows.Forms is a poor API, with a poor event system, with
	  a poor layout engine.

	  Some sources tell me that Microsoft is working on a
	  replacement for Windows.Forms, as Windows.Forms was not up
	  to the standards of quality of the rest of the .NET framework.

	  Which I believe after looking at the event model, and the rest
	  of Windows.Forms.

There are some pieces which are nice in Windows.Forms (Drawing2D) which
we can use libart and Xrender to implement, but the other things are
going to require a lot of work.  

Unlike the other classes that we have implemented, Windows.Forms is not
easy to isolate, and focus on a single component, and replace it as we
go.  The problem is that the toolkit has deep interdependencies, and
must be architected by someone with a lot of time to get the event
handling right.  

Look at the Genghis code base for a set of controls that people are
building with Windows.Forms: to have a complete implementation, we would
have to emulate every bit to allow Genghis to run.

I am personally no longer sure that a complete Windows.Forms emulation
is possible without resorting to things like using Wine (consider the
wndproc method, which is used to catch windows events, and implement
some of the corner cases, a common complain from people trying to
implement "Smart Clients").

Both Gtk and Qt are portable to multiple windowing systems, and I would
like to encourage people to look into doing "native" versions of Gtk for
MacOS X and Windows (without using the "rendering" code in GtkStyle, but
the code from the system platform).

That being said, looking at the future, it seems like a good toolkit
should incorporate ideas from OpenStep/NextStep/Aqua, and Swing.

Swing is extremely well designed, and is pretty much a programmers dream
come true, but has performance issues and is buggy (just using libart to
implement their Drawing2d apis would fix a lot of the problems in
there).

So, I am thorn between wrapping Windows.Forms and doing the right
thing.  Sure, Windows.Forms is wrapable, but might come at a very high
cost, a cost that we could probably spend innovating and creating a
better toolkit than Windows.Forms is.  There are several examples out
there, but it will require a long term commitment.  Look at Wine: it has
advanced a lot, but still has several bugs after all these years under
development. 

As far as I am concerned, in the close term, Ximian will focus on
supporting Gtk# because that is what we need to develop Gnome
applications, and will continue to evaluate our options to move forward.

> BTW, does mcs have conditional compilation yet? If not, are there any
> plans to add it?

yes, it does.

Miguel