Как обычно, архивирую совю публикацию на хабре.

Доброго времени суток уважаемый читатель. Продолжаю писать о платформе Maemo (пока еще для Maemo Fremantle). Эта статья посвящена новости в мире Nokia – выход Nokia Qt SDK. Пока еще это TP (Technical Preview, долго силил перевод на русский, не получилось, так что пуст будет “TP” далее по тексту). Но писать на этом уже можно, но есть несколько оговорок. Подробности далее по порядку. Еще я расскажу подробней о MADDE, так как именно эта часть в Nokia Qt SDK отвечает за разработку для Maemo.

Как результат мы напишем приложение (очень громко сказано , вообще так, приложенице ), соберем и запустим его на эмуляторе и на устройстве ( точнее на Nokia N900 ). Да и вообще разберемся что чем и как писать для устройств Nokia сейчас и в будущем.

Первым делом разберемся что к чему. Кто зачем и почему выпустил Nokia Qt SDK.
Так вот Nokia давно готовила этот шаг и вот первый выпуск можно уже опробовать сегодня. И так, встречаем: Nokia Qt SDK.
Официальная информация (там еще две ссылки в этой статье).

Официальное видео(странное вообще).

Click here to view the embedded video.

Теперь резюмирую. Это SDK для разработки под все официально поддерживаемые мобильные платформы с Qt на борту (на данный момент официально поддерживаются Symbian и Maemo 5, что там будет дальше, пока не ясно). Суть в том, что это единый инструмент для разработки мобильных приложений для устройств от Nokia.
Составные части:

1. Сердцем всего является Qt-Creator.
2. Под каждую платформу ставится SDK и toolchain для сборки приложения, упаковки и отладки на устройстве.
3. Qt Simulator – для отладки без наличия устройства.

Звучит вроде здорово. Немного подробностей под каждую из составляющих:
1. Qt Creator:
– специальной сборки
– из коробки настроенная интеграция с целевыми SDK, toolchain’ами и отладчиками.
– встроена поддержка эмулятора
– добавлены шаблоны для мобильных проектов
– очень удивило и порадовало наличие плагина “обновление”, который модульно обновляет SDK (сейчас Qt Creator обновляется только полностью, вышла новая версия – качай полностью и ставь рядом или вместо старой). Надеюсь эта “обновлялка” перекочует и в настольную версию Qt SDK
- поддержка технологии Quick/QML.
- поддержка помошника отладчика на python’е (в чем прелесть, можно посмотреть тут , особенно впечатляет последний пример – отладка отрисовки, все это возможно благодаря макросам на питоне в GDB), правда на устройстве еще нет gdb 7.x (обязательное условие для поддержки макросов питоновских), но будет же
- в нем все еще можно писать и десктопные приложения, это нормальный Qt-Creator

2. SDK+toolchain
– для Symbian – это урезанная версия предыдущего SDK (сильно урезанная, так как я сносил окружение для разработки под Symbian, которое у меня стояло, чтоб попробовать – Symbian SDK+ Carbon + Plugins – занимало у меня около 5 гиг на диске). Все что нужно для сборки и отладке на устройстве.
– для Maemo используется MADDE, он сам по себе еще в бета-тестировании, но позвоялет писать приложения не только под Linux’ом, а также под любыми другими платформами. Этим он лучше нынешнего Fremantle SDK (который пока официальный инстурумент для разработки, и еще минимум пол года будет таковым).
– все намного компактней собратьев и радует что есть “обновлялка”.

3. Qt Simulator
Достаточно интересная штуковина. По сути я ожидал увидеть действительно эмулятор, но ребята схитрили. Это не совсем эмулятор, это “песочница” с отдельным буфером экрана и поведением как у телефона (заряд, координаты, акселерометр, звонки и тд.). Он не эмулирует телефон, он по факту эмулирует Qt Mobility API (который кстати вышел из бета-тестирования и зарелизился недавно )
Вот что он в себя включает:

• Service Framework
• Bearer Management
• Messaging
• Contacts
• Versit
• Publish and Subscribe
• Location
• System Information
• Sensors

Ну и плюс Multimedia, единственная часть, которая осталась в бета состоянии, но все равно достаточно работоспособна.
Задача эмулятора как раз эмулировать поведение всех вот этих API, и работать они все будут одинаково на всех устройствах с поддержкой Qt Mobility API (я в это верю ). Так что если нужно будет реализовать что-то вне этого API – “нативное”, то эмулятор тут не поможет.
Плюс эмулятор поддерживает скриптинг и триггеринг различных системных ситуаций – входящий звонок, садится батарейка и так далее.
Конечно многих это может расстроить, но с другой стороны, более 90% кода при написании мобильного приложения будет использовано именно чистое QT API, все что “вне” прийдется отлаживать на устройстве. Так как Nokia QT SDK – инструмент для кросс-платформенной разработки, то можно предположить, что в эмуляторе можно отлаживать только кросс-платформенный функционал (я верю что такой принцип заложен). С другой стороны эмулятор стал легко переносимый на другие платформы и очень легкий по сравнению с настоящим эмулятором.
Еще одна задача эмулятора – посмотреть как это все будет выглядеть на устройстве (на разных, там в списке есть N95, N97, N900 и призрачный Harmattan (MeeGo) – призрачный потому-что устройства нет, есть только Qt-стиль).
Может это еще заставит разработчика трижды задуматься, прежде чем писать не портируемый код.
Ну в итоге не то что я ожидал, но меня порадовал эмулятор.

Ну вот сжато и сумбурно такое вот описание нового СДК. Теперь плохие новости:

• SDK только для PR 1.2 прошивки, которой еще нет (надеюсь ждать не долго осталось).
• Под Linux доступна только разработка для N900 (используя MADDE).
• Под Mac OS вообще ничего еще нет.

Но так как мы в Вами пока пишем только для N900, то в пролете остаются только пользователи Mac OS (и я в их числе ). Но не расстраивайтесь, MADDE доступно для MAC OS, так что все нормально, просто потребуется немножко больше ручной работы и останемся мы на Mac OS без эмулятора (может как-то можно и его прикрутить, я не пробовал совсем в этом направлении копать, если есть инфа или опыт – пишите).

Таким образом я покажу как установить SDK, написать приложение, собрать его и запустить на эмуляторе. Потом как настроить устройство и запустить на устройстве. Хоть у меня и не получится отладится на устройстве (свалится с SIGFAULT, так как библиотеки на устройстве и в SDK разные), но в скором будущем, когда я обновлю устройство до PR 1.2 это все будет работать (а вообще товарищи производители этих вот библиотек, стыдно должно быть, ибо нужно думать о бинарной совместимости новых версий). Все это под Windows. Под Linux это делается так-же, только сетевой интерфейс настраивается по другому, но я дам ссылку с картинками как это сделать.
А для пользователей Mac OS я покажу как настроить MADDE + Qt Creator чтоб получить такую же связку для разработки. Соберу приложение и запущу его на устройстве (тут оно уже будет работать). Это решение универсальное и будет работать одинаково на всех платформах. Поэтому его можно использовать как альтернативу Nokia Qt SDK, чтоб не тянуть лишнего (например Вам не нежуне ни эмулятор ни Symbian) или чтоб начать отлаживать на устройстве прямо сейчас.

Но обещают официальный релиз к официальному релизу MeeGo, 3-4 квартал 2010, не так долго и ждать осталось.

Ну и сразу официальная ссылка, с кучей информации демок и самим SDK .

1. Nokia Qt SDK на Windows.

Во первых, уточняю, у меня Windows XP SP3 32bit. Я не знаю как это будет работать на других версиях, но если будет различия, то пишите – обсудим. Я даже готов сам разобраться с возможными проблемами на Windows 7 (если они будут), если кто-нибудь подарит мне лицензию .
Вот традиционное видео:

Click here to view the embedded video.

Инструкции:

1. Идем по ссылке http://forum.nokia.com и там находим секцию от SDK или заходим сразу на страницу SDK .
2. Скачиваем SDK под нужную платформу – Windows, Offline-версия.
3. Запускаем установщик.
4. Принимаем лицензионное соглашение.
5. Выбираем путь установки и выбираем “настраиваемую” установку.
6. В списке можете поизучать устанавливаемые компоненты (я убрал исходниые коды от Qt, нужны они только если собираетесь отлаживать само Qt).
7. Жмем кнопку для установки и ждем пару минут.

Поздравляю !! SDK установлен и готов к эксплуатации (не правда ли легко, по сравнению с предыдущими статьями).

Далее пишем приложение:

1. Открываем Qt Creator из состава Nokia Qt SDK. И создаем сессию. Если вы не знаете что это и зачем, то очень советую ознакомиться, ибо без них разработка нескольких проектов превращается в геморрой.
2. Создаем новый мобильный проект (интеграция с Mobility API).
3. Создаем формочку с кнопкой.
4. Делаем приложение. Смысл его в том, что при нажатии на кнопку, текст в строке ввода “переносится” в Label.
5. Собираем для эмулятора с MinGW 4.4, можете меня спросить почему я запустил сборку до того, как написал год. Все просто, я просто хотел чтоб запустился компилятор .ui файлов и сгенерировал мне соответствующий .h файл, чтоб сработала всплывающая подсказка для написания моего кода (до этого подсказывать не по чем, экземпляра класса ui еще нет).
6. Запускаем в эмуляторе и немного там играемся.

Настраиваем окружение на устройстве (пункт 2 этой статьи, я вынес отдельно, так как настройка окружения на устройстве одинакова как для Windows Nokia Qt SDK иак и для “чистого” MADDE).

Отлично, теперь будем отлаживать на устройстве по USB (включим воображение и представим, что PR 1.2 уже вышел и я его уже поставил ).

1. Подключаем N900 в режиме PS Suite по USB.
2. Заходим в сетевые подключения и ищем интерфейс с названием устройства “Linux USB Ethernet/RND….”
3. Устанавливаем на этом интерфейсе статический адрес и сеть (во всех примерах это 192.168.2.14/24).
4. Предполагаю что Вы все настроили уже на устройстве, поэтому пингуем его.(пусть не смущает в видео подсеть 192.168.3.0, я потом перенастроил, так как локальный WiFi у меня был на сети 192.168.2.0).
5. Настраиваем наше устройство в Qt Creator’е. Выбирается авторизация по паролю, если не хочется каждый раз вводить пароль, то моно обменяться ключами. Для этого достаточно иметь сгенерированные ключи и настроить авторизация по паролю и после этого нажать на кнопку “Deploy Key …” и указать публичный ключ. Qt Creator подключится по паролю и заберет публичный ключ с устройства, а на устройство положит Ваш публичный ключ. Если же авторизироваться по паролю, то в этой вкладке нужно будет каждый раз вводить пароль, который сгенерировал mad-developer.
6. Проверям соединение с устройством, нажав на кнопку “Test”, должен вывестись список установленных библиотек Qt на устройстве.
7. На видио пропустил еще один шаг, нуно зайти в “Projects”и посмотреть, чтоб во вкладке “Maemo” был выбран нужный нам рантайм (он у нас один там, называется N900, это то что мы настраивали в предыдущих двух шагах). Если не понятно, подсмотрите в пункте 3, где мы будем настраивать связку Qt Creator+MADDE на Mac OS вручную.
8. Запускаем и все увы не работает, но непременно заработает, когда устройство прошьется до версии PR 1.2.

2. Настройка окружения на телефоне.

Съемка телефона мне дается очень сложно, в данном случае было сложнее, так как подставку я зыбал в Москве и пришлось городить стационарную систему съемок из подручный материалов. Не обращайте внимание на мои трясущиеся руки со стилусом – это не от страха, а от неудобности

А теперь к делу, все что нам нужно – это поставить и освоить пакет mad-developer из “extras” репозитория.

Click here to view the embedded video.

1. Заходим в Диспечер приложений. Нажимаем “загрузить” и заходим в каталог “разработка”.
2. Ищем пакет mad-developer и ставим его (если его нет в списке, проверьте, может он уже стоит и проверьте подключен ли у Вас репозиторий extras).
3. Запускаем mad-developer.
4. Настраиваем сетевой интерфейс USB (вводим статический аддресии – в моем случае 192.168.3.15, так как вторая подсетка уже занята).
5. При разработке из-под Windows необходимо вручную загрузить USB модуль g_ether, на Mac OS и Linux это не нужно, у Вас сетевые интерфейсы поднимутся и так.
6. Доступна консоль разработчика (зачем она, не совсем понятно).
7. Самое главное – это кнопка генерации пароля, пока пароль видно на экране – он действителен, как только нажмете кнопку “close” – подключиться к устройству по паролю вы уже не сможете.

Рабочее состояние приложения такое – открываете mad-developer и открываете окно с паролем, запускаете Qt Creator и заходите во вкладку настройки Maemo устройства и вводите этот пароль. После этого можно отлаживаться на устройстве. Если обменяться ключами как указано в предыдущей главе, то этого всего не нужно.

3. Настрйка связки Qt Creator + MADDE на Mac OS.

По большому счету, если Вам не нужен эмулятор, то даже на Windows и автообновление SDK, то можно воспользоваться этим путем вместо SDK. По сути для Maemo разработки Nokia Qt SDK и MADDE не просто синонимы, а одно и то-же. Так что если не собираетесь писать под Symbian и не нужен эмулятор, то советую использовать чистый MADDE в целях экономии места.

Тем не менее, на текущий момент Nokia Qt SDK нет для Mac OS, именно поэтому я и решил продемонстрировать установку MADDE+QtCreator.
Вот видео:

Click here to view the embedded video.

Плюс видео как добавить Madde’шный qmake в Qt-Creator(забыл включить в первое видео):

Click here to view the embedded video.

Тут все просто.

1. Скачиваем MADDE скрипт-установщик и запускаем его.
2. Скачиваем и ставим последний Qt Creator (либо последний “снимок” отсюда либо качаем последний официальный релиз 2.0 beta отсюда (там внизу страницы ссылки на сборки для разных ОС)).
3. Настраиваем mad-developer на N900 (предыдущая глава).
4. Настраиваем Qt-creator, добавляем Qt из MADDE пакета.
5. Настраиваем среду запуска на устройстве.
6. Пишем собственно приложение.
7. Запускаем и отлаживаем его на компьютере.
8. Запускаем и отлаживаем его на устройстве.

Хоть все и просто, но есть пару нюансов.

• В qmake.conf в MADDE не прописан флаг “-g” для gcc, при сборке приложения в режиме отладки. Поэтому в файл .pro нужно добавить такую вот строчку:
• QMAKE_CXXFLAGS_DEBUG+=-g
• эта переманная – флаги для gcc, при сборке в режиме отладки.
• Нужно “вручную” добавить qmake, который нужен для сборки приложения для запуска на устройстве.
• Необходимо пересобрать (помощник отладчика).

4. Отладка, live video.

Ну вот привожу еще одно видео, как выглядел последний параграф моими глазами. Весь процесс запуска и отладки на устройстве.

Click here to view the embedded video.

Заключение.

В итоге могу сказать Bravo!, компании Nokia. Все сделано очень дельно и хорошо, даже учитывая, что это beta, все равно разрабатывать приложения даже для коммерческого проекта можно.
Процесс установки и настройки очень простой. Разработка для мобильный и настольных приложений ведется одними инструментами. Qt Mobility API принес возможность абстрагироваться от уровня мобильной ОС до уровня “коммуникатор”.
Статья я надеюсь скоро устареет, но принципы заложенные в бета версию продуктов не должны изменится. По сути нужно будет делать то-же самое, только в файлах-установщиках будут другие версии.

Вот в принципе можно считать цикл статей на тему “как поставить и настроить чтоб можно было написать программку” я считаю завершенной. В следующих статьях мы наконец-то начнем писать приложение, приложение будет надеюсь интересное и полезное, но то что оно будет охватывать практически все темы (не глубоко, но достаточно для понимания куда копать дальше, в случае чего) – это я обещаю.

Всем удачного коддинга/хаккинга.

UPD: баги конечно есть, это первый официальный выпуск (хоть и бета). Так что те кому это интересно и кто нашел ошибки, имеет вопросы или просто хочет узнать больше вот необходимые ссылки:
Официальная WiKi страничка.
Официальная страница проекта.
Руководство по “быстрому старту”.
Форум, посвященный инструментам, входящим в состав этоко SDK.

Ну и конечно Qt bug-tracker.

Продолжаю цикл статей по программированию для Maemo.

Некоторым показалось, что начать программировать для Maemo тяжело. Именно поэтому я решил начать с демонстрации легкого пути “Easy way” (c), чтоб показать как легко начать. Далее, учитывая выход официального релиза t 4.6.2 для maemo 5, я покажу как поставить этот релиз на Fremantle SDK. Продемонстрирую отладку в эмуляторе. И самое главное, как отлаживать приложение на устройстве используя обычное сетевое подключение и подключение по USB.

Результатом нашего труда будет вот такое вот окошечко на устройстве:

Примечание: в качестве IDE используется Scratchbox, так как речь идет о Fremantle SDK. QtQreator можно использовать, но как таковой поддержки Fremantle в нем нет и не будет. Почему ? Да потому-что в нем делают поддержку нового, кросс-платформенного SDK – MADDE, о котором я уже упоминал (и упомяну еще в заключении).

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

1. Установка SDK и запуск HelloWorld в эмуляторе.

Все видео здесь не очень хорошего качества, на YouTube’e можно посмотреть их в HD формате, для этого достаточно два раза кликнуть по видео.

Начнем с начала, в данной точке предположим, что предыдущую статью вы либо не читали, либо решили не проходить тернистый немножко длинный путь по установке SDK. Но если бы вы прошли по первому пути, то в качестве приза результата Вы получили бы удобную среду для разработки в родной ОС (лично мое мнение конечно).
Но если Вы ленивый по каким-либо причинам Вам не подходит описанный мной вариант, предлагаю другой, более легкий и простой.

Если у Вас уже стоит Fremantle SDK, то можете пропустить этот шаг и перейти сразу ко второму шагу.

Для установки SDK необходимо скачать:

1. Fremantle SDK Virtual Image – файл по имени Maemo_Ubuntu_Intrepid_Desktop_SDK_Virtual_Image_Final.7z.
2. опционально 7ip архиватор, если у вас его нет (берите любой).
3. VirtualBox или quemu или VMWare. В моем примере я использую VirtualBox.

и далее действуем согласно видео, там вроде все наглядно:

Click here to view the embedded video.

Заметки: устанавливайте дополнения гостевой ОС непосредственно из самого VirtualBox, а не те, которые включены в сам SDK (ссылка на них на рабочем столе). Их нигде качать не нужно, они уже идут с самим VirtualBox и дистрибутив подключается как виртуальный образ диска.

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

2. Установка Qt 4.6.2, и создание и запуск Qt приложения в эмуляторе.

С этого момента не важно, используете вы способ установки предложенный из предыдущей статьи или же из пункта 1. Всё актуально для обоих случаев установки.

Click here to view the embedded video.

тут последовательность такова:

Сначала мы удаляем установленный в SDK Qt 4.5.

fakeroot apt-get remove libqtv4*

и затем установить официальный Qt 4.6.2 для Maemo5:

fakeroot apt-get install libqt4-maemo5-dev

Причем сделать это нужно для обоих целей ARMEL и x86. Цель x86 нужна для запуска и отладки в эмуляторе, а цель ARMEL для запуска и отладки на устройстве (кросскомпиляция). Переключаться между целями в scratchbox можно с помощью меню:

sb-menu

Теперь внимание!!!! Сеть в scratchbox может не работать (при запуске команды для установки пакетов могут быть ошибки с сетью). Это связано с небольшими проблемами в scratchbox. Их легко устранить. Для этого вне scratchbox нужно скопировать для каждой цели и для самого scratchbox файлик resolv.conf, который вы получили по DHCP либо сформировали в процессе настройки статической сети (явно или косвенно через утилиты):

sudo cp /etc/resolv.conf /scratchbox/etc
sudo cp /etc/resolv.conf /scratchbox/users/maemo/targets/FREMANTLE_ARMEL/etc
sudo cp /etc/resolv.conf /scratchbox/users/maemo/targets/FREMANTLE_X86/etc

Еще имейте ввиду, что в случае использования прокси, Вам нужно экспортировать переменные окружения:

export http_proxy=…
export https_proxy=…

Это можно вынести в отдельный скрипт или добавить эти строки в ~/.bashrc файл или указать proxy для apt-get:

 echo 'Acquire::http::Proxy "http://aptcache:3142";' > /etc/apt/apt.conf.d/99proxy

В этом случае apt-get будет работать через этот proxy.

также перед установкой пакетов Qt будет не лишним обновить пакеты для каждой цели в scratchbox (вообще все команды, начинающиеся с “fakeroot” выполняются только внутри scratchbox, а sudo вне его):

fakeroot apt-get update

После этого создаем проект Qt – “Qt Hello World” и в качестве конфигураций сборки выбираем все цели для ARMEL и X86 (ведь мы планируем отлаживать как в эмуляторе так и на устройстве).

3. Настройка и запуск приложения в локальном эмуляторе и на на устройстве через сеть (по WiFi в моем случае).

Click here to view the embedded video.

ln -s /opt/qt4-maemo5/bin/qmake /usr/local/bin

проверяем, что qmake доступен без указания пути:

qmake

должна появиться подсказка для qmake, и в начале указан версия Qt, должна быть 4.6.2

для include:

ln -s /opt/qt4-maemo5/include /usr/local/qt4

это нужно для ESBox.

Проделать эту операцию нужно для каждой цели сборки scratchbox (ARMEL и X86), чтоб не оказалось, что в терминале вы отлаживаетесь с одной версией Qt, а на устройстве с другой . Вы помните, что для переключения цели в scratchbox нужно воспользоваться утилиткой “sb-menu”.

Потом собираем наше приложение для эмулятора (X86-develop) и создаем конфигурацию отладки (локальную). Запускаем, соглашаемся на приглашение запустить эмулятор. Вы увидите что программа остановилась на точке входа в “main” функцию и заработал HelloWorld. Все работает хорошо. Ура!!!

Теперь запустим отладку на устройстве. Сначала я решил продемонстрировать отладку по сети. Все что для этого нужно – это установить gdb сервер на устройстве (для отладки) и ssh server (и клиент тоже не помешает).
Open SSH клиент и сервер можно установить с помощью этого метапакета: http://maemo.org/downloads/product/Maemo5/openssh/. Находятся он в репозитории http://repository.maemo.org/extras/. Как установить новый репозиторий вы можете подсмотреть в моей статье. Также можно зайти по ссылке на приложение и нажать кнопку “Install” прям на устройстве.

Установить gdb можно из репозиториев maemo прям на устройстве, находится он в репозиториях

deb http://repository.maemo.org/ fremantle/sdk free non-free
deb http://repository.maemo.org/ fremantle/tools free non-free

Просто добавьте эти строки в файл /etc/apt/sources.list на устройстве (или через стандартный менеджер пакетов), для этого надо быть суперпользователем, чтоб перейти в этот режим на устройстве нужно ввести команду:

sudo gainroot

и потом ввести:

apt-get update
apt-get install gdb

Все это можно сделать через ssh, не обязательно писать это все руками на клавиатурке .

Второй путь – это вручную скачать пакет gdb и поставить его с помощью dpkg (я сделал именно так).
Заходим и скачиваем на устройство по этой ссылке пакет. И сохраните на устройстве. Потому в консоли (опять же можно по ssh) зайдите туда и введите:

dpkg -i gdb_6.8.50.20090417-0maemo2+0m5_armel.deb

В scratchbox GDB уже стоит.

В настройках ESBox создаем устройство и прописываем IP N900 в качестве “Host Name”. Создаем конфигурацию запуска на удаленном хосте (в нашем случае это N900) выставляем способ доставки приложения SSH.
Есть два вариант – SBRSH и SSH.
SBRSH – это когда устройство монтируем папку с приложением у себя в файловой системе и с этого места запускает. Плюс: быстрее все происходит. Минус: устройство должно видеть ваш компьютер (для виртуальной системы должен стоять режим Bridge а не NAT или же перебросить порты) и на SDK-хосте должен стоять SSH сервер.
SSH – проект копируется по SCP на N900 и оттуда запускается. Плюс: виртуальная машина может быть в режиме Bridge. Минус: немного медленнее.
Я выбрал второй вариант, но вы можете выбирать сами, настройки там не сильно отличаются (правда в видео я сначала создал SBRSH, но потом поменял на SSH).
В качестве “Remote Connection”, удаленного соединения, выбираем ранее настроенное устройство и запускаем на отладку.

При старте попросят ввести пароль для пользователя user. (Пароль “maemo”). Лучше кликнуть чекбокс “Save password”, а то он много раз будет спрашивать пароль, напрягает

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

4. Настройка и запуск приложения на устройстве через USB соединение.

Недостаток отладки по сети: медленно. Но на помощь на придет USB соединение. По факту это тоже отладка по сети, так как создается сетевой интерфейс по USB, через который и отлаживается приложение. Но так, как он по факту “точка-точка”, то за счет этого и быстрее происходит.

Подготовка: необходимо поставить пакет pc-connectivity на устройстве, на виртуалке она уже стоит. Находится она в репозитории Extras. Очень мощный инструмент, унаследованный с предыдущих версий Maemo. Вкратце: он позволяет создавать профили соединений, для каждого профиля можно отдельно настроить соединения по USB, Wifi и Bluetooth. Да, отлаживаться можно и по bluetooth, но я не пробовал. Отладка по Wifi создает точку доступа с DHCP сервером. Полную документацию можно найти тут. Но не пугайтесь очень большим объемом документации. В нашем случае ее читать не обязательно .

Click here to view the embedded video.

После этого проверяем соединение – заходим на устройство по SSH.
Ну и все что осталось – это создать конфигурацию отладки для этого соединения и запустить непосредственно на устройстве.

Заключение.

Как вы можете видеть, все очень просто. Начать писать для Maemo5, имея при себе устройство или нет, не составляет особого труда. Но лично мне не нравиться, что я не могу использовать Qt-creator. Конечно можно код править даже на расшареных папках между виртуальной машиной и хостом, а потом руками все это запускать либо в эмуляторе или на устройстве и уже отлаживать в Gdb руками, или использовать ESBox. Но я уже сильно привык к Qt-Creator’у.
Но решение есть – MADDE. Это совсем другая SDK и официальной поддержки еще нет (находится в Developer Preview) и в Qt-Creator’е нет поддержки MADDE (в официальном релизе), но все это обещают к релизу версии Qt 4.7. Но тем не менее, этим всем можно пользоваться прямо сейчас (используя main ветку из git-репозитория или использую последние “снимки”), причем на любой ОС без использования виртуальных машин. Qt-Creator в Gitorious в master ветке уже достаточно неплохо работает с MADDE. Сейчас в MADDE не хватает двух основных вещей – эмулятора и обновления пакетов. Если у вас есть устройство, на котором вы хотите отлаживаться и готовы устанавливать нужные пакеты руками, то MADDE вам подойдет.
В следующей статье для разработчиков я опишу процесс настройки и работы с MADDE.

Всем приятного коддинга

Уже нет смысла, я думаю, объяснять что такое Maemo и где он работает. Всем понятно, что это Linux, который сейчас работает на таблетках от Nokia и на новом Nokia N900. Но так как проект open-source, то думаю другим производителям ничто не мешает сделать свое устройство под этой платформой (кто знает, может появится HTC или Motorolla на базе Maemo).

Речь в этой статье пойдет о том как настроить окружение для разработки для Maemo.

Начнем с того, что сейчас существуют два типа SDK – текущий стабильный для Maemo5/4 (Fremantle/Diablo) и новый SDK, который сейчас в бете – MADDE.

Ну давайте начнем со стабильного (относительно и спорно, позже покажу почему) и текущего – Fremantle (на момент написания статьи но был “pre-final 2″, теперь в “final”). Он базируется на Diablo и поэтому процесс установки и нструменты те же. И если вам нужен Diablo – инструкция подойдет эта, а далее я буду говорить только о Fremantle, подозревая что по желанию можно использовать Diablo.

Хорошо, предположим, что мы выбрали SDK Fremantle (MADDE я посвящу последующие статьи). У этого SDK есть один недостаток – он моно-платформенный. Он работает только под Linux x86 (желательно debian based, но не обязательно). Для счастливый пользователей этой системы существует простой путь для установки SDK нужно скачать скрипт с этой страницы и действовать согласно этой инструкции.

Что же делать, если рабочая система у нас Windows(самая популярная)/Linux x64/MacOs? Не отчаивайтесь. У вас и тут есть выбор. Самый легкий путь – это скачать отсюда виртуальный образ с настроенным окружением и в нем работать. Все предельно просто – качаем, запускаем из-под VMWare, QEMU, VirtualBox. Там уже стоит ESBox и SDK. Если вы не знаете как установить систему в виртуальной машине, можно подсмотреть в этой статье далее.

Ну и последний вариант – если Вы хотите разрабатывать приложения на своей родной платформе – нет проблем! ESBox (забыл представить – это Eclipse+плагины для разработки под Maemo5/4) умеет работать с виртуальной машиной. То есть получается, что вы пишите код в ESBox, он собирает это в виртуальной машине и запускает там, а результат отображается опять же в вашей родной системе. Виртуальная система работает “в тени”. Идея прекрасна, не правда ли?

На деле все не так гладко в Windows, под Mac OS и Linux все работает как надо (надеюсь в скором будущем для Windows все отмеченные мною баги будут исправленны). Я столкнулся с несколькими неприятными моментами, плюс часть документации, которую можно найти в разных местах создана не Нокиа, а open source community и иногда встречаются неточности и несоответствия версий

Вот в этой статье далее пойдет речь о том как установить Maemo SDK под Windows (будут замечания, если процесс будет отличатся от Linux, Mac OS вариантов) и более того, я при вас это сделаю менее чем за пол часа. Всё видео и нотации к ним под катом.

Да кстати, это все можно установить не только для разработки, но и для того чтобы познакомится с Maemo не имея реального устройства.

Некоторым кажется, что процесс утсановки сложен и много букв. В действительности не так, просто я постарался описать как можно подробней. В действительности достаточно посмотреть видео, и если что-то непонятно – прочитать описание к этому видео.

UPD:На момент написания статьи образ виртуально системы был “PreFinal2″, несколько дней назад вышла версия Final. Но инструкция остается полностью актуальна, так как для данного вида установки ничего не изменилось. Поменялось лишь содержимое образа виртуальной системы, с настроенным окружением maemo.

Порядок руководства такой: сначала видео, потом пояснения к нему и ссылки. Так что не надо их все запоминать, я их приведу после видео (советую смотреть в HD, ссылку привожу перед видео, как добавить HD-видео сразу сюда – не нашел).

Итак шаг первы: установка и первичная настройка виртуальной машины:

Сслыка на HD YouTube версию.

Click here to view the embedded video.

Ubuntu Server 8.10 Intrepid Ibex
Maemo Host PC Connectivity release without GUI applications
Installation wizards for virtualization performance tools
Installer for Official VMWare Tools
Installer for Open VMWare Tools
Installer for VirtuaBox GuestAdditions

Плюс там установлены некоторые патчи.

Далее заходим на сайт VirtualBox и в секции Download скачиваем установщик под Вашу платформу. Ну и соответственно устанавливаем его со всеми параметрами по умолчанию (осторожно: во время установки VirtualBox отвалятся на время сетевые интерфейсы).

Потом распаковываем скачанный виртуальный образ Ubuntu в удобное для вас место (zip формат поддерживается всеми ОС прям “из коробки”).

Запускаем VirtualBox и создаем новую виртуальную машину, в качестве диска подключаем только что скачанный образ.

Запускаем виртуальную машину: логин и пароль: maemo.

запускаем инструмент ~/install_guest_additions_server.sh командой:

sudo /home/maemo/ToolsInstallers/install_guest_additions_server.sh

Далее отвечаем на все вопросы положительно и принимаем все лицензионные соглашения.
После завершения процесса установки перезагружаем виртуальную машину командой:

sudo reboot

Шаг второй: установка и настройка ESbox+SDK для работы с виртуальной машиной.

Ссылка на HD версию на YouTube.

Click here to view the embedded video.

Заходим в настройки виртуальной машины и в секции “Сеть” меняем тип сетевого подключения с “NAT” на “Сетевой мост”.
Вообще, нужно организовать кросс-шару между хост-системой и виртуальной системой. Схема шары такова:

Мы маунтим workspace ESbox’a (на схеме – это “C:\maemo\shared”) на соответствующие папки на виртуальной машине, для того, чтобы SDK мог добраться до них для компиляции и запуска из виртуальной системы. Шара организована через smb-протокол.

Но для комфортной работы можно еще сделать обратную шару из виртуальной машины на хост машину, чтобы подключить заголовочные файлы из SDK и таким образом можно было их видеть из ESBox и задействовать автозавершение. Это не обязательно, но удобно.

Если будет сетевое подключение через NAT на виртуальной машине, то придется делать перенаправление 22 порта, поэтому проще сделать “Bridge” сеть, таким образом виртуальная машина появится в сети как отдельный экземпляр. Это даст возможность по сети с другого компа вести разработку (например повесить жене на компьютер этот виртуальный образ, а самому на буке кодить, зачем мощностям простаивать или удаленно работать с виртуальной машиной (вариантов много)).

НО стоит учесть один момент. Сеть может такое не позволить или если рутер не сильно умный, то передача данных между хостом и виртуальной машиной может спокойно идти через интернет (через провайдера) – даже при небольшом трафике в таком случае могут быть жуткие тормоза. Поэтому не отбрасываю и вариант использования NAT Networking, инструкция по настройке перенаправлению портов можно найти здесь.

Далее необходимо скачать ESbox с этого сайта..
Необходимо скачать два файла:

esbox_2.0.0-R20091216-common.zip
esbox_2.0.0-R20091216-win32.win32.x86.zip – для Windows (или соответсвующий для вашей платформы).

R20091216 – номер доступной версии на момент написания статьи, естественно нужно качать последнюю.

Первый архив – это плагины и фичи, а второй платформо-зависимые файлы (выполняемые и сопутствующие).
Распаковываем оба файла в одну и ту же папку ( если например распаковать в C:\, то программа будет находиться в C:\ESBox), архив zip поддерживается всеми платформами без сторонних продуктов.

Запускаем распакованный ESBox и приступим к его первичной настройке.
Сначала нас спросят, где находится наше рабочее пространство (workspace). Рекомендую указать C:\maemo\shared. (В видео выбран неправильный каталог, но в субтитрах написан правильный путь, я позже за кадром поменял путь к workspace’у).
Ставим галочку, сообщая что это рабочее пространство по умолчанию, и больше не нужно спрашивать при запуске о его размещение.

Далее подключаем справку (не обязательно).
Сначала подключается on-line репозиторий справки, параметры при заполнении:

Name: Maemo Docs Libraray
Host: library.maemodocs.nokia.com
Path: /fremantle

Так же по желанию можно установить off-line помощь.
Для этого добавляем новый репозиторий:

Location: http://maemoide.nokia.com/downloads/fremantle

Выбираем нужные пакеты (в моем случае все), принимаем лицензионное соглашение и устанавливаем.

После этого закрываем ESBox.

Следующее действие только для пользователей Windows – установка X-server. Под Mac OS сервер идет “из коробки” и работает нормально (проверял). Для Linux необходимо установить Xephyr:

sudo apt-get install xserver-xephyr

Под Windows у вас есть выбор между XServer’ами. Разработчики Maemo SDK предлагают Cygwin/X, я предлагаю XMing. Оба работают одинаково (одинаково неправильно, смотри следующую главу).

Чтобы установить Cygwin/X, необходимо зайти на сайт http://cygwin.org и скачать файл по этой ссылке.

После этого запускаем инсталятор и добавляем три пакета: X11/xorg-server, X11/xinit, X11/xdpyinfo.
Внимание для пользователей Windows 7. Cygwin/X версии 1.7 падает из-за бага. Он связан с composition расширением (об этом подробней в четвертой шаге).

Чтоб установить XMing, скачайте установщик с sourceforge.net. Запустите установщик и действуйте согласно инструкции (я оставил все параметры по умолчанию).

Как по мне, так XMing установить проще и быстрее.

Далее необходимо настроить виртуальную машину, идем в настройки ESbox->Build Machines и выбираем в списке виртуальных машин VirtualBox.

В первой вкладке нужно изменить путь к выполняемому файлу Virtual Box (убираем лишние символы “xVM “, если вы установили все по умолчанию, как я) и выбираем из списка нашу виртуальную машину.
Во второй вкладке настраиваем сетевые интерфейсы.
Для этого запускаем виртуальную машину и заходим на нее: логин/пароль – maemo/maemo.
набираем команду:

ifconfig

Команда выведет нам адрес виртуальной машины, а в выпадающем списке интерфейсов для хост машины, выбираем соответствующий IP адрес.
И обязательно нажимаем кнопочку “Apply”.
Далее щелкаем по ссылке сверху “Click here for maemo installers”.
Сначала устанавливаем Scratchbox.
Выбираем целевую платформу (Fremantle или Diablo). Соглашаемся на предложенный патч autoconfs’a,и перезагружаем виртуальную машину.

Опять щелкаем по этой ссылке и устанавливаем цели для Scratchbox (соответственно Fremantle или Diablo).
Тут необходимо принять лицензионное соглашение.
После установки целей будет предложено установить комерческие(закрытые) двоичные файлы от Nokia.
Это необходимый шаг для Fremantle.
Тут хитрое лицензионное соглашение, необходимо перейти по ссылке сверху, прочитать в броузере лицензионное соглашение, ввести код проверки и получить путь на deb-репозиторий. Вот этот путь нужно скопировать и ввести в соответствующее поле инсталятора.
После этого уже устанавливаются нужные пакеты.

Настройки сетевых ресурсов пока не трогаем, с этого мы начнем в следующей главе.

Шаг третий: окончание настройки и попытка собрать и отладить первое приложение.

Внимание: следующее видео предполагает, что вы сделали сетевой доступ к папке C:/maemo/shared и дали локальному пользователю права на изменение файлов.
Сетевой ресурс должен быть организован по протоколу Samba. Как это сделать на Windows/Linux/Mac Os вы можете легко найти в гугле.
Ссылка на HD версию на YouTube.

Click here to view the embedded video.

Заходим в настройки виртуальной машины во вкладку “Shared Folders” (смотри схемку выше). Проверяем пути и нажимаем кнопочку “Validate Machine”.
ESbox попробует смонтировать C:\Maemo\shared в соответствующие каталоги на виртуальной машине и спросит имя пользователя и пароль для подключения (он их запомнит и больше спрашивать не будет).
Вот Mac OS и Linux все должно пройти без ошибок.
На Windows он выдаст сообщение, что все смонтировалось хорошо, но недоступно. Игнорируем это сообщение. Ну и потом выскочит исключение. Баг номер 1. Не обращаем на это внимание, просто проверим, что в Windows появилось два диска T и S (или другие, если вы изменили настройки).

Дальше создаем новый проект Maemo C++ -> Hello World.
ESbox попросит проверить установленные зависимости. Если вы запускаете первый раз, то он поставит несколько пакетов (у меня уже стоит).

Запускаем среду maemo, нажав на кнопочку с логотипом maemo. Будет предложено убрать не поддерживаемые параметры для запуска X-server (я пробовал ни на что они не влияют, но лучше согласиться ).
Если вы установили XMing по моей рекомендации, у вас ничего не запустится, то ничего страшного. Все равно работать оно как надо не будет, просто посмотрите видео. А инструкции по настройке ESbox для работы c XMing читайте в следующей главе.

На видео там куча значков сбилась в левом углу (у меня уже установлены виджеты), у вас будет только значок твиттера. Нажав на него снизу будет полоса прокрутки (это броузер запустится).
Это баг номер 2, как его обойти я опишу в следующей главе. Этот баг проявляется только под Windows, на Linux и Mac OS у вас все красиво должно отображаться (если нет, то смотри в конце этого шага).

Как вы видите, оконный менеджер не работает как нужно. Приложение “погода” показывается без заголовка.

Выключаем среду Maemo и закрываем руками X-server(еще один баг, ESBox не может закрыть X-server).

Теперь пытаемся собрать приложение, в качестве цели используем выбранный FREMANTLE_X86(Debug). И опс, ничего не происходит. У нас ошибка в консоли (не может найти скрипт) и исключение плагина (еще баг).
Не переживайте. Просто нужно выбрать другую цель сборки и все заработает, после этого будет собираться и цель, которая не собиралась. Я думаю это связано с тем, что не инициализируются какие-то начальные значения, а при переключении целей они заполняются.
После долгой отработки autoconf’a мы готовы запустить наше приложение.

Стартуем среду Maemo и запускаем в режиме отладки наше приложение.
Приложение остановится в точке останова, значит gdb работает как надо, но после выполнения на экране черным-черно. Так и должно быть. Это приложение имеет только один элемент управления в заголовке окна, но так как заголовков у нас нет(не запустился оконный менеджер, но об этом позже), то его не видно.

Для пользователей Mac OS и Linux все должно уже работать и правильно отображаться. Если у вас отображается также, то проверьте, чтоб не стояло опции -extension Composite при запуске X-server. Эта опция была в Diablo, а в Fremantle она не нужна.

Шаг четвертый, окончательный: настройка XMing, обходим баги и отлаживаем наше приложение.

Ссылка на HD версию на YouTube.

Click here to view the embedded video.

Сначала инструкция для тех, кто меня послушал и поставил XMing.
Заходим в настройки ESbox->X Server и меняем значения:

Command template to launch server: “C:\\Program Files\\XMing\\XMing.exe”
Additional PAth entries for server: “”C:\\Program Files\\XMing”

Теперь для всех видов иксов нужно дописать такие параметры:

+extension Composite +extension “Generic Events”

Запустим, должен запустится XMing.

Поставьте на паузу видео и послушайте немножко мои рассуждения.

Теперь разберемся, почему не отображается все правильно.
С Cygwin/X есть проблема, что matchbox (оконный менеджер на maemo) не может распознать, что установлено расширение composite на X-server. И не запускается. Результат – сбившиеся иконки и нет заголовков и всего прочего. Баг этот известен, но немного другой. Суть такова, что нужно проверить поддержку Cygwin 1.7 с Fremantle SDK.

Вроде написано ,что вместо Cygwin 1.7 лучше использовать версию 1.5.25-15. Но старые версии Cygwin нельзя установить официальным установщиком (самая старая версия Xorg-server в официальном репозитории – xorg-server-1.6.5-1), а найти и скачать по быстрому у меня не удалось. Да и не факт что это решит проблему (описано было в багах падение, а не отсутствие поддержки composite extension). Если кто попробует, отпишитесь пожалуйста об успехах.

Второй вариант – это XMing. Тут у нас не поддерживается Generic Events (XGE) и он вообще падает с включенным расширением Composition. Без ошибок, просто молча падает. Дебажить его нет желания, тем более, что разработка его ушла уже очень далеко вперед, и судя по анонсам, в версии 7.5.0.14 это уже поправлено (последняя версия 7.5.0.16). Может и проблему с Composite Extension тоже поправили. Но в публичный доступ выкладываются версии с большим опозданием(сейчас лежит версия 6.9.0.31), и чтобы получить доступ к последним версиям, нужно получить донорский код (для этого нужно внести пожертвование в проект). Если бы я пользовался X сервером под Windows, то обязательно бы это сделал. Но моя основная платформа – Mac Os. Опять же, если у кого появится возможность проверить на последнем XMing – отпишитесь, очень интересно.
Да ,кстати, в XMing можно добавить опцию -clipboard, чтоб задействовать буфер обмена.
Ну а теперь как же сделать, чтоб все работало.

Схема такая. Среда Maemo, запускается на виртуальной машине, но экран она должна использовать не тот, который ему передаст ESBox, а локальный. Локально будет запущен Xephyr (этот X-server, который встраивается в другой XServer (вложены, nested)). Экраном для XServer будет уже XMing/Cygwin. Получается между maemo средой и виндовым XServer теперь вставляем Xephyr на виртуальной машине.

Сделать это достаточно несложно.
Теперь отпустите паузу с видео, поехали дальше настраивать.

Заходим на виртуальную машину и устанавливаем Xephyr:

sudo apt-get install xserver-xephyr

Потом создаем скрипт для его запуска:

touch ./start1.sh
chmod a+x ./start1.sh
vim ./start1.sh

Естественно вместо vim можете использовать другой редактор: nano, mcedit.

Содержание скрипта будет выглядеть таким образом:

#!/bin/bash
export DISPLAY=192.168.1.152:2
Xephyr :2 -host-cursor -screen 800x600x16 -dpi 96 -ac -kb

Вместо 192.168.1.152 – укажите айпишник Вашей хост машины.
И запускаем скрипт, он должен выругаться, что не может подключится к экрану.
Запускаем XServer из-под ESbox и запускаем скрипт снова.
Должен появится вывод как у меня в консоль.
Чтоб завершить работу Xephyr, нажмите Ctr+C (для переключения между консолями в виртуальной машине, используйте комбинацию Alt+<стрелка врпаво/влево>).

Теперь нам нужно поправить зайти в scratchbox и поправить там скрипт запуска среды maemo, чтоб он отображался в локальном Xephyr-сервера, а не в нашем Xming.

/scratchbox/login
vim /usr/bin/af-sb-init.sh

в начале добавляем такую строку

export DISPLAY=127.0.0.1:2

Ну теперь запускаем Xming на Windows, запускаем наш скрипт для Xephyr на виртуальной машине и запускаем среду Maemo из ESbox.

Вот у нас почти рабочая Maemo (некоторые приложения все же не запустились, например браузер и аудиоплеер).

Теперь давайте запусти наш helloworld в режиме отладки, тут тоже немножко нужно изменить параметры. В переменные окружения нужно добавить такую строку:

DISPLAY=127.0.0.1:2

Для того, чтоб наше приложение тоже отображалось в Xephyr а не на XMing.
Как вы видите все работает как надо.

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

Заключение.

Поздравляю Вас, если вы дошли до заключения.
Конечно мы получили не идеальное окружение, но оно работает.
Из основных недостатков:
при компиляции используется мощность виртуальной машины, а не полная мощность всего компьютера
отображение не так красиво и быстро работает, как должно
достаточно сложно настроить (общее время на видео 25 минут, но оно не учитывает время на загрузку пакетов)
среда Eclipse(ESBox) сама по себе не лишена недостатков (скорость, память, ошибки)

Но есть альтернатива – это MADDE. Эта SDK еще находится в разработке, но ее уже можно использовать.
Она кросс-платформенная. Требует минимум установки и существует поддержка этого SDK в Qt-creator’e (но пока экспериментально). На сегодняшний момент на MADDE можно писать приложения, но только имея реальное устройство. О том как установить и пользоваться MADDE я расскажу в последующих статьях.

В следующей статье я расскажу как написать Qt-приложени и собрать пакет, чтоб другие могли его установить.

Также жду ваших советов и соображений по поводу решения проблемы с XMing и Cygwin/X.

Приятного вам знакомства с Maemo.

In previous post I wrote how to create plugins for Qt-creator. In this mini post I’d like to share one more helpful information about Qt-creator.
Good guys form KDAB created and shared Qt Creator reference card. This nice reference card helps you to easily adapt to new IDE.

Links for download:
Qt Creator Reference Card – A4
Qt Creator Reference Card – US Letter
Qt Creator Reference Card Mac – A4
Qt Creator Reference Card Mac – US Letter

qtcreator reference card

I wish you a fan development with Qt-creator.

В предыдущем посте я отписался о том как создавать свои плагины для Qt-creator. В этом мини посте хочу продолжить тему и поделится находкой.
Хорошие ребята из KDAB создали и выложили Qt Creator reference card. Шпаргалка по IDE, которая поможет очень быстро адаптироваться к новой среде.

Ссылки для скачивания:
Qt Creator Reference Card – A4
Qt Creator Reference Card – US Letter
Qt Creator Reference Card Mac – A4
Qt Creator Reference Card Mac – US Letter

qtcreator reference card

Всем приятной работы в Qt-creator’e.

Qt-creator is rather new and extremely dynamic growing project. The main benefits: cross-platform, suitable, fast and scalable.

It’s a link to official page of project.
Small video preview:

Click here to view the embedded video.

But the main benefit, is that it open source. You can download it and look inside or maybe improve. Also you can become a contributor of Qt-Creator, more info on Gitorious’s project page..

Guys from vcreatelogic wrote the good manual about writing plugins for Qt-creator. This manual is very simple, organised step-by-step. There are a lot of pictures an examples. I hope to see more manuals like this.
Vcreatelogiс site – http://www.vcreatelogic.com/, and the link to download the manual – http://www.vcreatelogic.com/resources/downloads. You need to click on “Other Downloads” tab, following this link.

You can preview this document in this window:

Qt-creator это очень динамически развивающийся проект. Он кросс-платформенный, удобный, быстрый и хорошо настраиваемый.

Вот ссылка на официальную страницу проекта.
Небольшое видео превью:

Click here to view the embedded video.

Но самое главное, что проект является Open Source. Вы можете скачать исходники и посмотреть что там внутри. Также вы можете принять участие в разработке самого проекта на Gitorious.

Товарищи из vcreatelogic написали очень хороший документ по написанию плагинов для Qt-Creator. Очень доступно, пошагово и логично. Есть много иллюстраций и примеров. Эх, если бы все так писали документацию.
Сайт vcreatelogiс – http://www.vcreatelogic.com/, а вот ссылка для скачивания документа – http://www.vcreatelogic.com/resources/downloads. По ссылке необходимо нажать вкладку “Other Downloads”.

Проглядеть его можно вот в этом окошке:

Всем привет. Пару дней назад я начал немного “похачивать” Qt-creator. Чтобы понять в общих чертах внутренности прилось потратить вечер. Еще один вечер ушел чтобы понять как реализовать эту фичу. Ну и в конечном итоге реализация заняла около часа.

Смысл этой фичи заключается в том, что теперь можно с помощью соотвественного переключателя соеденить деревья исходных файлов и заголовчных файлов. Мне было неудобно иметь два дерева – одно для заголовочных файлов – другое для исходных, и это сподвинуло меня реализовать эту маленьку переделку.
Результаты можно посмотреть в моем “merge request” на gitorious’е .

Вот небольшая видео-демка, демонстрирующая мою фичу.

Click here to view the embedded video.

Я поменял калсс FolderNode, теперь в нем есть свойство FileType contentType(). Это свойство определяет тип содержимого папки (исходники, заголовочные файлы, ресурси и тд.). Еще я добавил свойство excludeFolderType в FlatMode. Это свойство служит для того, чтоб исключить все папки, у которых контент соостветсвующего типа, из модели со всеми наследниками.

Зачем мне это было нужно.
1. Хотелось понять как устроен Qt-creator.
2. Повысить свои навыки (поучится на чужом коде).
3. Помочь сделать Qt-creator лучше.

Дальше планирую реализовать еще парочку небольших улучшений:
1. Панель файловой системы сделать древовидной.
2. Состояние файла в проекте в системе контроля версий.

P.S:Это был мой первый опыт работы с git и gitorious.

Hello. I started qt-creator hacking two days ago. It took one evening to understand internal basics and one evening to decide hw to realise this feature. And so one hour to implement it.

You can see results in my “merge request” on gitorious .

I recorded small video to show this feature.

Click here to view the embedded video.

I changed FolderNode class, now it has property FileType contentType(). This property represent content type of folder. And added excludeFolderType property to FlatMode. This property exclude Folder with children with appropriate type from model.

Why I did it:
1. I’d like to understand internals of Qt-creator.
2. Got some experiences and skill.
3. Help to make Qt-creator better.

Also I planing to add version control system status to project tree and Tree view of File system view plane.
Hope to see this feature in master branch in near future.

P.S.: It was my first experience with gitorious.

Introduction.

Some time before I wrote about pimp pattern by Qt-way. In that post I was trying to show you the good way of using pimpl pattern, and use it at all. Especially when you implement your own library. Binary compatibility is good idea and d-pointers help to make it easily. Now I’ll try to extend you knowledges about this pattern, and show you new useful tool for making d-pointers better and more flexible. The next post is finally will close the pimpl topic: it will be about shared d-pointers and implicit sharing. But this topic is about private slots, the mechanism, that common used by Qt classes.

What is it? And why to use it?

Private slot is extension of d-pointers. Private slots give you way to realize slots in private class, even if private class is not QObject ( it’s not QObject almast in all classes ). But public class have to be QObject. Really the slot is not Private’s class slot, it is part of public class.
Why we need slot in private class? Let’s look at some example. There is exists QAbstractScrollArea class.It’s simply displays it’s view
port widget, and move it, if it has large geometry. QAbstractScrollAreaPrivate has two QScrollBars to make opportunity to user move viewport’s widget. Ok, and what to do when user changed scrollbar’s value ? In common way we need to connect appropriate signal of scrollbar to slot of our class, that implement necessary behaviour (scroll in our case). But this slots will became available outside our class in this case. It’s not good idea to show private implementation outside. The other possible solution is to make private class derived from QObject. Don’t do this (you have very heavy reasons to do it, and private slots is not one of them)!!!
Don’t worry, Trolls made a grade solution – private slots! This is very simple and flexible way to resolve this issue.

How does it work?

To implement private slot there is exists Q_PRIVATE_SLO macros. As usual, let’s look inside this macro:

# define Q_PRIVATE_SLOT(d, signature)

Wow!!! it’ empty. Why? Where is our macros’s definition? Hmmmm. The real man doesn’t afraid to come up against an obstacle. That’s why let’s look inside Qt’s moc preprocessor’s source code. The internal model of moc is looks like any lexer parser. But It’s not look like it made by QLALR, yacc or something else. I know that Trolls used QLALR ( their internal software ) to generate parsers – Qt Script Engine, QXMLStreamReader and maybe something else. But not moc. I’m not very strong with parsers, and it’s not our target ( at this moment ), that’s why I’ll only notice you about our research on Q_PRIVATE_SLOT macros.
Tokens are generated by generate_keywords. You can find it in util subfolder of moc’s source folder.
The output of this tool is array of such structures:

static const struct
{
   Token token;
   short next;
   char defchar;
   short defnext;
   Token ident;
}

Here are records about slots, signals and our private signal:

    {Q_SIGNAL_TOKEN, 0, 83, 470, CHARACTER},
    {Q_SIGNALS_TOKEN, 0, 0, 0, CHARACTER},
    {Q_SLOT_TOKEN, 0, 83, 474, CHARACTER},
    {Q_SLOTS_TOKEN, 0, 0, 0, CHARACTER},
    {Q_PRIVATE_SLOT_TOKEN, 0, 0, 0, CHARACTER},

Now we know that tokenizer generates token Q_PRIVATE_SLOT_TOKEN for our macros during parsing of code.

here it is in token.cpp:

        case Q_PRIVATE_SLOT_TOKEN: return "Q_PRIVATE_SLOT_TOKEN";

End then let’s find logic of parser. What parser has doing when met this token. This implementation is in MOC::parse() method:

              case Q_PRIVATE_SLOT_TOKEN:
                    parseSlotInPrivate(&def, access);
                    break;

Yes! We have found it!
the parseSlotInPrivate method is what we have been looking for. Let’s look at definition:

void Moc::parseSlotInPrivate(ClassDef *def, FunctionDef::Access access)
{
    next(LPAREN);
    FunctionDef funcDef;
    next(IDENTIFIER);
    funcDef.inPrivateClass = lexem();
    // also allow void functions
    if (test(LPAREN)) {
        next(RPAREN);
        funcDef.inPrivateClass += "()";
    }
    next(COMMA);
    funcDef.access = access;
    parseFunction(&funcDef, true);
    def->slotList += funcDef;
    while (funcDef.arguments.size() > 0 && funcDef.arguments.last().isDefault) {
        funcDef.wasCloned = true;
        funcDef.arguments.removeLast();
        def->slotList += funcDef;
    }
}

It’s all clear and rather simple. As you can see, this function is fills funcDef class/struct with appropriate values and adds this funvDef to regular slot List, like for normal slot does. And after moc did it, preprocessor replaced this macro with empty string regarding macros definition. And when compile build it, there is nothing left. But the slot’s meta definition has been realized in moc_.cpp file.
Very nice approach. Also you have opportunity to extend moc’s preprocessing functionality by hacking it
Ok. Now we know how it works, let’s look how to use it.

How to use it in your code?

It’s totally simple. Let’s extend my previous example.
1. Let’s make new method void _q_boo() in MyClassPrivare class:

class MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClass);
public:
	MyClassPrivate();
	virtual ~MyClassPrivate();

	void foo();
	void _q_boo();
	int i;
	MyClass * q_ptr;
};

definition is in myclass.cpp looks like:

void MyClassPrivate::_q_boo()
{
	qDebug()<<i;
	QCoreApplication::exit(1);
}

Don’t forget to include QDebug and QCoreApplication headers.
Some words about strange name _q_boo. It’s Qt’s naming rule for private slots. Name have to start with “_q_”. In this case it’s easy to recognize it in class’s declaration and definition.
I added QCoreApplication::exit(1) to exit application when slot will execute. But keep in mind that is not a good decision at all. It’s only for testing and demonstrationg of our library.
2. To make it more realistic ( in other case it’s too simple ) let’s invoke this slot from derived class.We have to declare macros in classes declaration:

	Q_PRIVATE_SLOT(d_func(),void _q_boo());

Regarding previous research about moc, we can explain that we need two arguments: first – target object, second – target method.

3. Let’s try to build our project:

moc_myclassderived.cpp: In member function ‘virtual int MyClassDerived::qt_metacall(QMetaObject::Call, int, void**)’:
moc_myclassderived.cpp:70: error: invalid use of incomplete type ‘struct MyClassDerivedPrivate’
myclassderived.h:5: error: forward declaration of ‘struct MyClassDerivedPrivate’

Don’t be afraid. That all ok. Moc doesn’t know anything about our private class, that’s why when it generates the moc file it only generate code regarding parsed .h file without checking cpp model at all. And it includes only header, that was target of moc generation process. myclassderived.h in our case. And there is only forward declaration in private header. But we unable to say to moc compiler to add extra header to include section.
The generated moc file “moc_myclassderived.cpp” is simply extension to our myclassderived.cpp file. That’s why it’s save to add it at end of .cpp file. From this place the parivate class is accessible, because we have included it’s header at the top of .cpp file.

..................
#include "moc_myclassderived.cpp"

Let’s build project one more. O-o-o-u. The same error . Don’t be despairing of success ! Simply run command “make distclean” and build it again.
That’s all. O, no! I forgot about example. Ok, let’s go next.
First let’s look on moc’s generated code for our slot (as I promised before).

int MyClassDerived::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
    _id = MyClass::qt_metacall(_c, _id, _a);
    if (_id < 0)
        return _id;
    if (_c == QMetaObject::InvokeMetaMethod) {
        switch (_id) {
        case 0: signal2((*reinterpret_cast< int(*)>(_a[1]))); break;
        case 1: d_func()->_q_boo(); break;
        default: ;
        }
        _id -= 2;
    }
    return _id;
}

Keep attention, when method receives query to invoke slot with _id=1, it simply invoke method _q_boo() from our private class directly. Without any additional steps and callings, like it is native Private Class’s meta call system (It’s not totally true, because there is little overhead, when calling d_func(), because it casts d_ptr to our Private Class’s type).

4. Let’s start timer in constructor, which will emit signal and execute our slot after 1 second.
First of all we need add init() method in private class.
Definition in myclassderived.cpp is look’s like this:

void MyClassDerivedPrivate::init()
{
	Q_Q(MyClassDerived);
	QTimer::singleShot(1000,q,SLOT(_q_boo()));
}

And now let’s add initialization of private class in constructors of public one:

MyClassDerived::MyClassDerived(QObject *parent)
	:MyClass(*new MyClassDerivedPrivate(), parent)
{
  Q_D(MyClassDerived);
  d->init();

}

MyClassDerived::MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent)
		:MyClass(dd, parent)
{
	Q_D(MyClassDerived);
	d->init();
}

Of course it’s better to add only one line in each constructor:

    QTimer::singleShot(1000,this,SLOT(_q_boo()));

But I tried to show you concept at all, and there are usually more than one line of code in initialization method.
Believe it or not, that’s all. In the next section I’ll show you test application for our library.

Testing our library.

Lets’ make new project (subfolder “main” in my case).
main.pro

TEMPLATE = app
LIBS += -lhabrhabr -L..
INCLUDEPATH += ../
TARGET = main

SOURCES += main.cpp

and the main.cpp:

#include "myclassderived.h"
#include <QApplication>

int main(int argc, char ** argv) {
	QApplication a(argc,argv);
	MyClassDerived d(0);
	return a.exec();
}

Why I made QApplication’s instance. Because signals and slots are working in context of thread loop, and we need this loop for our code. In our case we use main loop of application.
Build, Run, and having results:

7
exit-code:1

Ta-a-a-T-a-a-m! We made it!

Warning: I noticed about headers order in .pro file before. Here I’m repeating about it. Headers of private class HAVE TO BE AFTER THEIR PUBLIC headers in HEADERS section of .pro file. Also headers have to be in order they include each other. For example, myclass.h have to be before myclassderived.h, because myclassderived.h include’s it.
Keep in mind, that Q_PRIVATE_SLOT is not a part of public API, and Trolls are not make any guaranties, that it will have the same behavior in next releases. But don’t be afraid, I noticed in the post about pimpl, that it’s a base of all Qt’s realization, that’s why It might be changed only at next major releases, for example in Qt5.

And now source code, as usual (source code of test program is in previous section):
habrhabr.pro:

TEMPLATE = lib
HEADERS += myclass.h \
    myclass_p.h \
	myclassderived.h \
    myclassderived_p.h
SOURCES += myclass.cpp \
    myclassderived.cpp

myclass.h

#ifndef MYCLASS_H
#define MYCLASS_H

#include <QObject>

class MyClassPrivate;
class MyClass : public QObject
{
Q_OBJECT
public:
    explicit MyClass(QObject *parent = 0);
	int foo() const;
signals:
	void signal(int);
protected:
	MyClassPrivate * const d_ptr;
	MyClass(MyClassPrivate &dd, QObject * parent);
private:
	Q_DECLARE_PRIVATE(MyClass);
};

#endif // MYCLASS_H

myclass_p.h

#ifndef MYCLASS_P_H
#define MYCLASS_P_H
#include "myclass.h"

class MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClass);
public:
	MyClassPrivate();
	virtual ~MyClassPrivate();

	void foo();

	void _q_boo();

	int i;
	MyClass * q_ptr;
};

#endif // MYCLASS_P_H

myclass.cpp

#include "myclass.h"
#include "myclass_p.h"
#include <QDebug>
#include <QCoreApplication>
MyClassPrivate::MyClassPrivate()
{
   i = 5;
}

MyClassPrivate::~MyClassPrivate()
{
	//nothing to do
}

void MyClassPrivate::foo()
{
	Q_Q(MyClass);
	emit(q->signal(i));
}

void MyClassPrivate::_q_boo()
{
	qDebug()<<i;
	QCoreApplication::exit(1);
}

MyClass::MyClass(QObject *parent)
	:QObject(parent)
	,d_ptr(new MyClassPrivate())
{
	Q_D(MyClass);
	d->q_ptr = this;
}

MyClass::MyClass(MyClassPrivate &dd, QObject * parent)
	:QObject(parent)
	,d_ptr(&dd)
{
	Q_D(MyClass);
	d->q_ptr = this;
}

int MyClass::foo() const
{
	Q_D(const MyClass);
	return d->i;
}

myclassderived.h

#ifndef MYCLASSDERIVED_H
#define MYCLASSDERIVED_H
#include "myclass.h"

class MyClassDerivedPrivate;
class MyClassDerived : public MyClass
{
Q_OBJECT
public:
    explicit MyClassDerived(QObject *parent = 0);
signals:
	void signal2(int);
protected:
	MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent);
private:
	Q_DECLARE_PRIVATE(MyClassDerived);
	Q_PRIVATE_SLOT(d_func(),void _q_boo());
};

#endif // MYCLASSDERIVED_H

myclassderived_p.h

#ifndef MYCLASSDERIVED_P_H
#define MYCLASSDERIVED_P_H

#include "myclassderived.h"
#include "myclass_p.h"

class MyClassDerivedPrivate: public MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClassDerived);
public:
	MyClassDerivedPrivate();
	virtual ~MyClassDerivedPrivate();

	void foo2();
	void init();
	int j;
};

#endif // MYCLASSDERIVED_P_H

myclassderived.cpp

#include "myclassderived.h"
#include "myclassderived_p.h"
#include <QTimer>

MyClassDerivedPrivate::MyClassDerivedPrivate()
{
	j=6;
	i=7;
}

MyClassDerivedPrivate::~MyClassDerivedPrivate()
{

}

void MyClassDerivedPrivate::foo2()
{
	Q_Q(MyClassDerived);
	emit(q->signal2(j));
	emit(q->signal(j));
}

void MyClassDerivedPrivate::init()
{
	Q_Q(MyClassDerived);
	QTimer::singleShot(1000,q,SLOT(_q_boo()));
}

MyClassDerived::MyClassDerived(QObject *parent)
	:MyClass(*new MyClassDerivedPrivate(), parent)
{
  Q_D(MyClassDerived);
  d->init();

}

MyClassDerived::MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent)
		:MyClass(dd, parent)
{
	Q_D(MyClassDerived);
	d->init();
}

#include "moc_myclassderived.cpp"

Вступление.

Недавно я писал по поводу реализации паттерна Pimpl в библиотеке Qt и призывал людей следовать такому подходу при разработке их собственных бибиотек. Теперь я хочу поговорить о таком понятии, как приватные слоты и тем самым продолжить эту тему. Заключительной статьей на эту тему будет реализация механизма Implicit Sharing и shared d-pointer.

Что это и зачем это нужно.

Приватные слоты – это механизм дополняющий функционал d-указателей. Он позволяет реализовать слоты для приватного класса, даже если он не является наследником от QObject (обычно он им и не является), но для этого публичный класс должен быть наследником от QObject. Тоесть по факту создается некий приватный слот в публичном классе и он непосредственно дергает нужный метод приватного класса.
Зачем это нужно? Ну рассмотрим на примере. Есть класс QAbstractScrollArea. Он просто отображает некий виджет (viewport) и обеспечивает прокрутку. Прокрутка обеспечивается с помощью двух экземпляров класса QScrollBar. Сами эти скролбары он хранит в приватном классе. Теперь проблемма: как подключить сигнал от скроллбара об изменение его позиции с классом QAbstractScrollAreaPrivate, ведь он не является QObject’ом ? Сделать его наследником от QObject – лучше не делайте это . Можно сделать слот в публичном классе и повесить на него, то в таком случае это не очень красиво – так как наружу выходят слоты от внутренней реализации. Вот ту Qt-шниками был придуман достаточно разумный и элегантный подход – приватные слоты.

Как это работает.

Для реализации приватного слота служит макрос Q_PRIVATE_SLOT. Ну по нашему обычаю залазим в исходники Qt и смотрим что он из себя представляет:

# define Q_PRIVATE_SLOT(d, signature)

Опа !!!! Пусто . Но настоящие мужчины никогда не отчаиваются и лезут в исходники глубже, а точнее в исходники moc. Кто не знает, moc – это некая реализация некого парсера. Только немного хитрая. В отличие от инструментов использующих QLALR (QSA и QXmlStreamReader ) – эта штука оказалась своеобразной. Я не силент в парсерах поэтому более глобальный анализ провести не могу. Но он точно не похож на LALR потому-что я не нашел лексики его. Таблица токенов генерится некой утилитой generate_keywords, которую можно найти в исходниках moc в папке util.
Насколько я понял он просто генерит из любого текста токены и формирует из них структуру вида:

static const struct
{
   Token token;
   short next;
   char defchar;
   short defnext;
   Token ident;
}

Вот пример записей этого генератора:

    {Q_SIGNAL_TOKEN, 0, 83, 470, CHARACTER},
    {Q_SIGNALS_TOKEN, 0, 0, 0, CHARACTER},
    {Q_SLOT_TOKEN, 0, 83, 474, CHARACTER},
    {Q_SLOTS_TOKEN, 0, 0, 0, CHARACTER},
    {Q_PRIVATE_SLOT_TOKEN, 0, 0, 0, CHARACTER},

Кто хочет покапать дальше или вообще уже знает ответ – прошу высказыватся.
Кстати очень просто оказалось это все дело расширить можно добавить свой препроцессинг. Вот что значит писать красиво.

в token.cpp находим наш токен:

        case Q_PRIVATE_SLOT_TOKEN: return "Q_PRIVATE_SLOT_TOKEN";

И далее в реализации метода MOC::parse() находим что же он делает, когда встречает этот парсер:

              case Q_PRIVATE_SLOT_TOKEN:
                    parseSlotInPrivate(&def, access);
                    break;

Ну вот и добрались до сути, она находится в методе parseSlotInPrivate(&def, access);
Вот и она:

void Moc::parseSlotInPrivate(ClassDef *def, FunctionDef::Access access)
{
    next(LPAREN);
    FunctionDef funcDef;
    next(IDENTIFIER);
    funcDef.inPrivateClass = lexem();
    // also allow void functions
    if (test(LPAREN)) {
        next(RPAREN);
        funcDef.inPrivateClass += "()";
    }
    next(COMMA);
    funcDef.access = access;
    parseFunction(&funcDef, true);
    def->slotList += funcDef;
    while (funcDef.arguments.size() > 0 && funcDef.arguments.last().isDefault) {
        funcDef.wasCloned = true;
        funcDef.arguments.removeLast();
        def->slotList += funcDef;
    }
}

Вот теперь все ясно. Как вы видите эта директива заполняет нужные значения для определения метафункции, которая генерируется moc’ом ( таким же образом как и для обычных слотов ). А пустой дефайн просто делает эту запись пустой, когда moc прошел и настает время предкомпилятору. Тоесть на момент стандартной компиляции там уже пусто, но реализация слота сгенерирована в moc файле. Далее я покажу как она выглядит в нашем примере.
Ну вобщем разобрались с тем как это устроено, далее будет смотреть как это использовать.

Как реализовать это в своем коде.

Тут в дейсвтительности все очень просто. В качестве примера берем классы из моей предыдущей статьи . И добавляем новый функционал.
1. Добавляем метод void _q_boo() в MyClassPrivare:

class MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClass);
public:
	MyClassPrivate();
	virtual ~MyClassPrivate();

	void foo();
	void _q_boo();
	int i;
	MyClass * q_ptr;
};

Реализация в myclass.cpp будет выглядеть таким образом:

void MyClassPrivate::_q_boo()
{
	qDebug()<<i;
	QCoreApplication::exit(1);
}

Не забудте добавить QDebug и QCoreApplication в инклуды.
По поводу имени _q_boo. Это правило именования приватных слотов от qt. Имя должно начинатся на “_q_”. Тогда при просмотре объявления приватного класса можно определить что это слот.
QCoreApplication::exit(1) – я добавил для того чтобы при сраватывании мы завершили основной цикл приложения (далее напишу листинг этого приложения для тестирования нашей библиотеки).
2. Для большей запутаности ( а то сильно просто все получается ) давайте дерганье этого слота реализуем в наследнике – MyClassDerived. Для этого объявим у него в приватной секции такой вот макрос:

	Q_PRIVATE_SLOT(d_func(),void _q_boo());

Из вышеуказанного реверс инжиниринга moc мы тут видим, что нам нужен указатель на класс и имя его метода. По факту это простой текстовый анализ на основании которого потом сгенерируется код moc_myclassderived.cpp.
3. Попробуем собрать наш проект:

moc_myclassderived.cpp: In member function ‘virtual int MyClassDerived::qt_metacall(QMetaObject::Call, int, void**)’:
moc_myclassderived.cpp:70: error: invalid use of incomplete type ‘struct MyClassDerivedPrivate’
myclassderived.h:5: error: forward declaration of ‘struct MyClassDerivedPrivate’

Это нормально, ведь moc ничего не знает о нашем Private классе, ведь он инклудид в себя только тот заголовочный файл, на основании которого он был сгенерированый. А в публичном заголовочном файле только forward объявление. Так как moc – это по сути добавка к нашей реализации, просто включим его в конец нашего .cpp файла:

..................
#include "moc_myclassderived.cpp"

Теперь запускаем сборку и … Опять та же ошибка !!! Не отчаивайтесь. Просто сделайте make distclean и соберите снова.
Ну вот вобщем и все … аааа конечно, пример использования. Тогда идем дальше.
Как и общела смотрим, что же нагенерил нам moc:

int MyClassDerived::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
    _id = MyClass::qt_metacall(_c, _id, _a);
    if (_id < 0)
        return _id;
    if (_c == QMetaObject::InvokeMetaMethod) {
        switch (_id) {
        case 0: signal2((*reinterpret_cast< int(*)>(_a[1]))); break;
        case 1: d_func()->_q_boo(); break;
        default: ;
        }
        _id -= 2;
    }
    return _id;
}

Обратите внимание: когда к нам приходит запрос на вызов слота с _id=1, то мы дергаем метод приватного класса напрямую, без никаких потерь, как будто эта система метавызовов является родной для приватного класса а не для публичногою (немного завираю, так как все таки небольшой оверхед есть в преобразовании типов, во время вызова функции d_func() ).

4. Давайте запустим таймер, чтоб он дернул наш метод при создании класса MyClassDerived через одну секунду.
В первую очередь объявим init() метод в MyClassDerivedPrivate.
Реализация в myclassderived.cpp выглядит таким образом:

void MyClassDerivedPrivate::init()
{
	Q_Q(MyClassDerived);
	QTimer::singleShot(1000,q,SLOT(_q_boo()));
}

Ну и добавим вызов инициализации в наш конструктор (раньше они у нас были пустые):

MyClassDerived::MyClassDerived(QObject *parent)
	:MyClass(*new MyClassDerivedPrivate(), parent)
{
  Q_D(MyClassDerived);
  d->init();

}

MyClassDerived::MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent)
		:MyClass(dd, parent)
{
	Q_D(MyClassDerived);
	d->init();
}

Конечно в данном случае можно было не городить конструкцию с init(), просто бы в каждом конструкторе бы была такая запись:

    QTimer::singleShot(1000,this,SLOT(_q_boo()));

Но я хотел показать подход, когда в инициализации необходимо выполнить более чем одно действие.

Не поверите Но это все. В следующем пункте покажу программку, которая это все оттестирует.

Тестируем наш код

Ну вот создаем новый проект (в моем случае я его сделал в подкаталоге main моего проекта habrahabra):
main.pro

TEMPLATE = app
LIBS += -lhabrhabr -L..
INCLUDEPATH += ../
TARGET = main

SOURCES += main.cpp

ну и сам main.cpp:

#include "myclassderived.h"
#include <QApplication>

int main(int argc, char ** argv) {
	QApplication a(argc,argv);
	MyClassDerived d(0);
	return a.exec();
}

Почему нужно было делать QApplication? Да потому как система сигналов и слотов не будет работать без цикла выполнения потока в контексте которого он будет выполнятся (в нашем случае mainloop’a).
Собираем, запускаем, получаем результат:

7
exit-code:1

Урааа!!! Все работает.

Заключение.

Может вас испугало что я так много написал по этой теме ? В таком случае могу вас успокоить, все намного проще чем вам кажется. Просто я хотел показать как работает этот механизм, а не просто инструкции по применению вроде: “Вставтье это сюда и это сюда и ура у вас все работает”. В действительности необходимо проделать всего три шага.
1. Объявить макрос Q_PRIVATE_SLOT(d_func(),_q_method());
2. Реализовать этот метод в приватном классе.
3. Добавить в конец cpp файла #include “moc_classname.cpp”

И все !!! Все просто.

Важно: я уже указывать порядок следования заголовочных файлов в статье касательно pimpl. Но тут напомню, что все приватные заголовочные файлы должны строго следовать за публичными и в списке HEADERS они должны идти в порядке включения. В нашем примере derived класс включает в себя заголовки базового класса, поэтому в списке HEADERS файла проекта он идет после заголовков родителя.
Ну и так же как и макросы d-указателя, макросы приватного слота не являются частью публичного API и могут быть изменены в любой момент. Но не пугайтесь, я успокаивал по этому поводу в статье по pimpl.

Ну и по традиции исходники (исходники тестовой програмки полностью опубликованы выше, поэтому тут их не буду писать):
habrhabr.pro:

TEMPLATE = lib
HEADERS += myclass.h \
    myclass_p.h \
	myclassderived.h \
    myclassderived_p.h
SOURCES += myclass.cpp \
    myclassderived.cpp

myclass.h

#ifndef MYCLASS_H
#define MYCLASS_H

#include <QObject>

class MyClassPrivate;
class MyClass : public QObject
{
Q_OBJECT
public:
    explicit MyClass(QObject *parent = 0);
	int foo() const;
signals:
	void signal(int);
protected:
	MyClassPrivate * const d_ptr;
	MyClass(MyClassPrivate &dd, QObject * parent);
private:
	Q_DECLARE_PRIVATE(MyClass);
};

#endif // MYCLASS_H

myclass_p.h

#ifndef MYCLASS_P_H
#define MYCLASS_P_H
#include "myclass.h"

class MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClass);
public:
	MyClassPrivate();
	virtual ~MyClassPrivate();

	void foo();

	void _q_boo();

	int i;
	MyClass * q_ptr;
};

#endif // MYCLASS_P_H

myclass.cpp

#include "myclass.h"
#include "myclass_p.h"
#include <QDebug>
#include <QCoreApplication>
MyClassPrivate::MyClassPrivate()
{
   i = 5;
}

MyClassPrivate::~MyClassPrivate()
{
	//nothing to do
}

void MyClassPrivate::foo()
{
	Q_Q(MyClass);
	emit(q->signal(i));
}

void MyClassPrivate::_q_boo()
{
	qDebug()<<i;
	QCoreApplication::exit(1);
}

MyClass::MyClass(QObject *parent)
	:QObject(parent)
	,d_ptr(new MyClassPrivate())
{
	Q_D(MyClass);
	d->q_ptr = this;
}

MyClass::MyClass(MyClassPrivate &dd, QObject * parent)
	:QObject(parent)
	,d_ptr(&dd)
{
	Q_D(MyClass);
	d->q_ptr = this;
}

int MyClass::foo() const
{
	Q_D(const MyClass);
	return d->i;
}

myclassderived.h

#ifndef MYCLASSDERIVED_H
#define MYCLASSDERIVED_H
#include "myclass.h"

class MyClassDerivedPrivate;
class MyClassDerived : public MyClass
{
Q_OBJECT
public:
    explicit MyClassDerived(QObject *parent = 0);
signals:
	void signal2(int);
protected:
	MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent);
private:
	Q_DECLARE_PRIVATE(MyClassDerived);
	Q_PRIVATE_SLOT(d_func(),void _q_boo());
};

#endif // MYCLASSDERIVED_H

myclassderived_p.h

#ifndef MYCLASSDERIVED_P_H
#define MYCLASSDERIVED_P_H

#include "myclassderived.h"
#include "myclass_p.h"

class MyClassDerivedPrivate: public MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClassDerived);
public:
	MyClassDerivedPrivate();
	virtual ~MyClassDerivedPrivate();

	void foo2();
	void init();
	int j;
};

#endif // MYCLASSDERIVED_P_H

myclassderived.cpp

#include "myclassderived.h"
#include "myclassderived_p.h"
#include <QTimer>

MyClassDerivedPrivate::MyClassDerivedPrivate()
{
	j=6;
	i=7;
}

MyClassDerivedPrivate::~MyClassDerivedPrivate()
{

}

void MyClassDerivedPrivate::foo2()
{
	Q_Q(MyClassDerived);
	emit(q->signal2(j));
	emit(q->signal(j));
}

void MyClassDerivedPrivate::init()
{
	Q_Q(MyClassDerived);
	QTimer::singleShot(1000,q,SLOT(_q_boo()));
}

MyClassDerived::MyClassDerived(QObject *parent)
	:MyClass(*new MyClassDerivedPrivate(), parent)
{
  Q_D(MyClassDerived);
  d->init();

}

MyClassDerived::MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent)
		:MyClass(dd, parent)
{
	Q_D(MyClassDerived);
	d->init();
}

#include "moc_myclassderived.cpp"

This post is part of this post
.pro file:

TEMPLATE = lib
HEADERS += myclass.h \
    myclass_p.h \
    myclassderived.h \
    myclassderived_p.h
SOURCES += myclass.cpp \
    myclassderived.cpp

myclass.h:

#ifndef MYCLASS_H
#define MYCLASS_H

#include <QObject>

class MyClassPrivate;
class MyClass : public QObject
{
Q_OBJECT
public:
    explicit MyClass(QObject *parent = 0);
	int foo() const;
signals:
	void signal(int);
protected:
	MyClassPrivate * const d_ptr;
	MyClass(MyClassPrivate &dd, QObject * parent);
private:
	Q_DECLARE_PRIVATE(MyClass);
};

#endif // MYCLASS_H

myclass_p.h

#ifndef MYCLASS_P_H
#define MYCLASS_P_H
#include "myclass.h"

class MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClass);
public:
	MyClassPrivate();
	virtual ~MyClassPrivate();

	void foo();

	int i;
	MyClass * q_ptr;
};

#endif // MYCLASS_P_H

myclass.cpp

#include "myclass.h"
#include "myclass_p.h"

MyClassPrivate::MyClassPrivate()
{
   i = 5;
}

MyClassPrivate::~MyClassPrivate()
{
	//nothing to do
}

void MyClassPrivate::foo()
{
	Q_Q(MyClass);
	emit(q->signal(i));
}

MyClass::MyClass(QObject *parent)
	:QObject(parent)
	,d_ptr(new MyClassPrivate())
{
	Q_D(MyClass);
	d->q_ptr = this;
}

MyClass::MyClass(MyClassPrivate &dd, QObject * parent)
	:QObject(parent)
	,d_ptr(&dd)
{
	Q_D(MyClass);
	d->q_ptr = this;
}

int MyClass::foo() const
{
	Q_D(const MyClass);
	return d->i;
}

myclassderived.h

#ifndef MYCLASSDERIVED_H
#define MYCLASSDERIVED_H
#include "myclass.h"

class MyClassDerivedPrivate;
class MyClassDerived : public MyClass
{
Q_OBJECT
public:
    explicit MyClassDerived(QObject *parent = 0);
signals:
	void signal2(int);
protected:
	MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent);
private:
	Q_DECLARE_PRIVATE(MyClassDerived);
};

#endif // MYCLASSDERIVED_H

myclassderived_p.h

#ifndef MYCLASSDERIVED_P_H
#define MYCLASSDERIVED_P_H

#include "myclassderived.h"
#include "myclass_p.h"

class MyClassDerivedPrivate: public MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClassDerived);
public:
	MyClassDerivedPrivate();
	virtual ~MyClassDerivedPrivate();

	void foo2();
	int j;
};

#endif // MYCLASSDERIVED_P_H

myclassderived.cpp

#include "myclassderived.h"
#include "myclassderived_p.h"

MyClassDerivedPrivate::MyClassDerivedPrivate()
{
	j=6;
	i=7;
}

MyClassDerivedPrivate::~MyClassDerivedPrivate()
{

}

void MyClassDerivedPrivate::foo2()
{
	Q_Q(MyClassDerived);
	emit(q->signal2(j));
	emit(q->signal(j));
}

MyClassDerived::MyClassDerived(QObject *parent)
	:MyClass(*new MyClassDerivedPrivate(), parent)
{
 //Empty
}

MyClassDerived::MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent)
		:MyClass(dd, parent)
{
 //Empty
}

Introduction.

Qt Logo

Pimpl, what is it?

Pimpl – Pointer to implementation. It’s one of the programming patterns. The other name is “opaque pointer”, “handle classes”, “”Compiler firewall idiom”" and my favourite – “Cheshire Cat”. You can find more on Wikipedia.The main Idea of this pattern is to hide all private members and internal implementation from “main” class’s declaration. You can see only smile ,like Cheshire Cat’s smile. The cat is exists, he can speak, but you can see only his smile (Do you remember Alice ? – “Alice’s Adventures in Wonderland” ).
What it get for us?

1. If class hierarchy is wide and deep, then it get us more complex class hierarchy, increasing code reusing and making separate implementation of internal functionality and external class interface.
2. It makes ability to hide platform depended implementation from end-user.
3. One of the most useful features is binary compatibility of library while changing it’s realization.More about binary compatibility and Application Binary Interface (ABI) you can find here (Itanium C++ ABI) and here (an article about calling conversion).And the main rules about making library binary compatibility is described on KDE techbase Binary Compatibility Issues With C++ with the list of rules what you may to do and what not, while making library binary compatibility-enabled.
4. Next plus Is that there are less export symbols (depending on compiler and target platform), this decrease library loading time and emmory footprint.
5. Very useful feature is less time for project building.
6. All private implementation is hided from end-user, as private declaration makes it only unusable.
7. Implicitly sharing mechanism is based on Shared d-pointer pattern, which is the advanced implementation of d-pointers. The benefit of sharing is that a program does not need to duplicate data unnecessarily, which results in lower memory use and less copying of data. (This topic is for separate post )

And what about lacks? Yes! Here they are:

1. Every Constructor/Destructor increase execution time by allocation and releasing memory, in this pattern it’s making twice on each class.
2. Method of public class needs one extra instruction for accessing to private class implementation variable.

There are some situation when using Pimpl pattern adds unnecessary overhead. For example, when a lot of classes’s implementations created and released for storing some kind of simple data. In this case This classes have to be as simple as possible. And changing of interface of this kind of class is means changing of data exchange protocol. In this case It’s better to use plugins to have flexibility. You can find a lot of such examples. The main rule for all patterns is to use it in right place and in right situation.
As for my own opinion, Pimpl is useful only in library implementation or if you plan to move this code in library later.

How did Qt implement Pimpl in Qt library?

Qt uses “d-pointer” way. The main idea in making private class for base class with XXXXPrivate name. The main class has protected variable that point on this class’s instance. This private class declared in separate header or in .cpp file (I’ll explain what better to do). There are exists two class hierarchy – first is public and second is private. The private hierarchy is situated in _p.h (private headers )files. Private headers are used only for building library. They are absent in “include” folder and you aren’t able to use them in common way.

What the main benefits of using d-pointer by Qt’s way.

D-pointers way might to be some difficult to understand for first look. But it is rather simple and evident. Also code become more readable while using D-pointers, because the code is separated for public and private functionality.
Benefits:

1. Simple and evident.
2. Direct access to whole private class hierarchy (Actually the are not private, the are protected ^-))
3. Ability to access to public class from private.
4. Ability to make slots for private class (also if it not QObject) and hide it from public access by using Q_PRIVATE_SLOT(topic for separate discussion).

Yes, I want it. Give me one please!

Now, if you are ready to use this pattern and wanted to know how to make it I’ll show you right way – Qt way !(I really hope so !).
Here are steps for implementing d-pointer powered class or let’s make cheshire cat’s:
1. Forward declare private class for our main class MyClass:

class MyClassPrivate;
class MyClassPrivate: public QObject
{ ..............

2. Next, declare protected pointer variable of private class in first class of hierarchy:

protected:
    MyClassPrivate * const d_ptr;

Pay attention, that d_ptr is constant pointer. Actually we are unable to change this pointer.
3. Declare protected constructor, with firs parameter of reference to private class. This constructor makes ability to send inherited implementation of private class to all base classes as Pimpl object.

protected:
    MyClass(MyClassPrivate &dd, QObject *parent);

4. Declare macros Q_DECLARE_PRIVATE in private section:

Q_DECLARE_PRIVATE(MyClass);

Lat’s look inside this macros:

#define Q_DECLARE_PRIVATE(Class) \
    inline Class##Private* d_func() { return reinterpret_cast(d_ptr); } \
    inline const Class##Private* d_func() const { return reinterpret_cast(d_ptr); } \
    friend class Class##Private;

We can find there declaration and implementation of “d_func()” and “d_func() const” methods. They are using to retrieve private class instance and cast it to class’s Private class’s type. Also declare Private class as friend of our public class.
There are exists similar macros Q_DECLARE_PRIVATE_D. The difference is that _D macros accept’s two parameters. First is class name too, and the second is name of d-pointer variable. It’s make ability to use some another name for d-pointer instead of “d_ptr”. But name of function d_func() is same. Here is implementation of Q_DECLARE_PRIVATE_D macros:

#define Q_DECLARE_PRIVATE_D(Dptr, Class) \
    inline Class##Private* d_func() { return reinterpret_cast(Dptr); } \
    inline const Class##Private* d_func() const { return reinterpret_cast(Dptr); } \
    friend class Class##Private;

5. Then you need to declare Private class in _p.h or .cpp file. If you plan to inherit this class then you need _p.h file, in other case declare private class inside of .cpp file. Pay attention, that header file have to be declared before private header in project file. And I’ts better to have right ordered headers in project files. Headers that include other headers have to be declared after headers they are include. It’s important when you are include moc file right in your .cpp file when using Q_PRIVATE_SLOT macro (a’ll discuss it in other post, just keep this rule).

class MyClassPrivate
{
    MyClassPrivate();
    virtual ~MyClassPrivate();

    int i;
}

Also you need to make destructor virtual. Why? It’s subject for separate post. But believe me it’s important. Please use C++ documentation to make it clear for you. You can find this topic in Bjarne Stroustrup’s book.
7. Realization of protected constructor is:

MyClass::MyClass(MyClassPrivate &dd, QObject* parent)
              :QObject(parent)
              ,d_ptr(&dd)
{ .....

And the public constructor’s realization (Pay attention on “explicit” keyword, please make it’s clear for you, you have to understand what is it ):

MyClass::MyClass(QObject * parent)
         :QObject(parent)
         ,d_ptr(new MyClassPrivate())
{........

Derived Class’s realization of such constructor is:

MyClassDerived::MyClassDerived(QObject * parent)
         :MyClass(*new MyClassDerivedPrivate(),parent)
{........

As you can see Derived class creates private class instance and send it to base class as it’s private class’s instance.Private class of derived class is derived from private class of base class. And it’s sends to whole hierarchy.
8. To access to private classes’s instance from public class you can use Q_D macros.

#define Q_D(Class) Class##Private * const d = d_func()

As you can see, this macros get pointer to private class and cast it to our Private class type. As result we got variable d that points to our Private class instance (here you are: D-pointer !!! ).

int MyClass::foo() const
{
    Q_D(const MyClass);
    return d->i;
}

Pay attention that you have to declare add “const” to class name when you use it from const method. We got const d-pointer to const private class (if it’s not clear about “consts”, you have to make it clear for your about “const”, it’s very important).
9. Let’s go deeper. Let me introduce new character Q-pointer. Q-pointer is similar to d-pointer, only difference that it points to public(main) class from private class. You can use it from private class’es methods to access to public class (to emit signal, for example).
To implement it you have to declare pointer variable to public class’s instance in your first class of private hierarchy.

class MyClassPrivate
{
public:
    MyClassPrivate();
    virtual ~MyClassPrivate();

    int i;
    MyClass *q_ptr;
}

And declare macros Q_DECLARE_PUBLIC in all private classes, where you going to use q-pointer.

class MyClassPrivate
{
    Q_DECLARE_PUBLIC(MyClass);
public:
    MyClassPrivate();
    virtual ~MyClassPrivate();

    int i;
    MyClass *q_ptr;
}

Here are Q_DECLARE_PUBLIC macro:

#define Q_DECLARE_PUBLIC(Class)                                    \
    inline Class* q_func() { return static_cast(q_ptr); } \
    inline const Class* q_func() const { return static_cast(q_ptr); } \
    friend class Class;

As you can see it’s similar to Q_DECLARE_PRIVATE. but instead of d_ptr there is q_ptr and instead of d_func() is q_func(). And also there are no analog of Q_DECLARE_PRIVATE_D for Q_DECLARE_PUBLIC.
Warning: don’t forget to initialize q_ptr variable in all constructors of base class of your first class of hierarchy:

MyClass::MyClass(QObject * parent)
         :QObject(parent)
         ,d_ptr(new MyClassPrivate())
{
    Q_D(MyClass);
    d->q_ptr = this;
.......
}

10. To access to public class from private one use macros Q_Q.

#define Q_Q(Class) Class * const q = q_func()

Behavior and rules are the same as for d-pointer (don’t forget add “const” when use it from const method).

void MyClassPrivate::foo()
{
    Q_Q(MyClass);
    q->foo();
    emit(q->signal(i));
}

Conclusion.

Keep in mind that all macros are part of non-public Qt API, and might change in any time. But I can console you. These macros are basement of all Qt libs, and in worst way they can change only in Qt5. In any case you have to port application from Qt4 to Qt5. Another consolation is KDE use’s this macros in own source code. But if you paranoiac, you can rename this macros and fit it in your source code.
Also keep in mind that the class My class is derived from QObject. And QObject has it’s own private class hierarchy. QObjectData is most base class in it.It keeps pointer to parent, object state and other base properties. But Qt’s private class hierarchy is isolated from mine, because I close QObject’s d_ptr variable by mine. And when my classes use d_ptr, they use my private classes, but QObject still use it’s own private class.
Why not use Qt’s private hierarchy and make our MyClassPrivate derived from QObjectPrivate class. It is possible but it is bad decision. First of all We lose Qt lib’s binary compatibility and have to recompile our lib for every change of Qt’s private implementation, in this case. The second reason why to not to do so is private headers of Qt classes are unavailable by common way, we need Qt sources to compile our library. And what you’ll get doing it ? It’s unnecessary at all(Maybe I’m wrong, please let me know if it’s true).

Later I’ll tell you about some other interesting things:
What is QFlag and why to use it.
Qt’s code style.
How to implement implicit sharing in your classes and how it works.
Qt’s useful macros.
Qt Creator inside and outside (tips and tricks).
How to create application and easy port it to 7 platforms, using Qt.
And more interesting things.

Don’t lose it, subscribe to RSS on top of this page.
PS: Excuse me for my English, I’ll be glad to receive corrections and remarks about my publications. English is not my native language, be patient, because it’s rather difficult to write on English for me.

Source code examples.

I wrote a lot of text, to help you understand better there are code examples:
this post
I’m unable to put it in this post because WordPress doesn’t show it

English version.

Вступление.

Qt Logo

Часто в документации от Qt встречается термин Pimpl. Кроме того, те кто хоть немного копался в исходном коде Qt часто видел такие макросы как: Q_DECLARE_PRIVATE, Q_D. А также встречал так называемые приватные заголовочные файлы, название которых заканчивается на “_p.h”.
В этой статье я попробую приоткрыть ширму за всей это структурой.

Pimpl, что это?

Pimpl – Private implementation. Это одно из названий паттерна программирования. Еще его называют чеширским котом(это название мне больше нравится). В чем суть этого паттерна? Основная идея этого паттерна – это вынести все приватные члены класса и , в не которых случаях, функционала в приватный класс.
Отсюда название “чеширский кот” – видно только улыбку, а все остальное остается невидимым, но оно несомненно есть Кто не помнит этого замечательного кота, может обратится к первоисточнику, к книге Льюиса Кэрролла «Алиса в стране чудес». Очень интересная книга, особенно если читать в оригинале.
Что это дает?

1. Если иерархия классов “широкая” или “глубокая” получается более комплексная структура классов и тем самым повышается удобство “переиспользование – reuse” кода.
2. Также это дает возможность спрятать платформо-зависимую реализацию от конечного пользователя.
3. Одним из самых основных достоинств – это сохранение бинарной совместимости библиотеки при изменение ее реализации(достигается за счет того что вся реализация находится в приватном классе). Более подробно о бинарной совместимости и бинарном интерфейсе приложения (ABI) можно ознакомится здесь (Itanium C++ ABI) и здесь (an article about calling conversion). И основные правила о бинарной совместимости от KDE разработчиков Binary Compatibility Issues With C++ с кратким сборником того что нужно и чего нельзя делать для сохранения бинарной совместимости.
4. Следующим достоинством является то что количество экспортируемых символов в классе становится меньше и скорость загрузки библиотеки увеличивается, ну и плюс меньший размер конечно.
5. Увеличивается скорость сборки приложения (что очень актуально).
6. Прячется вся ненужная реализация от клиента, в отличие от приватных методов, pimpl объявление и реализацию не видно вообще.
7. Этот паттерн очень сильно облегчает реализацию механизма implicit-sharing (не буду переводить, чтоб не плодить лишней терминологии). Механизм при котором при копировании классов не происходит копирование данных, а копирование происходит лишь тогда, когда копии класса потребуется изменить эти данные. Implicit-sharing реализован во всех контейнерных классах Qt. Для его реализации используется реализация Pimpl под названием “shared D-pointers”. Вообще это емкая тема и требует отдельной статьи.

Но ведь должны же быть и минусы, скрывать их не буду, выложу как есть:

1. Каждый конструктор, деструктор вызывают выделение и освобождение памяти, что увеличивают время создания класса.
2. Каждый метод, который содержит доступ к приватной реализации добавляет плюс одну экстра инструкцию.

Учитывая эти недостатки, по мнению автора, использование этого паттерна для классов, которые будут содержатся в коде в большом количестве и создаваться/удалятся в процессе жизнедеятельности программы нецелесообразно. Допустим примером такой реализации может служить загрузка и хранение неких данных, вот классы, которые реализуют эти данные лучше сделать как можно проще. А любое изменение в таких классах предполагает что изменяется протокол самой передачи этих данных. Но могут быть и другие примеры такого рода классов. Поэтому основное правило при использование любого паттерна распространяется и на этот тоже: использовать необходимо оптимально, там где это действительно необходимо.
То есть этот паттерн необходимо использовать в том случае, если вы пишете библиотеку или планируете вынести этот функционал в будущем в отдельную библиотеку. В других случаях, по личному мнению автора, использование такого подхода избыточно.

Как это реализовано в библиотеках Qt.

В Qt коде используется подход d-указателей. Смысл в том что объявляется класс XXXPrivate и переменная публичного класса в защищенной секции. В отдельном заголовочном файле или в .cpp файле уже пишется реализация приватного класса (в чем разница я объясню позже).
Иерархия классов идет как по публичным так и по приватным классам. Для этого объявление приватного класса обычно делается в отдельном .h файле, который называется так-же как публичный, но добавляется приставка _p: qclassname_p.h. И эти классы не устанавливаются вместе с библиотекой, а служат лишь для сборки библиотеки. Поэтому вы их не найдете в пути, куда установились библиотеки QT (Prefix-PATH).

В чем достоинства подхода d-указателей (d-pointers) от Qt?

Этот подход с первого взгляда может показаться немного запутанным, но я вас уверяю, что он в действительности очень простой и наглядный, и даже облегчает читабельность кода (это свойство я отношу к субъективным, поэтому спорно, все зависит от восприятия конкретного человека).
Достоинства:

1. Простой и наглядный.
2. Прямой доступ ко всей иерархии приватных классов (в действительности они не приватные , а защищенные).
3. Возможность доступа к публичному классу из приватного.
4. Возможность реализовать систему сигналов и слотов для приватного класса и спрятать их от внешнего использования с помощью Q_PRIVATE_SLOT макроса (тема для отдельной статьи).

Хочу такую же, но с перламутровыми пуговицами! (с) х/ф “Брильянтовая рука”

Если я вас убедил, что Pimpl – это хорошо, и вы хотите попробовать и посмотреть как это работает, тогда давайте я вас посвящу в реализацию Pimpl по версии Qt.
Что нужно сделать:
1. Сделать forward – объявление вашего приватного класса перед объявлением публичного класса:

class MyClassPrivate;
class MyClass: public QObject
{ ..............

2. Далее в первом классе иерархии в защищенной секции необходимо объявить переменную, ссылающуюся на приватный класс:

protected:
    MyClassPrivate * const d_ptr;

Обратите внимание, что указатель константный, во избежании всяких там случайных нелепостей.
3. Также в защищенной секции (как первого класса иерархии так и всех его наследников) необходимо объявить конструктор, принимающий в качестве параметра приватный член класса. Это необходимо для того чтобы обеспечить возможность создание наследников приватного класса и использование их как приватных классов во всей иерархии:

protected:
    MyClass(MyClassPrivate &dd, QObject *parent);

4. В приватной секции объявляем макрос доступа к d-указателю:

Q_DECLARE_PRIVATE(MyClass);

Вот теперь разберемся что он из себя представляет:

#define Q_DECLARE_PRIVATE(Class) \
    inline Class##Private* d_func() { return reinterpret_cast(d_ptr); } \
    inline const Class##Private* d_func() const { return reinterpret_cast(d_ptr); } \
    friend class Class##Private;

Как мы видим тут объявляется функция d_func() и d_func() const, с помощью которой мы получаем указатель на приватный класс и константный приватный класс соответственно. Причем получаем его уже приведенным к типу приватного класса этого объекта. Ну и объявляем наш приватный класс другом для публичного.
Также существует макрос Q_DECLARE_PRIVATE_D. Разница в том что в качестве второго параметра вы указываете переменную d-указатель, таким образом вместо d_ptr в качестве D-указателя может быть использована переменная с любым именем. Но название функции d_func остается неизменным.
Реализация макроса выглядит таким образом:

#define Q_DECLARE_PRIVATE_D(Dptr, Class) \
    inline Class##Private* d_func() { return reinterpret_cast(Dptr); } \
    inline const Class##Private* d_func() const { return reinterpret_cast(Dptr); } \
    friend class Class##Private;

5. Теперь необходимо объявить наш приватный класс в .cpp или _p.h файле. Если вы предполагаете дальнейшее наследование от вашего класса или собираетесь использовать приватные слоты, то необходимо вынести все в отдельный _p.h файл. Если же нет, то достаточно объявить приватный файл в .cpp файле. Также имейте ввиду, что в .pro файле .h файл должен идти до _p.h файла и до всех файлов, которые его включат в себя. Это можно взять вообще за правило, так как облегчает работу компилятору.

class MyClassPrivate
{
    MyClassPrivate();
    virtual ~MyClassPrivate();

    int i;
}

Также рекомендую сделать деструктор виртуальным, если вы планируете строить иерархию приватных классов. Почему? Это тема отдельной статьи и таких статей уже написано достаточно, ну и конечно если не верите или не доверяете интернету, то обратитесь к Страуструпу, у него подробно излагается эта тема.
7. Реализация конструктора из защищенной секции будет выглядеть примерно таким образом:

MyClass::MyClass(MyClassPrivate &dd, QObject* parent)
              :QObject(parent)
              ,d_ptr(&dd)
{ .....

Ну и обычный конструктор с таким объявлением (обратите внимание на ключевое слово explicit, если не знаете что это и зачем, поинтересуйтесь – это полезно):

explicit MyClass(QObject * parent);

Будет выглядеть таким образом:

MyClass::MyClass(QObject * parent)
         :QObject(parent)
         ,d_ptr(new MyClassPrivate())
{........

В наследнике реализация такого конструктора будет выглядеть таким образом:

MyClassDerived::MyClassDerived(QObject * parent)
         :MyClass(*new MyClassDerivedPrivate(),parent)
{........

Как вы видите соответствующий конструктор наследника передает экземпляр своего приватного класса во все базовые классы по цепочке иерархии наследования (так же устроено и в Qt иерархии классов; самым первым классом в иерархии приватных классов является QObjectData, который содержит в себе родителя, состояние объекта и другие базовые свойства).
8. Для доступа к экземпляру приватного класса из метода публичного класса существует макрос Q_D().Вот что он из себя представляет:

#define Q_D(Class) Class##Private * const d = d_func()

Как вы видите мы получаем константный указатель на наш приватный класс в виде переменной “d” (вот он D-указатель !!! ).

int MyClass::foo() const
{
    Q_D(const MyClass);
    return d->i;
}

Обратите внимание, что в константных методах необходимо в Q_D макросе дописывать const перед именем класса, чтобы получить константный указатель на константный экземпляр приватного класса (если вас эта формулировка напугала или не до конца ясна, обратитесь к документации по “const”, поверьте – это очень важно ).
9. Теперь погрузимся глубже. Разрешите представить еще одного зверя : Q-указатель. Q-pointer (он же Q-указатель) – это тот же D-pointer (он же D-указатель), только с точностью наоборот. Он служит для доступа из методов приватного класса к экземпляру публичного (используется обычно в тех случаях, если логика тоже вынесена в приватный класс, или планируется это сделать в дальнейшем по цепочке иерархии).
Для его реализации необходимо в самом первом классе приватной иерархии объявить переменную-указатель на базовый класс:

class MyClassPrivate
{
public:
    MyClassPrivate();
    virtual ~MyClassPrivate();

    int i;
    MyClass *q_ptr;
}

И во всех классах иерархии объявить макрос Q_DECLARE_PUBLIC, в который планируется использовать Q-указатель.

class MyClassPrivate
{
    Q_DECLARE_PUBLIC(MyClass);
public:
    MyClassPrivate();
    virtual ~MyClassPrivate();

    int i;
    MyClass *q_ptr;
}

Вот что из себя представляет макрос Q_DECLARE_PUBLIC:

#define Q_DECLARE_PUBLIC(Class)                                    \
    inline Class* q_func() { return static_cast(q_ptr); } \
    inline const Class* q_func() const { return static_cast(q_ptr); } \
    friend class Class;

Как вы можете видеть, все тоже самое, как и в Q_DECLARE_PRIVATE, кроме названий. Ну и макроса для альтернативного названия q_ptr, наподобие Q_DECLARE_PRIVATE_D нет.
Важно: не забудьте позаботится во всех конструкторах первого класса публичной иерархии о инициализации переменной q_ptr:

MyClass::MyClass(QObject * parent)
         :QObject(parent)
         ,d_ptr(new MyClassPrivate())
{
    Q_D(MyClass);
    d->q_ptr = this;
.......
}

10. Для доступа из методов приватного класса к публичному классу (например чтобы сделать вызов сигнала публичного класса ) существует макрос Q_Q, вот как он выглядит:

#define Q_Q(Class) Class * const q = q_func()

Логика та же что и для D-указателей, и те же правила. Ну и в коде он будет выглядеть таким образом:

void MyClassPrivate::foo()
{
    Q_Q(MyClass);
    q->foo();
    emit(q->signal(i));
}

Заключение.

Имейте ввиду, что все эти макросы не являются частью публичного API, и могут быть в любой момент изменены. Но могу вас успокоить. Во первых это всё является настолько базовым фундаментом, что как минимум поменяется это к новой мажорной версии, но в этом случае все равно придется портировать приложение. А во вторых, очень многие крупные проекты используют эти макросы: например KDE. Ну а если вы являетесь убежденным параноиком и никому не доверяете, то можете объявить в своем глобальном файле похожие макросы, изменив их имя и использовать их в коде, тогда боятся точно нечего (кроме изменения поведения компиляторов по отношения к макросам , ибо настоящему параноику всегда есть чего боятся ).
Также имейте ввиду что в моем примере я наследуюсь от QObject, который использует те же макросы для построения своей иерархии как публичных так и приватных классов. Но моя иерархия приватных классов ничего общего не имеет с приватной иерархией классов Qt. Они стоят в стороне и не мешают друг-другу. Так как я перекрыл переменную d_ptr в своем классе, и для всех наследников от моего класса d_ptr будет указателем на мою иерархию, а для QObject нет. Для него d_ptr будет Qt иерархией приватных классов (точнее указателем на QObjectPrivate).
Может возникнуть резонный вопрос, а почему бы наш приватный класс не унаследовать от QObjectPrivate. Ответ: можно, но во первых потеряется бинарная совместимость с библиотекой Qt(нужно будет иметь нашу библиотеку для каждой версии приватной реализации в Qt (она тоже меняется, QWidget точно) ).И вторым аргументом против является то, что для сборки нашей библиотеки потребуются приватные заголовочные файлы библиотеки Qt, которые находятся в папке src исходников, а не include установленных библиотек Qt. Да и трудно себе представить зачем это нужно(может кто-нибудь представит контр-аргументы, буду рад).

В дальнейшем я вам расскажу еще немного интересных вещей:
что такое QFlag, в чем его преимущество и что с ним едят.
Правила оформления кода в Qt-style.
Как реализовать Implicit Sharing и что такое Shared D-pointer.
Полезные макросы в QT.
Qt Creator снаружи и изнутри.
Как с минимальными усилиями написать приложение для 7 платформ.
И много всего другого интересного.

PPS:Приношу свои извинения за мой русский язык, возможные неверные обороты речи и ошибки (как орфографические так и синтаксические) – это не мой родной язык

Фуууууух, ну вот вроде и все. В качестве дополнения простой пример реализации, а то я написал много букв, а на примере всегда наглядней:

.pro файл:

TEMPLATE = lib
HEADERS += myclass.h \
    myclass_p.h \
    myclassderived.h \
    myclassderived_p.h
SOURCES += myclass.cpp \
    myclassderived.cpp

файл myclass.h:

#ifndef MYCLASS_H
#define MYCLASS_H

#include <QObject>

class MyClassPrivate;
class MyClass : public QObject
{
Q_OBJECT
public:
    explicit MyClass(QObject *parent = 0);
	int foo() const;
signals:
	void signal(int);
protected:
	MyClassPrivate * const d_ptr;
	MyClass(MyClassPrivate &dd, QObject * parent);
private:
	Q_DECLARE_PRIVATE(MyClass);
};

#endif // MYCLASS_H

файл myclass_p.h

#ifndef MYCLASS_P_H
#define MYCLASS_P_H
#include "myclass.h"

class MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClass);
public:
	MyClassPrivate();
	virtual ~MyClassPrivate();

	void foo();

	int i;
	MyClass * q_ptr;
};

#endif // MYCLASS_P_H

файл myclass.cpp

#include "myclass.h"
#include "myclass_p.h"

MyClassPrivate::MyClassPrivate()
{
   i = 5;
}

MyClassPrivate::~MyClassPrivate()
{
	//nothing to do
}

void MyClassPrivate::foo()
{
	Q_Q(MyClass);
	emit(q->signal(i));
}

MyClass::MyClass(QObject *parent)
	:QObject(parent)
	,d_ptr(new MyClassPrivate())
{
	Q_D(MyClass);
	d->q_ptr = this;
}

MyClass::MyClass(MyClassPrivate &dd, QObject * parent)
	:QObject(parent)
	,d_ptr(&dd)
{
	Q_D(MyClass);
	d->q_ptr = this;
}

int MyClass::foo() const
{
	Q_D(const MyClass);
	return d->i;
}

файл myclassderived.h

#ifndef MYCLASSDERIVED_H
#define MYCLASSDERIVED_H
#include "myclass.h"

class MyClassDerivedPrivate;
class MyClassDerived : public MyClass
{
Q_OBJECT
public:
    explicit MyClassDerived(QObject *parent = 0);
signals:
	void signal2(int);
protected:
	MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent);
private:
	Q_DECLARE_PRIVATE(MyClassDerived);
};

#endif // MYCLASSDERIVED_H

файл myclassderived_p.h

#ifndef MYCLASSDERIVED_P_H
#define MYCLASSDERIVED_P_H

#include "myclassderived.h"
#include "myclass_p.h"

class MyClassDerivedPrivate: public MyClassPrivate
{
	Q_DECLARE_PUBLIC(MyClassDerived);
public:
	MyClassDerivedPrivate();
	virtual ~MyClassDerivedPrivate();

	void foo2();
	int j;
};

#endif // MYCLASSDERIVED_P_H

файл myclassderived.cpp

#include "myclassderived.h"
#include "myclassderived_p.h"

MyClassDerivedPrivate::MyClassDerivedPrivate()
{
	j=6;
	i=7;
}

MyClassDerivedPrivate::~MyClassDerivedPrivate()
{

}

void MyClassDerivedPrivate::foo2()
{
	Q_Q(MyClassDerived);
	emit(q->signal2(j));
	emit(q->signal(j));
}

MyClassDerived::MyClassDerived(QObject *parent)
	:MyClass(*new MyClassDerivedPrivate(), parent)
{
 //Empty
}

MyClassDerived::MyClassDerived(MyClassDerivedPrivate &dd, QObject * parent)
		:MyClass(dd, parent)
{
 //Empty
}

Hello All. I just think about Cross-platform development of end-user application. And found that it’s much more difficult than might be. I think it’s terrible and it’s break’s IT evolution at all. It’s very sad, and It’s time to think about decision.
Maybe you think I’m drank or it’s paranoia ? Maybe, But let’s see more detailed on it.

What we haver now ?

In our days we have two main branches of end-user hardware devices:
1. portable/embedded/low-resources devices
2. desktop/laptop devices

First category is handled devices, PDA, communicators, Set Top Boxes, industrial devices, Digital Secure Systems, Smart Houses, Phones, Multimedia centers, etc… Let’s call them embedded systems: ES.
The second category is personal computers and laptops. Let’s call them desktop systems: DS.

1. Desktops.

We have two main end-user desktop systems:

1. Windows
2. Linux
3. Mac OS

Windows	Windows: Now almost all users use Windows XP, Vista and Seven. Main language: C++. Main development environment: Visual Studio. In last years Microsoft promote .NET Framework. Now .NET almost cross-platform (Later about it). Target devices: i386 arch.
Mac Os	Mac Os: Almost All users use Leopard and Snow Leopard (but sometimes I sow 10.4). Main Language: Objective-C + Cocoa (C for system development). Family: Unix (BSD based Darwin OS) Main development environment: XCode + XTools Target Device: IBM Power PC (old versions) and Intel’s x386 arch based.
Linux	Linux: Almost all users use 2.6.x kernel. GUI: XServer + desktop environment Most popular desktop environments: KDE (Qt based), Gnome (GTK+ based), XFce (GTK+ based) … Main Language: C (both for system and GUI develop), C++. Main development environment: I don’t really know, for KDE – KDevelop + vim, for GTK+ maybe Anjuta, very popular are emacs and vim. Also Eclipse(CDT) hase popularity.

2. Embedded Systems.

Now we have these most popular embedded systems:

1. Windows Mobile.
2. Symbian.
3. iPhone’s Darwin.
4. Maemo.
5. Android.
6. Moblin.
7. Embedded Linux.

Windows Mobile	Windows Mobile also known as Windows CE. Main language: C++. Main development environment: Visual Studio. In last years Microsoft promote .NET Framework. Now .NET almost cross-platform (Later about it). Target devices: SuperH, X86, MIPS, ARM etc.
Symbian	Symbian: Most popular on Nokia, Samsung and Sony Erricsson mobile devices, most popular version: S60. It’s the most popular mobile platform now. Most popular IDE: Carbide и CodeWarrior. Native Language:C++ (with Nokia’s SDK for Symbian). Target platform: wide rage inc. x386.
iPhone	Iphone OS: latest IPhone OS 3.1. (The similar OS uses on Ipod touch). Main Language: Objective-C + Cocoa (C for system development). Family: Unix (BSD based Darwin OS). Main development environment: XCode + XTools. Target Device: ARM.
Maemo	Maemo – Debian Linux based OS. KErnel 2.6. GUI: XServer + Gnome desktop environment Main Language: C (both for system and GUI develop), C++. Main development environment: The same as for linux, and regarding maemo.org vi(m) and nano. New version is coming: Maemo 5. Target platform: a wide range, but now work only on nokia tablet’s.
Android	Android OS: Current version: 1.6 SDK. 2.0 is Ready. Linux based OS. With Java SDK. Native Language: Java (in newer version added NDK for C/C++ dev, but for system tools coding). IDE: Eclipse + ADT plugin. Target Devices: as linux it’s can feet on wide range devices, including x386. But now it’s few commercial devices(G1 and some HTC devices), but Device manufactures announced a lot of new, android powered devices. This OS is very interesting, because language is Java. Patron is Google. Why they choose this strategy is clear. Google tried to make android stable and easy for developers.
Moblin	Moblin:Linux based (2.6 kernel) OS, with GTK+ and CLutter powered GUI. Windowing system based on GNome mobile.(As I know Moblin 2 is used Xfce ). Main Language: C/C++ and variety of bindings to Clutter. Main IDE: as for Linux. Target devices: Intel Atom from Intel, but I think can be ported to all Linux supported platforms. Main Idea is to make fast, stable and looks-good OS for netbooks.
Linux Embedded	Embedded Linux: Most popular is 2.6 kernel based devices, but most resource limited devices use 2.4 kernel. Main language: C/C++ Might have no windowing system at all. There are the list of GUI implementations: TinyX, DirectFB, GTKFB, Microwindows, FLTK2, QT with QWS, etc. In some cases GUI may be realised via browser: Dillo, Konqueror embedded, Opera, Fresco, etc. At all Android, Maemo and Moblin are Embedded Linuxes too. But I highlighted Linux Embedded because there are a lot of different systems, that are Embedded Linux and the main task of GUI is to interact with user with one application, and this application makes all hardwork instead of user. And there are not importent which GUI Framework is used. The main task for GUI is user-friendly, lightweight, fast and easy and fast for develop.

Also I know about Blackberry and Palm Pre.
Blackberry offer develop on web applications and java. Palm Pre and Palm Pixi work on WebOs with JavaScript style development. Also there are exists Palm treo with Palm OS, but I think time is gone from Palm. What about blackberry, I never seen it at all, As far as I know it has popularity in US in corporate users, but not in other world. That’s why I’m unable discuss this platforms.
I think it’s completed list of main platforms for end-users. Yes I know about BSD (open BSD), minix, Solaris and some others, but this list is mainstream. Looks great, so much different platforms and OSs. But what wrong with this list? Maybe you think:”Nevermind. It’s not a problem to have so wide range of platforms.”
Ok, Let’s find problem at this platforms list.

Problems !!!

And now imagine: I’m software developer, software company or maybe somebody who needs some kind of application. Let’s call it X-body.
If i need desktop application (Mac OS, Windows, Linux), then I have choice :
1. Develop separate product for each platform.
2. Choose cross platform tool.
At my own opinion, first choice is overheading. First of all it took at three time more resources (time and human) to develop, and second is future development of products become difficult. In some point these branches can grow in three totally different products.
That’s why let’s see what about cross-platform tools.
Java – powerful and good decision, but java applications much more slower and need more resources. Also Java applications rely on Java Virtual Machine implementation and version. Developer in some time unable to be sure that application will work on all platforms, JVMs and different JVM versions in the same way. The next thing I really don’t like in java – GUI. There are no good GUI tools and Frameworks (maybe I mistake ?). I know about AWT, SWT and Swing.
GTK/GObjects/C/C++Really nice Framework, but it’s mostly GUI and have only community support. The same is about wxWidgets. What may happend with it tomorrow ?
.NET/MonoReally good try. But it still not full-featured Language, and it’s not so flexible as native applications.
Adobe Flash/Flex/Air Hmm, this one hase it’s own piece of pie in IT industry.
Scripting:Tcl/Tk, Perl, Python, Ruby … Not fast as native, not have direct access to OS specific features.

TAAAATAAAAM
Qt !!!!! Great Job Trolls. Qt is enough to build almost any application, and also it still C++, if some very specific features needed. But almost 95% of regular project is realised only with Qt classes. More about Qt on official site.

In my own opinion Qt is easiest way to implement cross platform application on desktop systems almost for all desktop applications (and not only GUI). Also Qt is natively inside in all modern Linux distributives. Qt hase native look on alien systems: GTK+ based windows managers, Win32, Cocoa. And please believe me, Qt classes really work the same on every platform. Also Qt is good documented. And the main bonus that QT is LGPL licensed !!! Totally free for commercial and free development. Thank you Nokia !!! And there are exists commercial licence for Qt too.
So many pluses, where is minuses?
I think there are:
1. Not good promoted, that’s why not so popular. I hope Nokia take some attention not only for symbian integration.
2. Good documentation about API and classes, but I think It will be better to have more tutorials, webcasts, examples and guidelines. Like Microsoft and Apple.
3. Poor documentation about some useful tools, like makeqpf, macdeployqt, qconfig, qtconfig, qmake and so on. Some times I looked in source code to understand how some feature works.
4. Not very suitable GUI designer, please look on Interface Builder for Mac Os and Delphi with one click for all needed code generation.
5. Not enough 3rd party widgets(especially commercial). It can be fixed by first item.
6. There are no any cross platform deployment tool from Qt. I know only one good : BitRock, but it very expensive, I think. For more information visit official BitRock site.

Also I really like QtCreator. A grate step. I’m also took a part of improving of this product and hope it become most powerful IDE in near future !!!

Hi All. I added photo gallery on meeting with old friends.
Добрый день всем. Вот состоялась встреча выпускников ПВИЗ 2004 года выпуска, группы в которой я учился

Фотоотчет выложил по адресу:
Путь к фоотчетам

Комменты можно писать здесь

PVIZ meeting 2009

Hello. It’s my first blog post.

First of all a couple of words about me. My name Rudenko Eugene. I’m software developer. The main target of this blog is to share for everyone me research and development experiences.

And now start. I choose for blog GoDaddy’s hosting. I like it and I’ll see what will be in future. I found that WordPress is great blogging system, thanks guys for this product and thank a lot for people that make it more extended with a great collection of plugins and extensions.

And now, the main question !!! What is this block about ? The answer: about me and my research and development (R&D). I’ll try to tell you about interesting hacks and show you how to do it and where to find info to get more information.

It’s was an entry, First hack I going provide you is Word Press hacking.

First of all I’m going to share my photo gallery in this blog. I’m using Mac on my main working machine. That’s why I’ll going to create export plugin for Apperture and iPhoto to make share process easily for me.

See you soon, have a nice time.