[Mono-winforms-list] Forms Architecture

[Peter Dennis Bartok]

Nikolaus,

The Winforms FAQ ( http://www.mono-project.com/FAQ:_Winforms ) has a section 
on philosophy. I am surprised that you didn't read the paragraphs right 
above what you quoted. It answers why we're doing it the way we are.

I don't have the time for a philosophical discussion right now, since we're 
nearing the Winforms Beta, but I do ask that you try it out before you say 
it's no good. I've seen Swing apps and yes, they sucked. However, purely 
going on my personal impressions, our (unoptimized) UI speed when using SWF 
apps is much better than that of any Swing app I've ever seen.

Also, our approach does allow native drawing of widgets, there is a theme 
interface that does allow that, and I Alexander Olk has made a driver for 
native Gtk drawing on Linux, for example.

The fun thing is, Sun could pretty much define their own toolkit API and it 
still sucked. We have a given API we need to implement. We don't have the 
luxury of defining what a control should do or not do, MS defined that, and 
they defined it very close to Win32.
To then say 'lets use native', unless that native is Win32 is fatal, since 
the other 'native' toolkits just don't implement the same features. And it 
does nobody any good if the app expects a feature that the native toolkit 
doesn't deliver.

As I said, give it a try before you say it's no good.

Cheers,
  Peter

-----Original Message-----
From: "Nikolaus Heger" <nheger at gmail.com>
To: <mono-winforms-list at lists.ximian.com>
Date: 14 March, 2006 18:22
Subject: [Mono-winforms-list] Forms Architecture


>Hi Developers,
>
>I would like to know what the current direction of the Forms
>implementation is and why the decision was made to go the way that
>it's going now. I am a full time Java Swing developer and looking to
>see if Mono/Windows.Forms could become a credible alternative. I
>would be thrilled if it did.
>
> From the Forms home page: "The current approach is to implement all
>controls fully in managed code, it uses an abstract theme interface
>to paint the widgets. The default theme interfaces renders the
>widgets using System.Drawing".
>
>This sounds exactly like Swing to me. There are two crucial problems
>with this approach:
>
>1 - It's slow or there is an enormous effort required to make it
>fast. Hand-drawing widgets is not as fast as letting the OS do it,
>Swing has struggled with that for years. As of today, Swing is pretty
>good on Windows, but still dead slow on other platforms. That's due
>to years and years of effort by Sun to make Swing fast on Windows
>which resulted in making most of it HW accelerated - on Windows.
>Even using system libraries which of course run on the graphics card
>- this is a slow approach, and making it fast requires insane effort.
>
>2 - It doesn't look native. No matter how good your themes are, you
>are forced to play catch-up with the latest OS release. The apps
>always look a little bit off. It's impossible to make an application
>that will look "right" on different versions of an OS, like look
>right on Windows XP _and_ Windows 2000. In Swing, I have to choose
>the XP or the 2000 look, and my app will be stuck with it and look
>out of place on the other platform.
>
>This is even worse with older apps - the look does not automatically
>update with the OS like native apps do. I have some software written
>in JDK 1.3 and because of subtle incompatibilities between 1.3, 1.4
>and 1.5 I had to ship the app with the JVM. Realistically, this is
>the _only_ way to ship reliable Java apps. The idea was of course
>that the users always have the latest and greatest JVM is installed
>on the system and apps run on it happily, but that is not a realistic
>approach (think QA time and maintenance effort here). So my app ships
>with 1.3 and will look like Windows 2000 on Win XP. Lame.
>
>There is also a solution to these problems: Use native widgets. AWT
>was a bust, but SWT works quite well and I use it everyday with
>Eclipse. Despite all the obstacles that have to be overcome using
>such an approach, I think it's the best way to do a cross platform
>GUI. If the OS handles the drawing of widgets, it gets you speed and
>perfect looks for free. Clearly, there are drawbacks, and clearly,
>the Forms team has decided that the drawbacks are severe...
>
>I realize that I was not there for the initial discussion of this, so
>if anyone wants to either point me to an archive of discussions or
>explain why the current Swing-like approach was chosen as the way to
>go forward, please respond.
>
>Best regards,
>
> Nikolaus Heger
>_______________________________________________
>Mono-winforms-list maillist  -  Mono-winforms-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>
>