Создание пользовательских интерфейсов Cocoa для OS X с С# и Mono

Кто-нибудь проводил время, сравнивая различные мосты Objective C и связанные с ними Cocoa обертки для Mono?

Я хочу портировать существующее приложение С# для работы в OS X. В идеале я должен запустить приложение в Mono и создать для него собственный Cocoa интерфейс.

Мне интересно, какой мост будет лучшим выбором.

В случае, если это полезно для всех, вот некоторые ссылки на мосты, которые я нашел до сих пор:

CocoSharp - распространяется вместе с Mono на OS X - www.cocoa-sharp.com
Monobjc - лучшая документация, чем другие (на мой взгляд) - www.mono-project.com/CocoaSharp и www.monobjc.net
NObjective - (по-видимому) быстрее других - code.google.com/p/nobjective
MObjc/MCocoa - code.google.com/p/mobjc и code.google.com/p/mcocoa
ObjС# - www.mono-project.com/ObjCSharp

Ответ 1

Команда Mono выпустила новый мост под названием MonoMac.

Это, по сути, настольная версия среды MonoTouch, созданная для iPhone.

Мигель объявил новый мост в своем блоге здесь: http://tirania.org/blog/archive/2010/Apr-19.html

Как только MonoMac созреет, я подозреваю, что он станет мостом, которым пользуются люди.

Ответ 2

Я недавно тестировал Monobjc, NObjective и MObjc/MCocoa с F #, и я поеду с MObjc/MCocoa.

Monobjc - это то, что вы пишете лучше всего документированный и упакованный, но по сравнению с другими двумя slow и не "ревертирует исключения" из ObjC.

Я считаю, что NObjective и MObjc/MCocoa являются единственными, которые реконструируют исключения из ObjC, и поэтому я считаю их единственными реальными альтернативами.

Как обсуждалось здесь NObjective использует структуры с наследованием, которые я нахожу довольно страшными и заставил меня наконец выбрать MObjC/MCocoa.

(Возможно, у вас также есть проблема с лицензией. Monobjc и NObjective находятся под LGPL, MObjc/MCocoa находится под MIT...)

Ответ 3

Я думаю, что NObjective - лучший выбор, потому что у него есть автоматическая генерация кода для оберток Objective-C, которую можно легко настроить для регенерации оберток для дальнейших версий Mac OS.

Ответ 4

Хорошо, я спрошу: зачем вам это делать? Cocoa Конфигурация пользовательского интерфейса, в том числе Cocoa -std delgates и Cocoa bindngs тесно связаны с Objective-C. Комбинация Interface Builder и Objective-C замечательно продуктивна. Хотя вы можете использовать Interface Builder со многими мостами до Objective-C (включая PyObjC, MacRuby и многие из мостов С#), вы неизбежно потеряете производительность из-за любого несоответствия импеданса между каркасом и выбранным вами языком. С С# это несоответствие является значительным. Поскольку вы пишете собственный пользовательский интерфейс, тем самым теряя кросс-платформенное преимущество, которое вы получите от С#, я бы использовал Objective-C. Для компетентного C/С++/С#/Java/etc. программист, обычно требуется 2-3 дня, чтобы стать комфортным и продуктивным в Objective-C.

Ответ 5

В списке рассылки Mono-OSX произошло довольно продолжительное обсуждение различных мостов.

Обсуждение начинается здесь с Miguel:

Объявление о том, что Cocoa # больше не будет поддерживаться Novell.
Попытка объединить оставшиеся усилия в сообществе.

Если вы прочтете оставшуюся часть обсуждения, кажется, что сообщество Mono склоняется к Monoobjc или MObjc/MCocoa; поэтому, если вы делаете свои собственные исследования, это, вероятно, те, на которых нужно сосредоточиться.

Ответ 6

Не спрашивайте, почему, поскольку у вас есть свои причины, я уверен.

Я бы посмотрел проект Unity3D и посмотрел, можете ли вы рассказать, как они это сделали. Выглядит, мм, тяжело.