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 - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
