[Mono-winforms-list] Windows Forms.

[Rick Fleming]

My question is what is the point of Mono or
MS.NET if it cannot be portable.  I thought
that was the whole point anyway?  So if you
have to use 'windows emulation' to use it
correctly, why have it at all?  Why not just
program WinAPI and use winelib on linux?

My vote is for platform independence, let
people make a GTK#/QT#/etc SWF...  I
wouldn't want to have to distribute a fake
Windows in order to have cross-platform
compatibility.  It's not compatibility, it's
a way to fake compatibility though
emulation.

Personally, I'll probably use GTK# in my
apps, even on windows...

----- Original Message -----
From: "Geoff Taylor" <geoff@opinionatedgeek.com>
To: <mono-winforms-list@ximian.com>
Sent: Tuesday, January 28, 2003 7:58 AM
Subject: Re: [Mono-winforms-list] Windows Forms.


| Greg Brown wrote:
| >
| > Just my 2 cents, but I would much prefer a Winforms platform
| > implemented using native widgets that gets me, say, 95% compatibility
| > with .NET than one implemented on top of an emulation layer that
| > *may* get me 100% compatibility. Mono is going to have enough trouble
| > playing catch-up with .NET as it is. Adding WINE into the mix is just
| > asking for more headaches in the long run.
|
| What's the point of .NET on Linux if it won't run .NET apps?  Surely 100%
is
| the goal - if Mono can't take advantage of all the programs that are being
| or will be written for .NET, why would anyone install Mono?  There'll
always
| be faster native code compilers, better windowing toolkits for specific
| tasks, better languages for specific domains, and so on.  I thought Mono
was
| there to bring about a common platform independent of the OS and
programming
| language.
|
| > It is possible, and likely, that a large number of applications
| > written for Winforms will not require calls into Windows-specific
| > APIs.
|
| I'm not at all convinced of this.  It's true that application developers
| often don't need to go to that level, but control developers often _do_
need
| to.  (At least in my experience of .NET applications and controls.)  So
| having an emulation layer which doesn't have this level of detail means
that
| Mono will be limited to running applications that don't use controls
| developed for .NET on Windows, the very opposite of the componentisation
| approach .NET is encouraging.
|
| > Also, it is not
| > unusual for application developers to write some amount of custom
| > code for each different platform on which a given product is
| > supported.
|
| Isn't this what .NET is trying to get away from?  Again, surely one of
| Mono's goals is to take advantage of the .NET applications out there
written
| for Windows, by making them available on Linux and other Unix systems.  It
| can't do that if it requires each Windows developer (some of whom can't
even
| spell 'Linux' let alone use it) to change their code.
|
| > In these cases, it is arguably more desirable for the
| > application to maintain consistency with the native windowing system
| > than compatibility with low-level Windows-specific services that are
| > not even being used.
|
|
| Personally, I don't think so.  I think it is more important that
| applications run consistently whether they are using Mono or MS' .NET
| implementation.  It shouldn't matter to users how this is done, what
| dependencies Mono has, what the native toolkit is, all that should matter
is
| that there's a .NET executable and it runs on Mono.  If the EXE needs to
| make a call to the base class library, surely it should work on Mono just
| the way it would on Windows.  No?  If not, how can Mono hope to be
anything
| other than a nice Linux/Unix programming system?
|
|             Geoff
|
| --
| http://www.opinionatedgeek.com/ :: Part of the solution.
|
|
| _______________________________________________
| Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
| http://lists.ximian.com/mailman/listinfo/mono-winforms-list
|