Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/mono/monomac

Bindings to create MacOS X applications with Mono.
https://github.com/mono/monomac

Last synced: 11 days ago
JSON representation

Bindings to create MacOS X applications with Mono.

Awesome Lists containing this project

README 

        
MonoMac - .NET/C# Bindings to the Cocoa API



DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED 

DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED 

DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED 



	WARNING: MonoMac is not actively maintained, and it has design mistakes

	that prevent it from properly managing memory.   You should use the

	open source Xamarin.Mac instead which is actively maintained, and

	has none of these design problems.

	

https://github.com/xamarin/xamarin-macios.



OLD NOTES:



	MonoMac provides a new set of C# bindings to the Cocoa APIs on

	OSX and can be used to create applications that use the native

	OSX APIs using Mono and C#.



	The code is licensed under the terms of the open source Apache

	License version 2 or the MIT X11 license, at your own choice.



Building:



	To build MonoMac, you need to get two packages:



	   * maccore

	   * monomac



	The first contains the code that is shared between MonoMac and

	MonoTouch.  MonoMac contains the actual bindings that are

	OSX-specific.



	You MUST check out both modules side by side currently.

	To build monomac type "make" which will create the monomac.dll



	MonoMac requires Mono v2.6.4 or higher, you can find a RC for

	2.6.4 at http://mono.ximian.com/monobuild/preview/download-preview/



Using:



	Download the MonoDevelop IDE from www.monodevelop.com for MacOS X,

	it comes with both MonoMac templates and project types that will

	help you get started.



More Information:



	http://www.mono-project.com/MonoMac



Discussion:



	The discussion of the development of MonoMac is taking place

	on irc.gnome.org in channel #monodev and on the

	[email protected] mailing list:



	http://lists.ximian.com/mailman/listinfo/mono-osx



Pending Tasks



	We are looking for contributors to these areas:



	* API binding for the rest of the Frameworks



	* We need samples to be written



	* We need tutorials to be written (like the ones we did for

          MonoTouch)



	* We need to port existing Cocoa samples to C#:

	  * To exercise the binding

	  * To serve as reference for new developers

	  * To identify missing frameworks

	  * To prioritize bindings



Binding APIs



	Information on how to bind new APIs can be found on the MonoTouch web site: 



	http://monotouch.net/Documentation/Binding_New_Objective-C_Types



Goals



	  We had two main requirements: the binding should just work

	  and the code should be MIT X11 licensed.  For the binding to

	  just work, we turned to the .NET Framework Design Guidelines

	  book as it captures years of design decisions, programming

	  idioms and advise that would help C# and .NET developers.  By

	  following the Design Guidelines we:



		Avoid surprises

		Blend with other C# and .NET libraries

		Reduce the room for errors

		Increase developer joy

		Minimizes time for the developer to be productive

		Every bit of existing .NET knowledge translates



	Luckily for us, .NET was designed from the start to be an

	interoperability framework.  A framework that supports the

	most advanced requirements to make multiple runtimes and

	frameworks to communicate seamlessly with each other.  We used

	these features to create our bindings.



	The above goals turned into the following technical

	requirements:



	  * Developers should be able to consume Cocoa APIs as C# APIs

	  * Allow developers to subclass Objective-C classes

	  	* Subclass should work with C# standard constructs

	  	* Derive from an existing class

	  	* Call base constructor

	  	* Overriding methods should be done with C#'s override system

	  	* Do not expose developers to Objective-C selectors

	  * Provide a mechanism to call arbitrary Objective-C libraries

	  * Make common Objective-C tasks easy, and hard Objective-C tasks possible

	  * Expose Objective-C properties as C# properties

	

	  * Expose a strongly typed API, for example instead of

	    exposing the generic-container NSArray or individual

	    NSObjects.  This means that developers get a few benefits:



	  	* MonoDevelop can flag errors as you write the code



	  	* MonoDevelop can present documentation popups on

	  	  types, methods, properties and parameters as you type them.



	  	* Minimize runtime errors by catching invalid casts at

	  	  compile time.

	  	  



	  	* Encourage in-IDE API exploration without rebuilding,

	  	  and without having to look up the types in the

	  	  documentation.



	  * Turn int and uint parameters that should have been enums

	    as C# enumerations and C# enumerations with [Flags] attributes

	  

	  * Expose the basic Foundation as C# native types:

	  	* NSString becomes string

	  	* NSArray becomes strongly-typed array

	  * Events and notifications, give users a choice

	    between:

	  	* Support the Objective-C delegate pattern:

	  		* Strongly typed version is the default

	  		* Weakly typed version for advance

	  		use cases

	  	* C# event system

	  * Class libraries should be MIT X11 licensed, like the rest

	    of Mono's class libraries.



	  * Expose C# delegates (lambdas, anonymous methods and

	    System.Delegate) to Objective-C APIs as "blocks".



	  * Curated APIs: there is no point in binding every UNIX or

	    CoreFoundation C API available, as those are not very

	    useful in practice.  Bind only those that are required to

	    build applications or get access to mandatory

	    functionality.