[Mono-winforms-list] Re: patches for Win32 API libraries

Miguel de Icaza miguel@ximian.com
05 May 2003 21:53:17 -0400


    A few comments.  But first of all, congratulations on getting this
work going.  I was able to run a simple Windows.Forms application with
the stock Mono (regular GC, regular mono, no changes applied there,
after I applied the previous fix to the class libraries).

    The work is awesome.

    I ran the MenuTest.exe program from the mono distribution, as I
could not find a lot of other samples (do we have a set of samples
anywhere to use?).  That application does "funny" things with the menus,
so I am not sure if this is a problem of the WineLib work, or a problem
of the funkyness of this particular example.  For example, menus are
only drawn when the mouse "moves" over the region where the menu should
be, not automatically.  

    Now, to my analysis of the current wine patch:

	* This is a major improvement in terms of maintenance, good job

	* The files that need to be manually copied, those seem to be
	  files that are generated automatically during the build, what
	  is the reason for doing that?

	* To increase the chances of folding these changes back with 
	  the Wine maintainers, it would be best if the "library" option
	  is implemented as a configuration option:

		./configure --enable-mono

	  Or something like that.  

	  With this, instead of removing references to directories,
	  we should conditionally do this, like:


	  Would become:

		if MONO
		SUBDIRS = $(common)
		SUBDIRS = $(common) $(full_wine)

	* Again, to increase the chances of getting some of these
	  changes folded back, we should look into using:

		#ifdef MONO

	  That way we can ensure that we are both happy users of the
	  same code base.

   I do not know how robust the SWF code is today, and I would like
others to post more about their experience (and hopefully with sample
programs), so we can isolate whether there are bugs that need to be
worked around in the WineLib approach, or if they are bugs in both