[Mono-winforms-list] Windows Forms.

[Michael L Torrie]

On Tue, 2003-01-28 at 06:58, Geoff Taylor wrote:
> 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.

Personally I see C# and mono as merely tools to allow easier development
of apps under linux.  Portability to windows is just a plus.  Basically
if SWF fails completely, mono will still be useful, especially in paving
the way to migrate from ASP.net under windows and IIS to Unix and
Apache.  So there is lots of point in .NEt under linux.  In fact, even
if and when Microsoft completely changes the specs to break
compatibility with Mono mono will still be a very useful thing.


If SWF is going to be attempted at all, though, a 100% compatibility
goal should be the target, so you are correct there.  I mean we already
have GTK# and QT# for those not interested in this type of
compatibility. 

I'm far more interested in mature gtk and gnome bindings than SWF right
now.  But on the other hand, bringing sharpdevelop and other apps over
is very cool.  Since I don't really know anything about the complexities
of SWF or porting it, I can't really argue one method over another.  I
do think the look and feel issue is important, but not an immediate
concern.

Michael


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