Just to reinterate what I said in an eariler email, if the alterative to Windows.Forms is more complex than I don't think will get many people using it, other than of course the die-hard programmers. The reason why dev environments like VB and Delphi are so popular is beause it's straight forward to write complex applications quickly. If you make the GUI toolkit too complex to use, you'll lock out a lot of potential developers and the GUI side of mono will just become a niche player, very much like swing. Depends I guess one what the aim are for GUI kits under mono.
Herbert ----- Original Message ----- From: "code" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 20, 2002 7:19 AM Subject: RE: [Mono-list] Windows Forms...wah > > I agree with you. If there is a better GUI toolkit and it could run on > most platforms, most people will use it instead of WinForm. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of Tum > > Sent: Friday, September 20, 2002 9:58 PM > > To: [EMAIL PROTECTED] > > Subject: [Mono-list] Windows Forms...wah > > > > > > Hi everyone, > > > > Here are some of my thoughts on the state of GUIs and Windows Forms. > > > > + > > Windows Forms has very nice native controls. It is fast, > > responsive but VERY POORLY designed. It is only a thin layer > > about native windows controls. Using native controls is > > *ok*, but they could have at least used the > > model-view-controller design pattern. The first thing I did > > when I started using Windows Forms was to write > > model/controller classes for lists and trees. > > > > + > > Swing is wonderfully designed. It is the best and most pure > > OO UI class library out there. It used to have major speed > > problems, but that hasn't been too much of an issue lately. > > > > + > > I really think that instead of porting Windows.Forms (which > > would be VERY hard), we should be thinking more along the > > lines of creating something similar to Swing or SWT. A swing > > like implementation would be better as you would have more > > control over component drawing (and thus better support > > printing and UI capturing). A designer plugin for VS.NET can > > easily be written to support the new toolkit. I think the > > added bonus of being able to *reliably* port .NET GUI > > applications to .NET would encourage people to use the new > > toolkit over Windows.Forms. > > > > + > > If a swing-like toolkit was written, only a few native > > routines would be needed. Drawing/blting (System.Drawing?), > > window creation and message/event dispatching. This would be > > trivial to implement on Windows and Linux. Most of the UI > > could then be written in portable managed code :D. > > > > ::Tum > > > > > > > > _______________________________________________ > > Mono-list maillist - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/mono-list > > > > > _______________________________________________ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
