[Mono-list] Windows forms.
Miguel de Icaza
06 Jul 2002 13:53:59 -0400
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
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
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 .
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
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
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:
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).
 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# ;-)