[Mono-devel-list] develop under Microsoft .NET and porting to Mono is correct?

[Jonathan Pryor]

On Mon, 2005-02-28 at 09:57 +0100, Mauro Bertoli wrote:
> Hi, thank for answers. I don't understand why I should
> use GTK# or similares... the windows forms Mono layer
> is not native? it require some extra-libraries /
> layers? It think not, I'm wrong? I will integrate
> Forms on Linux after... I will it another 4/6 months
> or year! What do you think?
> Mauro

Have you ever used a Java Swing app on Windows?  Or Tcl/Tk?  Or even
Microsoft Office? :-)

The reason I ask is that all of those apps have a visually distinctive
look and behavior that is different, if only slightly, from the standard
Windows controls.

For example, my Java Swing apps don't properly redraw while resizing the
window; you have to finish resizing to get a redraw.  This is completely
different from *real* Windows apps.

Tcl/Tk is just ugly (but that's true for every platform it runs on).

And Microsoft Office...  Well, it's Microsoft Office, and it *always*
looks different.  Cool, yes, but different.

The key point is that many users don't like applications that look
different.  It keeps the desktop from looking cohesive and consistent,
and requires that the user adapt to the program (instead of having the
program adapt to the user).

So, why should you use Gtk#?  Because System.Windows.Forms will look
like ass on Gnome/KDE (at least until Managed.Windows.Forms gets theming
support to integrate visually).  More specifically, it will look like
Windows, which might as well be ass on Gnome/KDE. :-)

Why shouldn't you use Gtk#?  Because it won't look right on Windows
unless you use the GTK-Wimp theme (which is included with Gtk# IIRC).
Gtk# also requires an X-server on Mac OS X, which is problematic for
some people.

Which brings us to the conflict between what's ideal for users and
what's ideal for developers.  For users, having a UI custom-designed for
their OS is ideal.  This means using Gtk# on Gnome, Cocoa# on Mac OS X,
and System.Windows.Forms on Windows.  Developers don't want to re-write
their UI code N times, so they want a portable toolkit.

The problem is that portable toolkits rarely behave properly on all
target platforms.  Qt has issues on Mac OS X; I've heard from a number
of friends that it never looks quite right, button sizes are wrong, etc.
It *looks* like a Mac, but it doesn't look *exactly* like a Mac, nor
behave like a Mac.  GTK+ will likely have the same problems, if it's
ever ported to use Carbon.  (System.Windows.Forms is broken by-design,
as it was never intended to be a portable toolkit anyway.)

What's my point in all this?  I'm not sure I have one.  It's more to
enlighten you to the potential problems you may see, and that there are
reasons that developers won't be use System.Windows.Forms even after
it's complete.

 - Jon