Я планирую создать приложение с графическим интерфейсом для Mac и Windows. Я проводил некоторые исследования по выбору технологий, таких как язык, библиотеки и инструменты сборки, чтобы я мог разделить как можно больше кода между двумя платформами.

The main requirements are:

Meets the Mac App Store requirements. Native look and feel on both Mac and Windows. Need to call into Quartz Window Services on Mac and the Windows API on Windows. Store and read data using SQLite.

Длина моего поста вышла из-под контроля, поэтому я переместил свои вопросы наверх в качестве резюме, а контекст ниже.

Questions I am leaning toward using Python for the ease of programming. Is this the right choice for me? If not why would C++ be better? And if so, how exactly do I get py2app and pyobjc set up to compile the python and build a standalone app that loads XIBs for GUI? Am I right that I should not use cross-platform GUI libraries on Mac for the sake of a more native interface? Or would I be better off using QT or wxWidgets? If I am going down the wrong path and/or there are better solutions that I have not considered, please point them out :) My research and conclusions so far GUI libaries

Для Mac я исключил использование кросс-платформенных библиотек графического интерфейса пользователя (таких как QT), поскольку кажется, что они не способны обеспечить естественный внешний вид на Mac (выглядят неуместно и / или трудно писать приложения, которые следуют Apple & apos ; s Руководство по взаимодействию с людьми). wxWidgets говорит, что использует нативные библиотеки, но этосообщение упоминает, что wxPython может использовать частные вызовы Objective-C и вряд ли будет одобрен для Mac App Store. Наконец, даже если внешний вид правильный, макеты, вероятно, все равно должны будут отличаться для двух платформ.

Поэтому я планирую использовать собственные библиотеки Cocoa GUI для интерфейса Mac, хотя все еще рассматриваю возможность использования wxWidgets для Windows GUI.

Language

Похоже, мой лучший выбор языка для основной логики приложения - C ++ или Python. Очевидно, что писать кросс-платформенный код на Python намного легче, чем на C ++, но всегда есть компромиссы.

Python

Pros: Намного быстрее писать и легче поддерживать. Надежные кроссплатформенные библиотеки, которые могут значительно сократить время разработки.

Cons: Использование Python означает использование PyObjC, который не обновлялся более года (как видно из SVN), и мне неясно, будет ли он по-прежнему работать с будущими версиями Xcode и OSX. Кроме того, настроить любую конфигурацию нормальной сборки с помощью PyObjc и py2app и использовать xibs для графического интерфейса вне Xcode - это кошмар.

C++

Pros: Проще настроить конфигурацию сборки и зависимости как на Mac, так и на Windows. Работает намного быстрее, чем Python, хотя в моем случае производительность не представляет большой проблемы.

Cons: Я не знаю C ++. Я довольно хорошо разбираюсь в C, но, похоже, это не сильно поможет мне в написании хорошего C ++. У меня сложилось общее впечатление, что писать кроссплатформенный C ++ гораздо сложнее, но я могу ошибаться. Есть много сообщений о неясных ошибках. Boost выглядит многообещающе, хотя.

Build tools

Настройка с использованием C ++ в качестве основного языка кажется достаточно простой на обеих платформах. Если я использую Python, его также легко установить в Windows, так как я бы использовал wxWidgets для графического интерфейса и py2exe для развертывания.

Что касается Mac и Python, стандартный выбор, кажется, pyobjc и py2app. К сожалению, я не нашел каких-либо примеров конфигурации сборки с py2app, которая использует библиотеки XIB и Cocoa, а не QT или wxWidgets. Я не хочу, чтобы Xcode управлял сборкой, так как я бы предпочел, чтобы файлы Python и ресурсы приложения размещались вне  каталог проекта Xcode. Это значительно упростит настройку Windows и сделает дерево файлов более чистым.

Edit regarding QT: Я еще раз взглянул на QT, потратив пару часов, играя с QT дизайнером. Основные элементы пользовательского интерфейса (кнопка, текстовое поле, метка) выглядят так же, как элементы какао. Я легко соединил QWindow и QTabView с некоторыми элементами, и это похоже на приложение Какао. Однако было несколько минусов:

Behavior's a little off, like lack of elastic scrolling, QTextEdit doesn't have the blue shadow indicating focus. QTableView doesn't look much like its Cocoa counterpart. Spacing between elements, spacing to parent view, do not follow guidelines. It's mostly fixable by tweaking the layouts, but needs to be done everywhere and I'd get it with Xcode for free. Missing the HUD element for making the inspector. This is something I would very likely need in my app, at least for the Mac side. Poor accessibility support.

Я знаю, что я разборчив, но должен быть разборчив, чтобы сделать хороший интерфейс. В целом QT кажется хорошим решением для Windows, но я думаю, что я остановлюсь на Cocoa для Mac. Я провел дополнительное исследование существующих программ и обнаружил, чтоVLC, Хром, а такжекоробка передач все делают собственные графические интерфейсы для Mac, в то время как VLC использует QT для Windows, Chrome использует пользовательскую среду, а Transmission использует GTK + и QT для Linux.

Я думаю, что я решил использовать Cocoa GUI для Mac и Qt или wxWidgets для Windows, но все же разделен между C ++ и Python для общей логики.