[Mono-winforms-list] Forms Architecture
nheger at gmail.com
Tue Mar 14 20:21:07 EST 2006
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.
More information about the Mono-winforms-list