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

Stifu stifu at free.fr
Tue May 19 13:52:13 EDT 2009 

I wish I could help, but I can't... simply because I don't even have a Mac.
Just reporting these 2 bugs above was a pain, as I had to blindly send test
cases to Mac users, and wait for them to confirm whether they triggered the
bug or not.

About getting a project started and included in Mono, having come to this
mailing list is a good start. You could also get in touch with Mono
developers that deal with the Mac implementation (like on the blogs /
monologue section of the site, you'll find people talking about how the Mono
port of MonoDevelop is coming along, and so on).

I don't know about Mac SVN clients, but you should be able to use
MonoDevelop (although it's still buggy on Mac) for C# coding. Stable is
good, but you could try the preview if you hit specific problems with the
stable version. There are also times when previews are actually more stable
than stables...

Anyway, I'll let mac devs discuss the rest with you, and wish you all the
best.


Lee V. Andrus wrote:
> 
> 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
> 
>>
> 
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx
> 
> 

-- 
View this message in context: http://www.nabble.com/I-want-to-help-developing-Mac-Mono-tp23567292p23621305.html
Sent from the Mono - OSX mailing list archive at Nabble.com.

More information about the Mono-osx mailing list