[Mono-osx] Mono 2.6 and Windows.Forms on MacOSX
ajbrehm at gmail.com
Wed Dec 30 04:44:24 EST 2009
Lee V. Andrus wrote:
> 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
I am not so good with the advanced anything, but I can send some money if
you tell me where.
I can also test.
I am familiar enough with .NET but only on the write-applications level, not
the extend-framework level.
> 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#.
Delphi Prism comes with Monobjc. Perhaps Novell should include all three
Cocoa bridges in Mono or set up a meeting with all the people involved so
that everyone can come up with a decision.
I don't think it's good that we have three (technically two) bridges to
> 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.
Over my head... I know about the .NET event model and a bit about the way
Cocoa handles this, but don't understand at all how these two could possibly
be made to work together. Good luck!
> 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.
Aren't the people of the Qt framework dealing with a similar problem at the
moment? I think they are still porting Qt to Cocoa after having finished a
Carbon port and then finding out that Carbon doesn't support 64 bit code.
Anyway, I'll happily test and support in any way I can!
View this message in context: http://old.nabble.com/Mono-2.6-and-Windows.Forms-on-MacOSX-tp24047606p26965606.html
Sent from the Mono - OSX mailing list archive at Nabble.com.
More information about the Mono-osx