kanato's picture

Develop Cocoa native window interface.

Project:The Open Toolkit library
Version:1.x-dev
Component:Code
Category:task
Priority:normal
Assigned:kanato
Status:open
Description

This issue is to track information pertaining to the development of a Cocoa native window interface on Mac OS X. Carbon has been deprecated in Mac OS X for a while now. The recent release of Snow Leopard finally supports 64-bit kernel and applications, but only with Cocoa. A Cocoa native window implemention should be developed for OpenTK to allow OpenTK applications to run as 64-bit applications, and also to keep up with the times, since the future of Carbon is uncertain.

It appears we need to develop our own objective-c bindings for this. The MonoObjC project is the current Cocoa bindings used in Mono, but it is LGPL so we can't just borrow the source. The older CocoaSharp bindings are no longer maintained, and it's not clear to me what their license is.

Apple has Objective-C runtime information which can be used to develop C# bindings:
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/Obj...


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kanato's picture

#1

Some tutorials on working with Cocoa without interface builder files:
http://lapcatsoftware.com/blog/2007/05/16/working-without-a-nib-part-1/

swiftcoder's picture

#2

Add my voice to the request, especially on the consideration that Mono's AOT compilation is so far restricted to 64-bit.

I have done similar work on an (in progress) Cocoa back-end for Pyglet, so I can offer advice/help once you have a working mono<->ObjC bridge.

However, I would caution that writing your own ObjC bindings is a considerable undertaking. is there a reason why Monobjc couldn't be an external dependency (as PyObjC is for Pyglet on Mac)? It seems to me that the license is only a problem if you wish to fork Monobjc into OpenTK's own code...

the Fiddler's picture

#3

Depending on monobjc is an option, but it's not ideal from a deployment standpoint. Yes, this is a manifestation of the "not-invented-here" syndrome, but there are some real advantages to this approach: namely, you can deploy your application on any OS using a simple file copy. This is part of the reason why we are not relying on Tao.Sdl or similar libraries.

The mitigating factor is that we don't need anything near a complete Cocoa binding for use in OpenTK, which means our task is at least two orders of magnitude easier than what monobjc needs to do.

I guess one sensible approach would be to use monobjc to create a working implementation first and then remove the dependency by creating direct bindings to the necessary Cocoa APIs.

kanato's picture

#6

I was just reviewing the state of C#/Mac bindings and I came across this: http://tirania.org/blog/archive/2010/Apr-19.html
In particular, monomac/src/OpenGL/ has Cocoa/OpenGL bindings written. And it's MIT licensed. I think with a bit of work the necessary parts could be integrated into OpenTK to use.