[Mono-osx] I want to help developing Mac Mono

[Lee V. Andrus]

Yes, I would like to work on an alternate System.Drawing assembly with  
you.  However, be warned that although I am a highly experienced and  
talented programmer, my exposure to OS X API's has been slight since I  
have not been paid to work on Macintoshes in some time.  But I am  
eager to learn, willing to obtain study aids at my own expense, and  
willing to be flexible.

But how do we begin?  How to start a project and get it recognized by  
the Mono Project?  How do we manage source control?  Should I use  
Xcode or Monodevelop (preview or stable release)?  Yes, I am a detail- 
oriented worrier.

As a matter of general philosophy, I an less offended by build-time  
dependencies on freely-available libraries than a run-time dependent  
on the X11 server.  The former is a smaller inconvenience for  
developers than the latter is for end users.  But a library that  
references System.Drawing could create circular dependencies in this  
project.  I am always looking for shortcuts, especially if I am one of  
two people tackling a task this big.  In the short run at least, I  
believe we may need to be prepared to reference, adapt, or copy  
anything that license restrictions permit.

One thing we need to settle quickly is what API we build on.  I have  
some ideas but few conclusions.  The bridges I mentioned promise to  
clear one hurdle for us.  But they are thin wrappers around the native  
frameworks and are not intended to handle some of the translations you  
mention.  A new release of Monobjc that eliminates dependency on  
System.Drawing and has some other powerful features was just  
announced.  But I find the claims of NObjective particularly  
exciting:  Its build uses a translator that extracts info from  
Objective C Introspection to build bridges (including bidirectional  
exception re-throwing) for all frameworks in a list.  If  
System.Drawing is already using Carbon and NObjective lives up to its  
hype, we could build a bridge for Carbon and adapt some of the  
existing work.  However, I know even less about Carbon than Cocoa and  
Apple seems to be deprecating Carbon.  I am willing to go along with  
the opinion of someone who has more knowledge in this area.


On May 16, 2009, at 9:39 AM, Mac Programmer wrote:

> From: Mac Programmer <MacPgmr at fastermac.net>
> Date: May 16, 2009 9:39:36 AM CDT
> To: landrus2 at by-rite.net
> Subject: re: [Mono-osx] I want to help developing Mac Mono
>
> Hi Lee,
>
> Interesting post.
>
> I believe that Mono's System.Windows.Forms implementation on Mac  
> does use System.Drawing fo do everything. One big problem with that  
> is that System.Drawing is dependent on libgdiplus.0.0.0.dylib, a  
> native library included with Mono. This library is dependent on the  
> following native libraries, which are either included with Mono or  
> come from an X11 installation (a showstopper in my opinion). Here's  
> what otool reveals about libgdiplus.0.0.0.dylib:
>
> otool -L libgdiplus.0.0.0.dylib
> libgdiplus.0.0.0.dylib:
>        /Library/Frameworks/Mono.framework/Versions/2.4/lib/ 
> libgdiplus.0.0.0.dylib (compatibility version 1.0.0, current version  
> 1.0.0)
>        /Library/Frameworks/Mono.framework/Versions/2.4/lib/ 
> libglib-2.0.0.dylib (compatibility version 1801.0.0, current version  
> 1801.4.0)
>        /usr/lib/libiconv.2.dylib (compatibility version 5.0.0,  
> current version 5.0.0)
>        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
> current version 88.1.12)
>        /Library/Frameworks/Mono.framework/Versions/2.4/lib/libintl. 
> 8.0.2.dylib (compatibility version 9.0.0, current version 9.2.0)
>        /usr/X11R6/lib/libXrender.1.dylib (compatibility version  
> 1.2.0, current version 1.2.0)
>        /usr/X11R6/lib/libSM.6.dylib (compatibility version 6.0.0,  
> current version 6.0.0)
>        /usr/X11R6/lib/libICE.6.dylib (compatibility version 6.3.0,  
> current version 6.3.0)
>        /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0,  
> current version 6.2.0)
>        /usr/X11R6/lib/libfontconfig.1.dylib (compatibility version  
> 1.0.0, current version 1.0.0)
>        /Library/Frameworks/Mono.framework/Versions/2.4/lib/libexpat. 
> 1.5.2.dylib (compatibility version 7.0.0, current version 7.2.0)
>        /usr/X11R6/lib/libfreetype.6.dylib (compatibility version  
> 6.3.0, current version 6.3.0)
>        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current  
> version 1.2.3)
>        /Library/Frameworks/Mono.framework/Versions/2.4/lib/libtiff. 
> 3.dylib (compatibility version 12.0.0, current version 12.2.0)
>        /Library/Frameworks/Mono.framework/Versions/2.4/lib/libjpeg. 
> 62.dylib (compatibility version 63.0.0, current version 63.0.0)
>        /Library/Frameworks/Mono.framework/Versions/2.4/lib/libgif. 
> 4.1.6.dylib (compatibility version 6.0.0, current version 6.6.0)
>        /Library/Frameworks/Mono.framework/Versions/2.4/lib/ 
> libpng12.0.dylib (compatibility version 36.0.0, current version  
> 36.0.0)
>        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
> current version 1.0.0)
>
> System.Drawing encompasses everything from colors to fonts to  
> images. Currently Monobjc relies on System.Drawing to do a few  
> implicit conversions, for example between System.Drawing.Color and  
> NSColor. These kinds of conversions are handy but of course tie your  
> app to X11.
>
> NObjective and mcocoa don't appear to have dependencies on  
> System.Drawing, but then they don't appear to have ways of doing  
> these conversions either. Also, I believe Laurent is working on  
> removing the System.Drawing dependency and providing some other way  
> of doing the conversions. You might check with Laurent on the  
> Monobjc user list to see where he is with that.
>
> Having a dependency on System.Drawing in Monobjc also presents a  
> problem for me. I started working on a proof-of-concept Monobjc- 
> based WinForms implementation. I'll need to supply some parts of the  
> System.Drawing namespace too but I can't do this as long as another  
> assembly (Monobjc.Cocoa.dll in this case) references the Mono  
> System.Drawing assembly.
>
> Would you be interested in working on an alternate System.Drawing  
> assembly with me? Initially I would only need some of the basics  
> like Font and Color, but obviously the more there is to it the better.
>
> Also, I don't know what the Mono team's plans are for WinForms on  
> Mac. I think it's pretty hideous and unusable in its current Carbon  
> and X11 based form, although if you've looked at the latest  
> MonoDevelop preview you can see that they've been able to put the  
> MonoDevelop menus on the Mac menu bar (although they're using Carbon  
> functions to do it, not Cocoa), so it is possible to clean up a  
> WinForms app a bit. Note that this does not reduce the dependence on  
> libgdiplus.0.0.0.dylib or X11 any.
>
> Thanks.
>
> -Phil Hess

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20090519/57217749/attachment.html