Как установить qmake mac os

Рисоваська под Mac (как собрать Qt-приложение под Mac OS X)

Upd. Чтобы помочь в тестировании под разные дистрибутивы Linux — подключайтесь в группу «Друзья Рисоваськи»

Еще в начале января я собрал первую работающую версию Рисоваськи под Mac и лишь два дня назад появилась версия, которую не стыдно показывать другим людям. Сначала расскажу почему же портирование на Mac заняло так много времени, а потом — как собрать проект на Qt под Mac OS X

Почему так долго

В команде не было Mac-эксперта

Есть ошибки в работе Qt (4.5.0 и 4.5.1) под Mac OS X

Подозреваю, что немногие пишут Mac-программы с использованием C++ и Qt. Видимо, в основном используют нативные инструменты — Objective-C, Cocoa. То тут, то там в Qt встречаются мелкие недоделки, разное поведение стилей и лэйаутов и прочие неприятности.

XCode очень сильно отличается от Visual Studio

Совершенно другие схемы интерфейса, совершенно другая (очень слабая) поддержка Qt. Пока не привыкнешь — уходит много времени на самые простые действия. Более того, поскольку это всё же Unix, поэтому многие вещи нужно выносить в командные файлы, а не совершать их каждый раз руками, что тоже отличает разработку в Mac OS X от разработки в Windows. Я лично очень полюбил консоль.

Mac OS X — это совсем другой мир

В остальном не хватало просто смелости решить для себя, что Mac OS X — это действительно другой мир, который нужно изучать, любить и с которым дружить.

Краткое руководство под сборке Qt проекта на Mac OS X

Если вы написали какое-то приложение под Windows с использованием Qt и хотите собрать его под Mac OS X, то вот вам краткая инструкция:

1. Устанавливаем последнюю версию XCode, вместе с ней устанавливается компилятор gcc

2. Качаем Qt — www.qtsoftware.com/downloads, мы качали Framework Only (122 Mb)

3. Собираем Qt с учетом специфики проекта (мы собирали статическую версию):

cd /tmp/qt-mac-opensource-desktop-4.5.1
./configure -prefix /Developer/Qt -qt-zlib -qt-libpng -qt-libjpeg -svg -qt-libtiff
-qt-libmng -qt-gif -qt-sql-sqlite -openssl -universal -sdk /Developer/SDKs/MacOSX10.4u.sdk -static -release

-prefix /Developer/Qt — куда устанавливать Qt
-qt-zlib -qt-libpng -qt-libjpeg -svg -qt-libtiff -qt-libmng -qt-gif -qt-sql-sqlite — список подключаемых Qt-плагинов
-openssl — собираем с поддержкой openssl (его нужно установить заранее)
-universal — чтобы работало на процессорах Intel и PowerPC
-sdk /Developer/SDKs/MacOSX10.4u.sdk — путь к SDK 10.4 universal
-static — статическая версия
-release — только релиз-версия, потому что основные баги Qt мы уже отладили

make -j 4 sub-src
sudo make install

-j 4 — собирать в 4 потока, ускоряет сборку при наличии двухядерного процессора, правда и машину нагружает
sub-src — собирать только «ядро» Qt, не собирать всякие примеры и дополнительные утилиты

/.bash_profile:
PATH=»/Developer/Qt/bin:$PATH»
export PATH
export QTDIR=/Developer/Qt
export QMAKESPEC=macx-g++

Всё, Qt установлена.

4. Сгенерировать файл проекта XCode

Файлы проекта под Windows — обычно .sln и .vcproj. В них указано какие файлы относятся к проекту, какие дополнительные библиотеки подключать и т.п. Нам нужно создать такой же файл, но для XCode. Хорошая новость — собирать его вручную каждый раз при изменении проекта не придется, потому что этот процесс можно автоматизировать.

Допустим что у нас проект состоит из двух папок — MoodBox (UI, сеть и всё остальное) и Velasquez (рисовальный движок). Под Windows у нас есть MoodBox.vcproj, который включает все необходимые файлы из папки Velasques

4.1 Создаем в любимом редакторе файл с описанием проекта MacOS.pro

# тут мы подключаем файлы с переводами
TRANSLATIONS = moodbox_en.ts \
moodbox_ru.ts

# настройки Qt и плагинов
QT += network xml svg
QTPLUGIN += qjpeg qgif qmng qsvg qtiff

# задаем иконку для проекта и имя приложения
ICON = moodbox-dock.icns
TARGET = MoodBox

# добавляем пути include и библиотеки
INCLUDEPATH += /sw/include/ImageMagick /sw/include/ImageMagick/Magick++
LIBS += -lMagick++ -lMagickCore -lMagickWand
LIBS += -L/sw/lib/

# указываем DEBUG, чтобы легче отлаживаться
DEFINES += DEBUG

# добавляем необходимые данные в bundle
data.path = Contents/Resources
data.files = $$(PWD)/Avatars $$(PWD)/Clipart $$(PWD)/Sound $$(PWD)/catalogue.pal
QMAKE_BUNDLE_DATA += data

# убираем то ненужное, что лежит в папке MoodBox, но не нужно для сборки проекта
HEADERS -= _PaletteConverter/stdafx.h \
_PaletteConverter/targetver.h

SOURCES -= _PaletteConverter/PaletteConverter.cpp \
_PaletteConverter/stdafx.cpp \
qtsingleapplication_win.cpp \
qtsingleapplication_x11.cpp

# добавляем нужные файлы из проекта Velasquez

HEADERS += ../../Velasquez/Qt/backgroundelement.h \
../../Velasquez/Qt/backgroundtool.h \
../../Velasquez/Qt/undocommands.h \
../../Velasquez/Qt/varianthash.h \
../../Velasquez/Qt/vcommon.h

SOURCES += ../../Velasquez/Qt/backgroundelement.cpp \
../../Velasquez/Qt/backgroundtool.cpp \
../../Velasquez/Qt/brushdrawingelement.cpp \
../../Velasquez/Qt/undocommands.cpp \
../../Velasquez/Qt/varianthash.cpp

Этот файл нужно менять только при изменении настроек или при включении/исключении файлов из других папок. Новые файлы из папки MoodBox подключатся автоматически.

4.2 А теперь создаем скрипт make-pro.sh, который как раз и будет генерировать проект XCode

4.3 Открываем полученный MoodBox_Mac.xcodeproj в XCode, соглашаемся с выбором папки проекта.

4.4 Заходим в меню XCode: Project — Edit Active Target и устанавливайте следующие параметры:

5. Жмём большую кнопку «Build and Go»

Если проект не очень сложный, то программа скомпилируется, слинкуется и будет запущена. А если сложный (есть зависимости с другими библиотеками, есть windows-specific код, активно используются стили .qss), то придется еще поработать — выделять специфичный для платформ код в #ifdef, разделять файл стилей на общие стили и стили, специфичные для платформ, а потом клеить эти файлы при загрузке приложения, собирать сторонние библиотеки с поддержкой universal и многое-многое другое.

Источник

Интеграция приложений Qt в среду Mac OS X (с использованием Cocoa и Objective-C++)

Доброго всем дня!

Недавно я писал о кастомизации заголовка окна в Mac OS X и получил реквесты написать поподробнее о взаимодействии Qt и Cocoa. Думаю, тему можно немного развернуть и написать об интеграции приложений, написанных с помощью Qt, в среду Mac OS X. Оговорюсь, что используется в данном случае Qt for Cocoa, если возьмёте Qt for Carbon, то и работать придётся только с карбоном. Но он морально устарел, и использовать его стоит только в крайних случаях.

Обычная Qt-программа имеет ряд несостыковок с Apple HIG. Точнее, может иметь, так как не всем программам нужен дополнительный функционал. Например, не любой программе надо иметь бэдж поверх значка в доке, расширять меню дока или выносить/дублировать некоторые функции в маковское меню.

Но что делать, если такой функционал нужен? Если нужно отображать в доке количество уведомлений (а-ля скайп), обрабатывать клик по иконке в доке, добавлять свои пункты меню в док, да ещё и иметь нормальное меню, в общем, сделать так, чтобы программа смотрелась как родная в Mac OS? Что-то из этого можно сделать с помощью штатных или полудокументированных функций Qt, а что-то — только с использованием Cocoa и, соответственно, Objective-C… Что же делать?

Нам поможет Objective-C++!

Что это за зверь и с чем его едят? По сути, это возможность комбинировать Objective-C и C++ классы в одном файле исходников. Причём, расширение заголовочников остаётся стандартным (.h), а вот для исходников нужно указывать расширение .mm, чтобы компилятор его съел и не поперхнулся.

Теперь представим себе, что у нас есть некий (может быть даже большой) проект, написанный с помощью Qt. Изначально он писался под винду или линукс, а вот теперь его надо перенести в макось, да так, чтобы было красиво и удобно, чтобы маководы не морщили нос при виде этого чудища.

Понятно, что для начала надо подстроить интерфейс программы под Apple HIG, без этого никуда, но это останется за рамками данной статьи, упомяну лишь полезные дефайны Q_WS_*, которые позволяют компилить разный код для разных ОСей. Мы же будем говорить о том, какими средствами можно подстроить своё приложение под новое окружение (или же как создать Mac-приложение на Qt с нуля — это зависит от поставленных целей).

Итак, пойдём по порядку.

Общая интеграция

Для начала дадим имя и значок программе. Нет, не то имя, которое имеет бандл, а имя, которое будет отображаться в Application Menu. Для этого нам потребуется свой файл Info.plist, а не тот, что генерирует qmake. Это делается одной строчкой в .pro:

В наш .plist пишем что-то такое:

Разумеется, вместо «MyAppName» и «com.mycompany.myapp» пишем английское название программы и свой идентификатор бандла. Почему английское? Да потому что локализуем мы его в другом файле. На это указывает самый первый параметр в плисте: LSHasLocalizedDisplayName. Создаём директорию «ru.lproj», а в ней файл InfoPlist.strings. В этот файл пишем что-то такое:

Здесь уже нужно указывать локализованное название бандла и имя, отображаемое в Application Menu. Чтобы это заработало, нужно при установке программы скопировать эту дерикторию в AppName.app/Contents/Resources, делать это лучше через указание INSTALLS в .pro файле, за подробностями прошу обращаться к документации к qmake. На скриншоте видно, что Application Menu имеет русское название, несмотря на то, что сам бандл имеет название на латинице.

Чтобы задать иконку программы (см. myicon.icns в файле MyInfo.plist), нам нужен файл .icns, который можно создать самому в графическом редакторе, либо сконвертировать из .ico или кучки .png с помощью программ или онлайн сервисов. Чтобы смотрелась иконка хорошо, лучше сделать в ней несколько размеров: 512×512, 256×256, 128×128, 64×64, 48×48, 32×32, 16×16. Система сама выберет какой размер в какой ситуации отображать. Файл с иконкой надо так же устанавливать в Resources. Самый простой способ заставить его устанавливаться — это прописать следующее в .pro файле:

Разделение кода

У Objective-C++ есть множество ограничений. Нельзя, к примеру, включать хедер с объявлением интерфейса Objective-C класса в файл исходников .cpp, ибо компилятор подавится. Для новых проектов, расчитанных только на Mac OS X, это не будет ограничением, ибо можно весь C++ код держать в .mm файлах и радоваться жизни. Но смысл Qt в кроссплатформенности, так что будем считать, что наши исходники всё-таки в .cpp файлах.

Выход тут прост. Надо создать «обёртку» для Objective-C вызовов и классов на C++. Я выбрал такую структуру: есть Qt/C++ класс, который обеспечивает интеграцию с Mac OS X. Какую-то работу он выполняет сам, а какую-то перепоручает «делегату», приватному классу, активно использующему Cocoa/Objective-C. При этом, получаем следующие файлы:

* myclass.h — заголовок основного класса
* myclass.cpp — реализация
* myclass_p.h — заголовок приватного класса (без Objective-C-интерфейсов)
* myclass_p.mm — исходники приватного класса, могут включать в себя интерфейсы и имплементацию классов Objective-C, включать любые хедеры и т.п.

Таким образом, мы чётко разграничиваем C++ и Objective-C++.

Кстати, чтобы Objective-C++ заработал, в .pro файле надо все хедеры/исходники, использующие его, помещать в секции OBJECTIVE_HEADERS и OBJECTIVE_SORCES. И, разумеется, делать это внутри блока macx: <>. А ещё, если мы хотим использовать Cocoa, то надо добавить этот фреймворк к проекту. Пишем в .pro:

А теперь пойдёт интересное.

Работа с Dock

Рассмотрим пять основных функций работы с доком: добавление бэджа, добавление оверлея, обработка клика на иконке в доке, «подбрасывание» иконки программы в доке и добавление своего меню. Средствами Qt решить можно только последнюю проблему, да и то слабо документированной функцией qt_mac_set_dock_menu(QMenu*). Причём объявить её надо самим, как внешнюю:

На меню, исходя из личного опыта, накладываются некоторые ограничения в сравнении с «родным» маковским меню:

* неактивные (disabled) пункты меню становятся зачем-то активными
* QMenu не эмиттит сигналы aboutToHide и aboutToShow
* нельзя сделать отступ каких-либо элементов
* если первый QAction в меню — разделитель, то он будет виден (в отличие от всех остальных проявлений QMenu)

Так что под это придётся подстраиваться. Можно, конечно, сделать всё на Objective-C/Cocoa, но тогда придётся делать свой механизм маппинга QAction’ов и родных пунктов меню. Но это имеет смысл делать только при действительно большой необходимости в устранении указанных ограничений.

Рассмотрим теперь клик на доке. Если бы мы писали на Cocoa, то проблем бы не было, достаточно было бы в AppDelegate реализовать метод applicationShouldHandleReopen:hasVisibleWindows:. Но мы не имеем прямого доступа к делегату программы, созданному в недрах Qt. Поэтому воспользуемся магией рантайма для добавления реализации этого метода. Для начала объявим функцию, которая будет реализовывать то, что нам нужно. Для этого превратим наш приватный класс в синглтон (всё равно нам не нужно более одного объекта этого класса) и напишем такую функцию:

Функция мертва без внедрения её в делегата. Не будем же с этим медлить!

Здесь мы берём класс делегата нашего приложения и добавляем в него метод на лету. И заодно реализуем метод emitClick(), эмиттящий Qt-сигнал о клике. Собственно, вот и всё, теперь по клику в доке мы можем показывать, к примеру, главное окно программы.

Далее можно попробовать подбросить иконку программы в доке. Первая же мысль: «так это же умеет делать QApplication::alert(QWidget*)!» Мысль верная, но преждевременно оптимистичная. Всё дело в том, что в Mac OS X 10.6.* эта функция работает как надо, а вот в 10.7.* почему-то не хочет (может быть, это связано с тем, что Qt 4.7.x официально не поддерживает Lion, а в 4.8 это пофиксят). Я не стал разбираться почему так происходит, и просто написал подбрасывание на Cocoa, благо это делается одной строкой:

И пусть этот кусок кода дублирует Qt-шный alert(), зато работать будет во всех версиях Mac OS X. А для других систем можно по-прежнему использовать alert().

Теперь разберёмся с бэджем. Если кто не в курсе, то это крсный кружок с текстом, отображаемый поверх значка программы в доке. Например, он используется для отображения числа непрочитанных писем в Mail.app. Документация от Apple говорит, что делать это надо так:

Здесь badgeString имеет тип NSString*. Ага, вот и первое неудобство! В Qt обычно идёт манипулирование QString, а значит, надо написать некий «конвертер» строк:

Как видно из кода (и из комментария к нему), возвращаемая строка не релизится, так что придётся делать это в вызывающем коде (Qt не использует ARC, так что за памятью следить будем сами).

Теперь можем написать функцию нашего приватного класса, которая будет выводить нужную нам строку в бэдже дока:

Теперь последний аспект работы с доком — добавить произвольный оверлей в док. Это делается с помощью следующего кода:

Здесь view это NSView*. Но мы-то работаем с Qt! А значит, нам надо в оверлей поместить QWidget*. Как же получить из QWidget’а его NSView? Пишем простую функцию:

Всё просто, создатели Qt сделали почти всю работу за нас.

Но, увы, ждёт нас облом: NSView, полученный из QWidget’а непригоден для установки в док. То есть, он ставится, NSDockTile его съедает, но вместо содержимого виджета в доке образуется пустое место. Не знаю уж, почему. Но даже в Qt Creator’е прогресс-бар в док вешается именно через свой чистый NSView, созданный специально для этого. Так что, если нужен свой оверлей, то милости просим написать свой View на Cocoa. Увы.

Работа с меню

Перейдём к маковскому меню (тому, что на верхней панели). По умолчанию, Qt-программа его не создаёт (ну, если не считать стандартного Application Menu с системными функциями). Первое, что приходит на ум Qt-разработчику, это QMenuBar. И действительно, в документации к нему написано, что он может выполнять функции маковского меню. Но тут два варианта: либо сделать отдельный QMenuBar для каждого окна программы, либо сделать один глобальный. Выберем второй вариант в силу его неоспоримых преимуществ.

Опять же, исходя из документации, нам нужно создать QMenuBar с нулевым родителем, т.е., QMenuBar * macMenuBar = new QMenuBar(NULL), тогда он будет глобальным. Точнее, первый, из соданных таким образом менюбаров, станет глобальным.

А теперь — куча монотонной работы руками. Создаём сами меню «Правка», «Файл», «Справка» и так далее. Это достаточно нудная работа, но без неё программа хорошо выглядеть не будет. Кроме того, стандартные сочетания клавиш ⌘W и ⌘M не будут соответственно закрывать и сворачивать окна. Их придётся так же делать самостоятельно (хорошо хоть ⌘Q работает сразу).

Отмечу некоторые особенности QAction’ов в Mac OS X. Если им задавать шорткаты, то в конструктор QKeySequence надо передавать «Ctrl+M» для создания шортката «⌘M». И вообще, клавиша «⌘» в Qt под мак везде проходит как Ctrl, а клавиша «Ctrl» — как Meta. Для более лёгкой портируемости программ, надо полагать.

Ну и об ограничениях данного подхода к созданию меню.

* нельзя сделать отступ пунктов меню
* QMenu не эмиттит сигнал aboutToHide (только aboutToShow)
* имеет место следующий баг: если меню «Справка» называется «Help», то в нём будет автоматически создан системный блок поиска по пунктам меню, но если он будет назван по-русски, этого не произойдёт, даже если в системе текущая локаль — русская. Как избавиться от этого глюка, я пока не нашёл.

Почти финал — кастомный заголовок окна в Qt

Чтобы применить всё, написанное мной в прошлой статье, к Qt-программе, нужно сделать следующее. Во-первых, ставим где надо retain/release, т.к. не включен ARC. Во-вторых, в Objective-C++ разрешено то, что не удалось сделать в чистом Objective-C: взятие класса, если он объявлен только форвардом:

Это избавляет нас от необходимости иметь хотя бы одно окно в программе перед вызовом данной функции. В остальном всё то же самое, так что копипастить код сюда не буду. Посмотреть это можно в примере (ссылка ниже).

Заключение

Итак, мы рассмотрели Objective-C++ в применении к связке Qt+Cocoa для интеграции программы, написанной на Qt, в среду Mac OS X. По большому счёту, ничего сложного в этом нет, если имеются базовые знания Objective-C и Cocoa. Надо только знать некоторые особенности, на которых я постарался заострить внимание в данной статье.

Если кого интересуют полные исходники тестового проекта, то добро пожаловать на GitHub!

PS: ещё можно было бы рассмотреть встраивание в программу уведомлений через Growl, но это читатель может сделать и сам, если он усвоил материал.

Источник