[Mono-winforms-list] Forms Architecture

[Nikolaus Heger]

On Mar 15, 2006, at 8:40, Peter Dennis Bartok wrote:

> 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 did read these paragraphs. They mention GTK and Wine. IMHO, both  
are not suited for a native implementation approach. I agree with all  
that was said about why not to use these frameworks and I could think  
of a few more.
GTK sucks as a cross platform framework to begin with, and basing the  
forms implementation on it could not possibly make it better.
As "better" my definition would be that the Forms application is  
indistinguishable from a native application on the respective platform.

I was thinking about SWT. SWT is a native GUI framework for Java.  
Eclipse is based on it, and Azureus, too.

> 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.

That sounds very promising, I will definitely check it out.

> The fun thing is, Sun could pretty much define their own toolkit  
> API and it
> still sucked.

Agreed. I could elaborate on why Swing is broken, but that's not the  
topic here. The important thing is to learn from its failures.

There are two basic mistakes in the Swing architecture. These  
mistakes are conceptual and can not be fixed. I was somewhat afraid  
that the Forms project is about to repeat these mistakes.

#1 - Emulating native looks with theme
#2 - Hand-drawing widgets

If I can define a Forms theme that just uses the OS for widget- 
drawing, that might be enough to get around both. But I am concerned  
because the whole "theme and hand drawing" philosophy wasn't  
dismissed outright.

> 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.

That's the problem with all cross platform GUIs. There certainly is  
validity to it, but the problem is limited in scale. SWT seems to  
deal with that just fine.

It seems to me that you want to achieve two things

1 - Provide Windows.Forms as a means to create a cross platform GUI.  
You can mark the windows-only functions of the API as "bad, do not  
use" and developers can develop wonderful cross platform GUIs with no  
problems by just avoiding these Win32-only things.

2 - Provide Forms as a way to quickly / easily port Windows native  
applications. This will be hard as MS will "allow" if not  
encourage .Net developers to dig deep into the Win32 API. The only  
solution to this is to provide workarounds for this on other  
platforms where possible, and skip the impossible-to-emulate things.  
Developers not wise enough to avoid those, or those who simply don't  
care just cannot be accommodated on other platforms.

I, for one, would be happy with just #1. There will always be people  
who program in a Windows-only way and MS will obviously not prevent  
them from doing that.

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

I didn't say it's no good. I can believe it's "fast enough" because  
on a modern machine almost anything is fast enough and there is  
differences in perception as to what constitutes fast enough. I have  
written Swing apps that are fast enough - at least on Windows. The  
bigger problem is that they stick out as non-native.

It is my experience that the Swing approach with themes is plainly  
wrong. The reason is that while themes are cute, no one really needs  
them. If you look at Swing themes, there are some nice ones from  
JGoodies - they are nice, but I would much rather have a 1:1 native  
look. The only reason I need the nice themes is that there isn't a  
1:1 native look that works everywhere.
And if you look at the most other themes (including and especially  
the ones from Sun) they are just horribly ugly.

Themes have little value other than to approximate the native look,  
and at that task, they are always worse than using native in the  
first place.

I have used Swing since it first came out, and written many client  
applications in it (yes, they can be fast) and never have I had the  
need to have themes. Every single app though had a problem with not  
looking exactly like a native app.

I didn't find an archive where these questions were discussed in the  
past. If there is such a thing, please let me know.

Best regards,

	Nik



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-winforms-list/attachments/20060315/db6eb7ba/attachment-0001.html