[Mono-list] Toolkit for System.WinForms, and how to deal with Mono-specific issues

Sebastien Lambla sebastien.lambla@6sens.com
Wed, 11 Jul 2001 18:23:04 +0200


<< I know we're a long way away from being able to actually write our
WinForms layer, I was wondering whether or not when desigining this (and
possibly other toolkit or OS-dependent parts of Mono) we would want to
allow multiple toolkits and implementations. In other words, should we
plan for multiple WinForms implementations so that other popular
toolkits or desktops can still use the base Mono code yet have GUI
applications mesh with their desktop? This would also allow Mono to run
GUI programs on other operating systems, such as QNX or BeOS (of which
I'm a closet advocate of). >>

I thought a lot about this. My main question is, do we hook to current GUIs
which may be a compatibility problem at some point, or do we handle all the
drawing of the different widgets so as to mimic the windows GUI with the
Drawing namespace, which would be 100% compatible but slooooooooow (remember
how java redraw was soooo slow?). In my opinion we should permit hooking
when feasible, and have a bunch of "pure C#" libraries for missing OS
support.

<< This brings up another issue - how are we going to deal with presenting
needed Mono-specific functions without polluting the System.* namespace
with entities that really don't belong there? For instance, where would
a function to select the toolkit for WinForms parts go? In
System.WinForms.SelectToolkit()? in Mono.WinForms.SelectToolkit()? What
do you think?>>

Each .net application can have a manifest, which is an XML file, describing
what it can/may do. How about specifying which toolkit you want for a
specific platform in this XML file? As long as winforms is compatible across
platforms, the toolkit selection should not be a problem. You could then
have an add on to the os to select the environment, which toolkit and such.
Mono specific functions should go in a Ximian.Mono namespace and must not be
implemented in the System tree if we are to enable back and forth
portability of applications.

<< Lastly, is anybody else interested in working on JScript support? >>

Very, but my lack of knowledge on generating parse trees and such prevent me
from helping you...

Sebastien Lambla