[Mono-osx] Mono 2.6 and Windows.Forms on MacOSX

Lee V. Andrus landrus2 at by-rite.net
Tue Dec 29 17:52:35 EST 2009



Andrew Brehm wrote:
> 
> 
> 
> Lee V. Andrus wrote:
>> 
>> I am currently working on a Cocoa-based replacement for the Carbon Driver
>> that is the default implementation of Windows.Forms on OS X.  I hope that
>> it will eliminate some inefficiencies and some impediments to support of
>> 64-bit applications.  After I get it working as well as the Carbon
>> Driver, I will start filling in some of the missing pieces.
>> 
> 
> Excellent!
> 
> Do you need any help via testing or donations?
> 

Getting some money for this would enable me to devote more time to it.  At
some point I will probably need help creating unit tests or verifying that
it does not hurt other platforms.  But my greatest need is for some expert
advice on Mono, the Cocoa framework, bridging them, and advanced Mac
programming.

I am currently using the MObjc/MCocoa bridge.  They have bidirectional
translation of exceptions, marshaling of Mono application classes into
Objective C proxies, extensible and flexible wrapper code generation, simple
initialization callable from C#, and no reliance on undocumented
features--but no support for a Protocol as a parameter type.  The other
products all had critical deficiencies (although NObjective has very
recently stopped using an outlaw feature, inheritance in value types). 
Using any bridge package raises issues.  The structure of the makefiles
under the mcs directory makes excluding the dependency from builds on other
systems difficult.  The powers that be in the Mono community have expressed
reservations about making Mono dependent on such a package until it gathers
such a following as to be bundled with Mono like Cocoa#.

Most examples of Cocoa event handling involve subclassing Cocoa classes and
overriding a different method for each event type.  For that reason and
because event handling in Mono's System.Windows.Forms does not fit with
using the Cocoa run loop, I try to take events directly from the event
queue.  But some "events" are not presented as NSEvent objects in the event
queue.

I could really use a cookbook of Carbon to Cocoa translations, some notes on
the thinking that went in to some design decisions in System.Windows.Forms
(particularly the XplatUI subsystem--especially XplatUICarbon), and someone
I could talk things over with.  It would also be helpful for someone in the
know to add summary comments to all the abstract or virtual properties and
methods in XplatUIDriver detailing what is expected of their
implementations.  It is sometimes difficult to tell from looking at the
other implementations that may not have a simple translation to Cocoa, how
closely I need to mimic code that may be essential, an implementer's style,
unimplemented, or just wrong.
-- 
View this message in context: http://old.nabble.com/Mono-2.6-and-Windows.Forms-on-MacOSX-tp24047606p26961640.html
Sent from the Mono - OSX mailing list archive at Nabble.com.



More information about the Mono-osx mailing list