создать кроссплатформенное приложение для windows, mac os x

<p>я хотел бы создать приложение, которое работает как на windows, так и на mac os x. мне бы также хотелось, чтобы оно имело все преимущества того, что может предложить платформа, на которой он работает, в отношении frameworks, api и т.д. способ сделать это без необходимости писать код objective-c, а затем код c #? я думал о c++ как об альтернативе, но мне было интересно, есть ли что-нибудь еще там. приложение будет основано на графическом интерфейсе (хотя я пока точно не знаю, что оно будет делать)</p><p>-г.</p>

<p>хорошо, что вы думаете о переносимости на ранних этапах - гораздо сложнее «запутаться» после свершившегося факта.</p><p>доступны различные кроссплатформенные наборы, но, по-моему, все они не обеспечивают «родной» внешний вид и поддержку всех поддерживаемых платформ. на mac (что я использую) сторонники таких комплектов всегда хотят упомянуть, что они используют нативные элементы управления. это хорошее начало, но это еще не все путешествие. другие вопросы, рассматриваемые <a href="http://developer.apple.com/documentation/userexperience/conceptual/applehiguidelines/xhigintro/chapter\_1\_section\_1.html">apple's human interface guidelines</a> , включают в себя то, как должны быть расположены элементы управления, как должны быть обозначены метки кнопок, какие стандартные сочетания клавиш должны использоваться и т.д.</p><p>даже microsoft пришлось <a href="http://blogs.msdn.com/rick\_schaut/archive/2004/02/26/80193.aspx">узнать трудный путь</a> об опасностях написания кроссплатформенного графического интерфейса с неудачным word 6.0 для mac.</p><p>имхо, лучшим подходом является использование дизайна <a href="http://en.wikipedia.org/wiki/model-view-controller">mvc</a> с уровнем модели, написанным на стандартном, переносимом c++, а уровнями представления и контроллера с использованием собственного инструментария для каждой платформы. в mac-версии carbon и c++ всегда были интересной опцией, которая больше не поддерживается, поэтому вы захотите использовать cocoa, используя objective-c в представлении и objective-c++ в ваших контроллерах для преодоления языкового разрыва. ваша версия для windows также может компилировать вашу модель как «управляемый c++» и использовать любой язык .net для контроллеров и представлений.</p>

<p>взгляните на <a href="http://www.realsoftware.com">real studio</a> . шутки в сторону. вы можете написать приложение в real studio и развернуть его в windows, mac os x и linux.</p><p>правка: real studio сейчас <a href="http://www.xojo.com">xojo</a> .</p>

<p> <a href="http://www.wxwidgets.org/">wxwidgets</a> - это кроссплатформенная библиотека c++, которая является практическим выбором. но я согласен с sherm - все кроссплатформенные библиотеки создают худший пользовательский интерфейс для нативных приложений.</p><p>это усложняется тем, что каждая ос имеет различную семантику пользовательского интерфейса (порядок кнопок и т.д.), поэтому, несмотря на то, что вы можете добиться хорошего внешнего вида, получить правильное «чувство» на каждой платформе с помощью одного уровня представления практически невозможно.</p><p>в зависимости от того, что вы в конечном итоге делаете, веб-интерфейс может оказаться лучше (например, встроить веб-сервер в ваше приложение и передавать страницы http в браузер). тогда вы избегаете проблем с l & f!</p><p>в качестве альтернативы вы можете решить, что у вас будет совершенно нестандартный l & f, и пойти на что-то вроде wxwidgets или tcl/tk.</p>

<p>adobe flex с библиотеками air отлично подходит для создания единой, высокоуровневой среды разработки для такого рода вещей. я написал несколько утилит, которые люди используют на обеих платформах взаимозаменяемо.</p><p>вы также получаете разумную переносимость в браузер, если это представляет интерес. но я думаю, что это довольно хорошее решение без учета этой выгоды.</p>

<p>мое предложение, использовать python. python интегрируется с objective-c и c # (ironpython). просто избегайте множества совершенно новых возможностей языка, и все в порядке.</p><p>конечно, это будет нелегко. но я бы сказал, что это <em>не должно</em> бездумно легко. это становится очень очевидным, когда дизайнеры не принимают во внимание, как будет работать их приложение, когда оно переносится на другую платформу.</p>

<p>если вы решите использовать c++, есть несколько хороших кроссплатформенных библиотек графического интерфейса, которые позволят вам избежать дублирования кода графического интерфейса для каждой платформы. например: </p><ul> <li> <a href="http://www.rawmaterialsoftware.com/juce/">juce</a> </li> <li> <a href="http://trolltech.com/products/appdev">qt</a> </li> <li> <a href="http://www.wxwidgets.org/">wxwidgets</a> </li> </ul><p>есть ряд других подобных проектов, но это одни из лучших и известных проектов. для остальной части вашего кода, конечно, все, что зависит от системы, должно быть написано с использованием отдельного кода c++ для взаимодействия с win32 api или системным api os x, где это необходимо. при этом вы можете обнаружить, что можете избежать большей части системного кода, используя обширные библиотеки, такие как <a href="http://www.boost.org/">boost</a> . </p><p>другие предложения могут быть такими, как использование файла конфигурации вместо реестра windows или файла plist на компьютере mac. вместо этого, по возможности, применяйте независимые от платформы подходы, чтобы свести к минимуму места, где вам приходится писать код с использованием системных api. </p>

<p>вы должны использовать лучшие инструменты, доступные для каждой ос.</p><p>код c/c++ может быть отделен от gui и использоваться в каждой отдельно разработанной программе.</p><p>прежде чем принять решение, взгляните на кроссплатформенные приложения, которые были разработаны с помощью переносимых наборов инструментов, таких как qt или wxwidgets. по моему опыту, они никогда не полируются так же, как их родные аналоги, особенно на mac.</p>

<p>для gui я бы посмотрел в sdl или qt.</p><p>кроме того, проверьте моно <a href="http://mono-project.com/main\_page">http://mono-project.com/main\_page</a> </p>

<p>предстоящий qt-creator может стоить посмотреть: <a href="http://trolltech.com/developer/qt-creator">текст ссылки</a> </p>

<p>спасибо за все ваши ответы. я провел некоторое исследование и поиграл с wpf, canimation и т.д. похоже, что использование модели c/c++ и создание графического интерфейса для каждой платформы - лучший путь. спасибо за вашу помощь.</p>

<p>если вы разработчик для windows, используйте qt или c # winforms; если вы разработчик для mac, вы можете попробовать cocotron ( <a href="http://www.cocotron.org/">http://www.cocotron.org/</a> ), но он еще не закончен на 100%, хотя коммерческие приложения поставляются с ним.</p>

<p>также проверьте <a href="http://fltk.org">fltk</a> , wxwidgets очень хорош и богат, но также очень большой ...</p>

<p>как уже упоминали другие, вполне возможно создать красивый кроссплатформенный графический интерфейс на java как для windows, так и для mac. однако, если вы хотите, чтобы ваше приложение сливалось и вело себя так, чтобы оно "ощущалось" как приложение, разработанное с нуля для платформы, на которой оно работает, вам действительно нужно разработать графический интерфейс и пользовательский интерфейс для каждой версии. приложение отдельно.</p><p>если вы проанализируете, что собирается делать ваше приложение, и поймете, что существует значительная часть кода/логики, которая может быть разделена между платформами, то напишите эту часть переносимым способом на языке, который доступен в обеих системах. c, c++, java, python, ruby и т.д. если значительная часть отсутствует, то есть большая часть кода предназначается для графического интерфейса, тогда меньше возможностей для совместного использования какого-либо кода.</p><p>в случае значительной части общего кода, я бы предложил рассмотреть python и ruby в качестве языков реализации, поскольку существуют привязки cocoa для этих языков на mac и windows с использованием ironpython и ironruby, которые можно использовать повторно. код в .net-приложении. </p>

<p>у ребят из magnetism studios есть приятное <a href="http://macdaddyworld.com/2008/10/27/adventures-in-cocotron/">описание использования cocotron</a> для создания исполняемого файла windows с xcode.</p><p>у меня нет опыта работы с cocotron, но если бы мне нужно было написать приложение для windows - с опытом разработки для mac, это было бы первым, что я попробовал бы.</p>

<p>ява или моно приходят мне на ум. некоторые люди могут возразить, что графические инструментарии java не самые современные, но, по-моему, это, по крайней мере, мне, самый простой способ перенести ваше приложение на несколько платформ и избежать сложностей развертывания.</p><p>mono, с другой стороны, может быть немного сложнее портировать, так как вам придется писать хотя бы дважды графический интерфейс, если вы планируете иметь нативные виджеты (либо winforms или gtk для windows и cocoasharp для max), но вы можете написать бэкэнд только один раз и разработать интерфейс для каждой платформы.</p><p>как я уже говорил, инструментарий java gui может не показаться «родным» внутри osx или даже в windows, но они точно работают на обеих платформах, вы можете использовать swing или awt.</p><p>что касается моно, вы можете использовать gtk или winforms для обоих окон и osx, но они по-прежнему не будут чувствовать себя нативными, вы можете, однако, использовать cocoasharp, которые являются привязками к инфраструктуре cocoa, но я не уверен в статусе проекта (читай: функциональность служба поддержки)</p>

<p>я вторая ява. он разработан как кроссплатформенное решение.</p><p>другие упоминали adobe air. </p><p>похоже на adobe air это silverlight. я считаю, что это (или будет) полностью кроссплатформенный.</p>

<p>если вы выбираете язык c++, я бы определенно рекомендовал <a href="http://www.qt.io">qt</a> для этого. ваше приложение может быть развернуто под windows и mac в соответствии с запросом в op, но также и под linux, а теперь и с последней версией на смартфонах, использующих io, windows rt и android.</p><p>он хорошо документирован и очень активен в сети (в том числе в so).</p><p>единственный отрицательный момент, который я вижу, - это инструмент создания qt, который, imho, менее удобен для пользователя, чем исторические инструменты (например, visual studio), но на самом деле вы не обязаны использовать его в качестве ide для разработки qt. </p>

<p>пока вы не привязаны к языкам, похоже, что java - хороший кандидат. сопоставьте это с swt для графического интерфейса, и у вас будет приложение, которое будет выглядеть нативно на любой ос, которая вам нравится.</p>

<p>вы можете создавать фантастические кроссплатформенные приложения с помощью java swing. просто нужно немного больше усилий, чтобы научиться делать это.</p><p>вот взгляните на некоторые из этих ссылок.</p><ol> <li> <a href="http://jidesoft.com/products/component.htm">http://jidesoft.com/products/component.htm</a> </li> <li> <a href="http://www.xerto.com/imagery.php">http://www.xerto.com/imagery.php</a> </li> <li> <a href="http://www.jgraph.com/screenshots.html">http://www.jgraph.com/screenshots.html</a> </li> <li> <a href="http://www.javootoo.com/">http://www.javootoo.com/</a> </li> <li> <a href="http://www.formdev.com/screenshots/">http://www.formdev.com/screenshots/</a> </li> <li> <a href="http://www.jidesoft.com/products/oss.htm">http://www.jidesoft.com/products/oss.htm</a> </li> </ol>

<p>я планирую сделать то же самое, и я собираюсь создать приложение c #/.net для windows, а затем перенести его на os x, используя mono. мое приложение уже имеет полностью (за исключением строки заголовка и угловых кнопок) пользовательский интерфейс, поэтому косметические различия ос не должны сильно меня затрагивать.</p><p>я не уверен, что вы имеете в виду, используя лучшее из каждой платформы с точки зрения фреймворков и api и так далее. в общем, написание кроссплатформенного приложения означает запись в наименьший общий знаменатель и, следовательно, означает<em> не </em>получение максимальной отдачи от каждой платформы.</p>

<p>для полноты, теперь стоит добавить <a href="http://unity3d.com">unity</a> в список.</p><p>было бы очень сложно создать приложение для каждой платформы, которое выглядит как нативное, а общие инструменты gui далеки от совершенства. но это не просто игровой движок, и вы можете писать на c #/mono, использовать приличный диапазон библиотек и довольно безболезненно развертываться на win и osx.</p>