[Mono-winforms-list] System.Windows.Forms Status Update

[Peter Dennis Bartok]

The strategy in picking controls to be implemented was simple:

1) Pick a few simple ones that allow us to drive driver and theme API
development without getting bogged down trying to implement the actual
control.
2) Pick a few simple ones that allows those members on the team who have not
been involved with control development before to get used to it and play
with the techniques (like double-buffering) before working on the large
controls where, again, you could get bogged down in implementation problems
vs. figuring out the basics.

I agree with your assessment on the importance of TextBox, and we are now
working on TextBox, Menu and some of the other 'big' controls, but for the
reasons described above we had to do some others first. To use any
preexisting programs, chances were that all controls needed to be more or
less implemented so we chose to ignore that goal. The goal is to have a
solid implementation, I'm deliberately avoiding the "lets get some apps
going" approach, because it tends to lead to shortcuts and half-implemented
classes. (Thus the stipulation in the Readme to not just submit stubs)

Cheers,
  Peter

-----Original Message-----
From: "Dan Maltes" <dan@astusa.com>
To: "'Peter Dennis Bartok'" <peter@novonyx.com>;
<mono-winforms-list@ximian.com>
Date: 10 September, 2004 15:52
Subject: RE: [Mono-winforms-list] System.Windows.Forms Status Update


>Peter,
> Next to perhaps the Label and Button controls, I would say the
>TextBox may be the next most used control, especially in business apps.
Any
>reason why less significant controls like Groupbox or Tooltip are being
>worked on ahead of the TextBox control?  I know it will all get done
>eventually, but just seems odd that the TextBox wasn't at the top of the
>list.  Was there a strategy or priority decided upon?  Certainly many more
>prexisting sample programs out there could be used sooner if TextBox was in
>there.  Just a thought, feel free to ignore me since I'm just a lowly
lurker
>with little or no time to help out.
> Anyway, great job, the new managed SWF implemenation will bring me
>back to Mono I'm sure.
>
>-Dan Maltes
>
>-----Original Message-----
>From: mono-winforms-list-admin@lists.ximian.com
>[mailto:mono-winforms-list-admin@lists.ximian.com] On Behalf Of Peter
Dennis
>Bartok
>Sent: Thursday, September 09, 2004 5:24 PM
>To: mono-winforms-list@ximian.com
>Subject: [Mono-winforms-list] System.Windows.Forms Status Update
>
>[This is a resend - I apologize if you're getting it twice]
>
>Hi All!
>
>As some of you may know, we've had a SWF hack-a-thon in Provo last month. I
>figured I'd give everyone a quick update about the current state of things.
>
>For those who might have missed Miguel's message two months ago here a
quick
>intro: After having various problems with the approach of using Wine, like
>threading support, installation issues, debuggability, interop with
>System.Drawing, etc. we decided to start over and develop SWF from scratch
>(again). Except that this time everything is fully implemented in managed
>code. All controls are natively written in C#, using only System.Drawing
and
>a small 'driver' that provides the interface to the underlying Windowing
>system.
>
>At this point, we have the following controls fully implemented in managed
>code:
>- Label / LinkLabel
>- Statusbar
>- Toolbar
>- Scrollbar (Horizontal/Vertical)
>- Trackbar
>- Button
>- RadioButton
>- CheckBox
>- Picturebox (even supports animated pictures)
>- ProgressBar
>
>These controls should all be fully usable and provide/implement all methods
>and properties documented by Microsoft for System.Windows.Forms.
>
>Currently, the following controls being worked on:
>- Edit
>- Menu
>- Groupbox
>- Tooltip
>- TabControl
>
>Additionally, the Form and Control class are still a work in progress, not
>yet complete. Control is tied very much into the underlying driver
>architecture. Currently we have a driver for Win32, and a driver for X11.
>The X11 driver has only been used/tested on Linux, due to lack of time and
>resources we haven't done anything on Solaris or Mac yet, maybe someone who
>reads this will feel compelled to volunteer :-)
>
>Some of the bigger issues we were facing with Wine, like multithreading,
are
>already solved in the new implementation. The developers.exe sample app
that
>shows off multithreading, timers and various controls already works nicely
>with the new code.
>
>We've had volunteers, asking which areas need work, so here a list of
>controls and classes/components that need tender loving care:
>- ListControl
>   ComboBox
>   ListBox
>     CheckedListBox
>- MonthCalendar
>- Splitter
>- TreeView
>- DomainUpDown
>- NumericUpDown
>- DateTimePicker
>- Common Dialogs (probably only doable once all controls are done, unless
>someone implements them on top of Microsoft's Win32 SWF)
>- PrintPreviewControl
>
>- Macintosh driver
>- 64bit testing and/or support for Solaris
>- Testing and support for other platforms
>
>The list is probably incomplete, and some things are very large tasks, like
>the ListControl, which consist of several classes that can probably be
>implemented somewhat independently of each other.
>
>Also, if you would like to contribute but are unsure whether you have the
>time or experience to contribute a whole control, we also need test
>applications. Simple ones that just test every aspect of a single control
as
>well as more complex apps that have a purpose like a calculator. Anything
>that helps sniff out bugs in the code or shows people how to use SWF for
>their own needs is needed and welcome. And of course, we also still need
>lots of documentation.
>
>The current implementation can be found in mcs/class/Managed.Windows.Forms,
>and the core developers usually hang around #mono-winforms on gimpnet.
>
>Cheers,
>  Peter
>
>_______________________________________________
>Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>
>
>
>