[Mono-list] Windows forms

[Dominic Pease]

Has anyone considered getting in contact with the ECMA and attempting to
get the ball rolling on a standard windowing specification? Certainly,
MS is heavily involved in TC39-TG3 (as they ought to be), so they might
not be receptive to such proposals; but, after all, the website states
that the group's second priority (after the core specifications were
completed) is: 

'2. Upon completion of item 1, to investigate the future direction of
CLI standards, and to evaluate and consider proposals for complementary
or additional technology [1]'

Might be worth a shot. If it accelerates the process (which I feel is
inevitable), it could be good for everyone.

-----Original Message-----
From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com] On
Behalf Of Mike Kruger
Sent: Tuesday, July 09, 2002 1:33 AM
To: mono-list@ximian.com
Subject: Re: [Mono-list] Windows forms

Hi

>    I am glad that you joined the discussion, because you have a lot of
> experience with Windows.Forms.
>
> > It's a lot of work, but Windows.Forms suck and when GTK# is good it
may
be
> > worth the effort.
>
>    There are two things I would like to explore from you:
>
> * What pieces of Windows.Forms are good.
>
> * What parts of Windows.Forms you think are bad.
>

Unfortunately there aren't many good pieces. Windows.Forms is a bit like
Java.AWT with some
more classes. All is good if you're programming 'low level' but if you
want
to implement a forms
designer or docking you simply can't in pure Windows.Forms (.NET has a
forms
designer build in,
but I mean programming a forms designer on your own) because you can't
go
'deep enough'. With
Java Swing you've more power (you could overwrite what you want). A
control
wrapper is something
other than a C# implementation, but Windows.Forms suffers from not
including
good user ideas. I assume
that the GTK# coders accept ideas/changes when they're good and improve
the
handling.

Ok now to some points which come into my mind :

- Bad idea : ImageLists. They may be more performant or may save memory
or
something else, but giving
a reference to a Bitmap is more flexible in my opinion. This old windows
technlogy shouldn't live on.

- Bad idea : The most classes are only 'toys'. Like the RichTextBox, you
can't even scroll the scrollbars on your own.

- Bad idea : Too many enums instead of a more flexible approach like the
strategy pattern. Java Swing is here much better. Sometimes it were much
nicer if they've taken a more
flexible approach. Example : The MessageBox.Show, you can have buttons :
yes/no/cancel, OK, yes/no etc. but not
your custom buttons. I think that is bad. It would be more nice to have
an
option which allows customize the
buttons. But other classes have the same problem the messagebox was only
one
example out of many.

- Bad idea : Not mighty enough. You simply can't do anything in .NET
what
you could do with MFC.
I agree that this point is difficult when you write a wrapper but free
software is flexible enough to change
the faults. Per example : You can't set the context menu of a form
caption
bar. The MainMenu is not flexible
enough you can't change the drawing of the 'form' which shows the menu
items, only the menuitem drawing, you can only
put it on top with a property in the Form. I think that they don't
follow
their control model here. It is always bad, if you don't
follow your own model. (A MainWindow is a Control, therefore it should
be
one)

+ Good idea : Easy to use (but this is almost any OOP GUI Framework I
encountered). But they've a easy model with docking/anchors etc. Not
having
layout managers or something like this makes
it a lot easier to 'draw' a Form. (but it has well known downsides too
...)

+ Good idea : It's hard for me to say which ideas are good, because the
bad
ideas are more appearant.
I can't even list the controls which are good, because almost every
Windows.Forms control (even
the button) is rewritten by someone else who found that someone is
missing.

>     I want to know what is good, because perhaps we could implement
> those pieces at least, and people could use a combination of the good
> pieces, with pieces from a differen toolkit (simplifying for example
the
> effort to port SharpDevelop).

I don't know, if it is good to mix up APIs. I like consistent APIs :)

One of the callenging parts of the SharpDevelop port is the port of the
TextArea Control ... when that is
finished the rest is piece of cake ... it's a bit of work but it
shouldn't
be hard. SharpDevelop is highly modularized
I could port a thin subset first and then step by step. I have
abstracted
the GUI layer (because I've thought
that the day dumping Windows Forms would come ...) to make the port
easier.

Mike


_______________________________________________
Mono-list maillist  -  Mono-list@ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list