Я планирую создать графическое приложение для Mac и Windows. Я делал некоторые исследования в области выбора технологий, как в языках, библиотеках и инструментах сборки, поэтому я могу делиться как можно большим количеством кода между двумя платформами.
Основные требования:
- Отвечает требованиям магазина Mac App Store.
- Родной внешний вид и на Mac, и на Windows.
- Вам нужно позвонить в Quartz Window Services на Mac и Windows API в Windows.
- Сохранять и читать данные с помощью SQLite.
Длина моего сообщения вышла из-под контроля, поэтому я переместил свои вопросы в начало в виде сводки, а контекст ниже.
Вопросы
- Я склоняюсь к использованию Python для удобства программирования. Это правильный выбор для меня? Если бы не почему С++ был лучше? И если да, то как именно я могу получить py2app и pyobjc, чтобы скомпилировать python и создать автономное приложение, которое загружает XIB для GUI?
- Правильно ли, что я не должен использовать кросс-платформенные библиотеки GUI на Mac ради более родного интерфейса? Или мне лучше использовать QT или wxWidgets?
- Если я иду по неверному пути и/или есть лучшие решения, которые я не рассматривал, укажите их:)
Мои исследования и выводы до сих пор
Расширения GUI
Для Mac я исключил использование кросс-платформенных графических интерфейсов (например, QT), поскольку не похоже, что они могут обеспечить собственный внешний вид на Mac (выглядят неуместно и/или трудно писать приложения которые следуют Руководствам по человеческому интерфейсу Apple). wxWidgets говорит, что он использует родные библиотеки, но этот post упоминает, что wxPython может использовать частные вызовы Objective-C и вряд ли будет одобрен для Mac App Store. Наконец, даже если внешний вид прав, макеты, вероятно, по-прежнему должны будут меняться для двух платформ.
Поэтому я планирую использовать родные библиотеки Cocoa GUI для интерфейса Mac, хотя все еще рассматриваю использование wxWidgets для графического интерфейса Windows.
Язык
Кажется, что лучшим выбором языка для основной логики приложения является либо С++, либо Python. Очевидно, что гораздо проще писать кросс-платформенный код с Python, чем С++, но всегда есть компромиссы.
Python
Плюсы: гораздо быстрее писать и проще поддерживать. Надежные межплатформенные библиотеки, которые могут значительно сократить время разработки.
Минусы: использование Python означает использование PyObjC, которое не обновлялось более года (как видно из svn), и мне непонятно, будет ли он работать с будущими версиями Xcode и OSX. Кроме того, для настройки любой строгой конфигурации сборки с PyObjc и py2app и использования xib для графического интерфейса, вне Xcode, является кошмаром.
С++
Плюсы: проще настроить конфигурацию сборки и зависимости как на Mac, так и на Windows. Работает намного быстрее, чем Python, хотя производительность в моем случае не является большой проблемой.
Минусы: я не знаю С++. Я очень хорошо знаком с C, но похоже, что это не поможет мне написать хороший С++. У меня сложилось общее впечатление, что писать кросс-платформенный С++ гораздо сложнее, но я могу ошибаться. Есть много сообщений о непонятных ошибках. Boost выглядит многообещающим.
Инструменты сборки
Настройка приложений, если использование С++ в качестве основного языка кажется достаточно простым на обеих платформах. Если я использую Python, он также кажется простым настроить в Windows, поскольку я буду использовать wxWidgets для развертывания графического интерфейса и py2exe.
Как и для Mac и Python, стандартный выбор выглядит как pyobjc и py2app. К сожалению, я не нашел примеров конфигурации сборки с py2app, которая использует библиотеки XIB и Cocoa, а не QT или wxWidgets. Я не хочу, чтобы Xcode управлял сборкой, так как я предпочел бы, чтобы файлы и ресурсы Python размещались за пределами каталог проекта Xcode. Это значительно упростило бы настройку для Windows и упростило бы файловое дерево.
Изменить QT: Я еще раз взглянул на QT, проведя пару часов, играя с дизайнером QT. Основные элементы пользовательского интерфейса (кнопка, текстовое поле, метка) выглядят так же, как элементы Cocoa. Я собрал QWindow и QTabView с некоторыми элементами легко, и он выглядит как приложение Cocoa. Однако было несколько негативов:
- Поведение немного не работает, как отсутствие эластичной прокрутки, QTextEdit не имеет синей тени, указывающей фокус.
- QTableView не похож на его сопоставитель Cocoa.
- Расстояние между элементами, расстояние до родительского представления, не следует принципам. В основном это исправление путем настройки макетов, но это нужно делать везде, и я бы получил его с Xcode бесплатно.
- Отсутствует элемент HUD для создания инспектора. Это то, что мне, скорее всего, понадобится в моем приложении, по крайней мере, для Mac.
- Плохая поддержка доступности.
Я знаю, что я придирчивый, но должен быть разборчивым, чтобы создать хороший пользовательский интерфейс. Общий QT, похоже, является хорошим решением для Windows, но я думаю, что буду придерживаться Cocoa для Mac. Я провел некоторое дополнительное исследование существующих программ и обнаружил, что VLC, Chrome, и Transmission все делают собственные графические интерфейсы для Mac, в то время как VLC использует QT для Windows, Chrome использует настраиваемую структуру, а Transmission использует GTK + и QT для Linux.
Я думаю, что решил использовать графический интерфейс Cocoa для Mac и Qt или wxWidgets для Windows, но все же разделил между С++ и Python для общей логики.