Windows Forms.

Hey guys,

    So we have a problem with Windows.Forms right now.  To test/develop
on Linux we need to get Wine to include support for a few semaphore API
calls.   

    As said before, Winforms implemented with Wine is required to have
full support for Wndprocs and P/Invokes, and is the right way of doing
things.

    The other option that we have scratched is to build Windows.Forms
using a native toolkit, because we would not be able to achieve 100%
compatibility.   

    Idea: it would be useful to have a Windows.Forms implementation that
used Gtk# at least to port existing Open Source Winforms code that we
could tweak or ifdef chunks of code.

    Opinions?

Miguel

    
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: Windows Forms.

Winelib update.

Hello everyone,

   I just wanted to get everyone on the same page about the issues that
we face right now with the Wine-based implementation of Windows.Forms.

   In the past we *thought* that the problem was Wine interacting badly
with the GC.  This is not the case.  We tracked this down to a different
problem.  It turns out that Wine has its own pthreads implementation
that provides them with some control that is required by the Win32 api.

   So linking an application with both -lpthread and -lwine is a recipe
for disaster.  That is where the GC problems happened.  By turning off
the GC, we were able to "mask" the problem, but the problem was still
there.

   Now, if you remove the -lpthread a few symbols remain unresolved: a
few of the semaphore api calls.  The way of solving this is to either
copy/paste the semaphore api calls into the Wine runtime (someone should
send a patch to these guys), or we could put those missing api calls in
our stub program as a quick workaround.

    I discussed this with Dennis on email, but I should have posted to
the public to let everyone know. 

Miguel.
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: Windows Forms.

Hello,

My opinion:

Wine:   Full support - Not native
Gtk#:  Near full support - Native

Both sound good. My opinión is that the Windows.Forms
could be plugable so that a user could choose witch one to use.
Even a user could use one Windows.Forms with one application and
another one with another one. If the qt# people wants to develop
it or the wxWindows too, let's allow them to plug it into mono.
(I know that Ximian can only put their effort in one place, but
leave the things open, can be good)

Another thing:
Not every application is using the Wndprocs and P/Invokes, so if the
owner of the application cares a bit about the portability of the
application, the NET Framework (and therefore Mono too) is rich enough
to do most things without touching the Windows API.
What I mean is that I'd like a Gtk# or Qt# based Windows.Forms
for my own application (when I know how I program things), but
I'd like (for example) a Wine implementation to run a comercial
program.

It's no so hard to program without using WndProc and the API
(I'm developing visual program in C# and I think I have 5 classes that
must use the API, in a project with several hundred classes. That's the
only thing that should be ported), but I can understand that a 100%
compatibility sounds good.

I don't know the Gtk# too much, but the worst problem I see is
the System.Drawing with Wine and Gtk# because it is really
equal to the new GDI+ of windows and I think it is not implemented
in Wine and it could be hard to implement in Gtk#.
(please, correct me if I am wrong)

Thank you very much for the great work all of you have done so far
Asier Llano

Miguel de Icaza wrote:

>Hey guys,
>
>    So we have a problem with Windows.Forms right now.  To test/develop
>on Linux we need to get Wine to include support for a few semaphore API
>calls.   
>
>    As said before, Winforms implemented with Wine is required to have
>full support for Wndprocs and P/Invokes, and is the right way of doing
>things.
>
>    The other option that we have scratched is to build Windows.Forms
>using a native toolkit, because we would not be able to achieve 100%
>compatibility.   
>
>    Idea: it would be useful to have a Windows.Forms implementation that
>used Gtk# at least to port existing Open Source Winforms code that we
>could tweak or ifdef chunks of code.
>
>    Opinions?
>
>Miguel
>
>    
>_______________________________________________
>Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>
>  
>

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: Windows Forms.

I'm for a gtk# one. It wouldnt work with all apps, but hopefully a good
chunk of them. And as more and more apps go .NET only, there will be less
of a need for P/Invoke.

On 26 Jan 2003, Miguel de Icaza wrote:

> Hey guys,
>
>     So we have a problem with Windows.Forms right now.  To test/develop
> on Linux we need to get Wine to include support for a few semaphore API
> calls.
>
>     As said before, Winforms implemented with Wine is required to have
> full support for Wndprocs and P/Invokes, and is the right way of doing
> things.
>
>     The other option that we have scratched is to build Windows.Forms
> using a native toolkit, because we would not be able to achieve 100%
> compatibility.
>
>     Idea: it would be useful to have a Windows.Forms implementation that
> used Gtk# at least to port existing Open Source Winforms code that we
> could tweak or ifdef chunks of code.
>
>     Opinions?
>
> Miguel
>
>
> _______________________________________________
> Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: Windows Forms.

Hello,

> I'm for a gtk# one. It wouldnt work with all apps, but hopefully a good
> chunk of them. And as more and more apps go .NET only, there will be less
> of a need for P/Invoke.

Again, the problem is not P/Invoke alone, but Wndproc method in controls
as well.

The P/Invoke issue is a bad one, because it is required for things where
there is no managed API (most third-party controls for .NET will use
P/Invoke).  So the Gtk#-based solution is a very partial one.

I can not stress this enough: A Gtk#-based implementation would *not* be
fully compatible, and people should be very very very aware that this
implementation *would require changes to their code* and would *not be a
full implementation*.

Miguel
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

RE: Windows Forms.

I don't have a great understanding of the structure of WineLib or the
ramifications of using it, but I think that is the way to go.  One of
the most important features of .Net in all of its flavors is binary
portability.  

While projects such as GTK# are important, I think the goal should be as
near 100% compatibility Windows/.NET as possible.  It appears as though
the major problems in using WineLib are (1) the aforementioned threads
problem, and (2) possible widget/theme issues.  I really can't say how
difficult either of these problems are but given the quality of
developers at work here, I can't believe they are insurmountable.  Once
these problems are addressed, many more .Net apps will run "out of the
box" on Mono, which is certainly what I am looking forward to.

Reggie

> -----Original Message-----
> From: mono-winforms-list-admin <at> lists.ximian.com [mailto:mono-winforms-
> list-admin <at> lists.ximian.com] On Behalf Of Miguel de Icaza
> Sent: Sunday, January 26, 2003 2:52 PM
> To: Bob Smith
> Cc: mono-winforms-list <at> ximian.com
> Subject: Re: [Mono-winforms-list] Windows Forms.
> 
> Hello,
> 
> > I'm for a gtk# one. It wouldnt work with all apps, but hopefully a
good
> > chunk of them. And as more and more apps go .NET only, there will be
> less
> > of a need for P/Invoke.
> 
> Again, the problem is not P/Invoke alone, but Wndproc method in
controls
> as well.
> 
> The P/Invoke issue is a bad one, because it is required for things
where
> there is no managed API (most third-party controls for .NET will use
> P/Invoke).  So the Gtk#-based solution is a very partial one.
> 
> I can not stress this enough: A Gtk#-based implementation would *not*
be
> fully compatible, and people should be very very very aware that this
> implementation *would require changes to their code* and would *not be
a
> full implementation*.
> 
> Miguel
> _______________________________________________
> Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-winforms-list

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: Windows Forms.

Hi Miguel et al,

Maybe I do not understand all the issues, but I fail to see how a Gtk#
System.Windows.Forms implementation gets you any closer to "the right
way of doing things".

I would not waste effort on any incomplete System.Windows.Forms
implementations, and would rather see all effort spent on getting
Winelib "fixed".  It means SWF on Linux is delayed just a bit more, but
it will really be worth the effort.

Just my 2 cents.

--

-- 
PJ Cabrera
pjcabrera at pobox dot com

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

RE: Windows Forms.

<!--
I just have to throw in a few comments on this subject, perhaps we are defining the problem the wrong way. 
Obviously one of the most greatest goals of .NET and C# are crossplatform compatibility.
 
It seems to me that our problem is not implementing System.Windows.Forms.  Our problem is rooted in the fact
that Microsoft has defined a library that is not able to be platform independent, and thats just for things
like the WndProc problem.
 
As for the P/Invoke problem, I do not think that it is unreasonable to expect that anyone using P/Invoke
rewrite their code.  One thing that may be a positive solution to the problem is to provide a repository for
people that want to use P/Invoke code with Mono, whether it be WinForms or Console apps.  I would envision
that this repository would mainly help developers that are not familiar with Linux (or whatever platform
they are looking at) development, that would give them cross references to common things that P/Invoke is
used for in MSWindows.
 
Obviously platform independence is a wonderful and noble goal, but the only way for windows to be platform
independent is to have a platform independent WinForms library, which we don't have.  As for P/Invoke,
that will never be platform independent, hence Platform/Invoke.
 
I realize that it would be our ultimate goal to have applications copy and run on Mono-Linux/OSX/etal.  We
also however have to realize that the main reason people would use any other OS over MSWindows is a quicker
ROI.  Yes having software effortlessly port from one to the other really helps the ROI, but The extra
machine power, increased complications, and slower speed caused by Wine would perhaps offset that 100%.
 
In summation, ever since I started helping with WinForms I have been disgusted at the obvious bloated mess
that Wine will add to WinForm apps and I think it is rediculous to require its use just to show windows in X.  I
propose that applications that require the services of windows run under Wine, but any that do not will be
able to run as lean and mean as possible.  Lets make Wine the exception and not the rule.
-->
 
Josh

	-----Original Message----- 
	From: Miguel de Icaza [mailto:miguel <at> ximian.com] 
	Sent: Sun 1/26/2003 1:51 PM 
	To: Bob Smith 
	Cc: mono-winforms-list <at> ximian.com 
	Subject: Re: [Mono-winforms-list] Windows Forms.
	
	

	Hello,
	
	> I'm for a gtk# one. It wouldnt work with all apps, but hopefully a good
	> chunk of them. And as more and more apps go .NET only, there will be less
	> of a need for P/Invoke.
	
	Again, the problem is not P/Invoke alone, but Wndproc method in controls
	as well.
	
	The P/Invoke issue is a bad one, because it is required for things where
	there is no managed API (most third-party controls for .NET will use
	P/Invoke).  So the Gtk#-based solution is a very partial one.
	
	I can not stress this enough: A Gtk#-based implementation would *not* be
	fully compatible, and people should be very very very aware that this
	implementation *would require changes to their code* and would *not be a
	full implementation*.
	
	Miguel
	_______________________________________________
	Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
	http://lists.ximian.com/mailman/listinfo/mono-winforms-list

	

RE: Windows Forms.

Im a Windows c# app developer.

There are going to be a very! large number of developers using windows
forms to build applications (the ms factor)! If we could make it real
easy for them to move their applications across to Linux, many of them
would and that would build the strength of Mono, Linux & Open Source.

The very spirit of .net is to try to use just the standardized,
comprehensive .net framework without having to pinvoke to the platform
to get things done. For that reason we would want the thread class in
the mono framework should work exactly like the ms thread class for
example. 

As a windows programmer, if I knew that as long as I used vanilla
windows forms (didn't start intercepting windows messages or using
reflection to get at underlying windows handles) that Id be able to run
on Linux, you bet a would! If I knew I could achieve cross platform
support by following certain rules, I would..

I like small and efficient - for me a lean System.Windows.Forms using
gtk that includes all the standard windows controls would be what I
wanted. If I needed to draw my own, Id use System.Drawing - thus
sticking to the framework. I don't want to know that im running on
windows.

If we are going to build SWF, lets do it right.

My vote - no Wine. But more importantly, either way, lets get something
going, so people can see results, the more people see, even small
progress, the more that will jump in and help!
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list