[Mono-devel-list] Windows.Forms schemes.

Moore, Paul Paul.Moore06 at ca.com
Wed Aug 27 11:22:41 EDT 2003

Its not simply a case of 'eventually the best solution will win' (or solutions).

Some of us have to place bets now and changing horses late is a tough thing to do (look at #develop)

I REALLY like the idea of cross platform dev using CLR (fabulous job done by mono and dotgnu teams), but I cant convince myself to bet my farm on it until the GUI toolkit issue has a solution with an empty 'cons' column.

I don't care about p/invoke and windows procs, I am looking to create new apps. I just want a way to

A) write portable GUI code
B) painlessley if possible (ie a GUI designer)
C) that uses (not looks like) the native widgets

-----Original Message-----
From: Miguel de Icaza [mailto:miguel at ximian.com] 
Sent: Wednesday, August 27, 2003 6:39 AM
To: Thong (Tum) Nguyen
Cc: 'Neil Cawse'; mono-devel-list at lists.ximian.com
Subject: [Mono-devel-list] Windows.Forms schemes.


> Itÿs worth nothing there are many .NET controls are written in 100%
> managed code.  Iÿm pretty sure the major toolkits (Infragistics,
> Syncfusion, etc) are 100% managed.

Am sure they are all written in C#, nobody said they were not.

They just happen to P/Invoke a lot, and hook up to WndProc, and do
extensive processing in WndProc.

> People using P/Invoke have already given up their ´cross platform¡
> compatibility and those applications will become 100% managed over
> time.  Catering for them isnÿt (IMO) important when you consider the
> ´ugliness¡ of having to integrate with wine.

That is fine.  We have now three efforts aiming at different scenarios:

	* Full compat.
	* Mid-compat using Gtk.
	* Mid-compat without toolkit.

Thats why I like research: we get to try all the options.  Some
assumptions we make will turn out to be wrong, some will turn out to be
right.  Its hard to predict.

We have a diverging opinion about what real applications will look like,
and thats why we are using different models.  In the end, since its all
C# anyways, end users get to choose the implementation that suits their

Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com

More information about the Mono-devel-list mailing list