[Mono-winforms-list] Re: patches for Win32 API libraries
Miguel de Icaza
miguel@ximian.com
05 May 2003 21:53:17 -0400
Hello!
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
there.
* 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:
SUBDIRS = A B C D E
Would become:
if MONO
SUBDIRS = $(common)
else
SUBDIRS = $(common) $(full_wine)
fi
* Again, to increase the chances of getting some of these
changes folded back, we should look into using:
#ifdef MONO
...
#else
#endif
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
environments.
Miguel.