При портировании я опирался на родной гайд qt4.6
Ну… если быть совсем честным, то к этой документации я «пришёл» после двух вручную спортированных приложений ;) Когда упёрся в приложение с ui-файлом старой версии.

Исходные приложения используют только «стандартные» элементы управления (кнопки, поля ввода, выпадающие списки), Layout’ы и .ui — формы. Никакой экзотики, вроде custom drawn виджетов и т.п.

Тролли описывают переход от qt3 к qt4 в своей доке, но мне удалось переехать и от qt2.3 к qt4 без проблем.
Вот как выглядит процедура. Сначала натравливаем утилиту qt3to4 на файл проекта (.pro-шник, то есть). Всё работает чётко и быстро: все старые qt-шные классы переименовываются в соответствующие с приставкой Q3 и правятся имена подключаемых хедеров. Но на этом не всё: программа ещё лезет в .pro-файл и устанавливает там QMAKE_UIC=uic3. Эта строка лишняя, если
портировать и ui-файл тоже, потому что в этом случае утилита uic3 предназначена для работы со старыми ui-файлами.
Да. Программа создаёт log-файл, в котором протоколирует все изменения, сделанные в исходниках проекта. И программе можно подсунуть конфигурационный файл, который будет выполнять те замены, которые будут указаны. То есть замену QMAKE_UIC можно отключить.

Дальше конвертируем старые ui-файлы в новые командой uic3 -convert. Все работает быстро и чётко. Но на этом автоматика заканчивается ;) Дальше — ручками и/или regexp’ами.
Из старых ui-ков генерировался хедер, в котором объявлялось готовое окно. Нужно было только от
него унаследоваться. В qt4 из новых ui-ков генерируется класс-контейнер и он не является окном.
Соответственно, в коде нужно это учесть: унаследоваться от окна и автогенерированного хедера (причём в строго такой последовательности, так требует moc). Другой вариант — сделать переменную
в окне типа автогенерированного класса. И вызвать в конструкторе setupUi( this ).
Я выбрал второй вариант. А если быть честным, то пока писал статью, нашёл информацию о том, что порядок наследования строго определён. А когда я экспериментировал, сделал включение в другом порядке, и пришлось отказаться от этого метода. Поторопился я… :(

Ещё я заметил, что конвертор uic3 в редких случаях меняет разметку. И некоторые элементы
управления, к которым производилось обращение из кода, перестают существовать.
В моём случае конвертор из набора BoxLayout’ов сгенерил QGridLayout.

Также из автоматизма выбился такой момент: раньше существовал конструктор с указанием
имени окошка: QWidget( parent, title, flags ). Теперь этот конструктор принимает только parent & flags.
Для установки title требуется вызов setWIndowTitle. Но это, конечно, мелочи.

В итоге: имеется два спортированных приложения с десятью GUI-шными плагинами.
На первый взгляд — работают. Детальное тестирование будет на следующей неделе. Заняло это примерно 3 дня плотной работы.
Таким образом, команде Trolltech — зачёт. За то, что не пришлось переписывать код,
а воспользоваться старыми объектами, оставленными для совместимости. За то, что удалось сэкономить кучу труда на составление списка замен и на переделывание старых форм в новые.

PS: пока писал заметку, я «нашёл» и porting guide from qt2 to qt3. Но какой в нём теперь смысл… ;)

Ну, и первой задачей была разработка нового интерфейса — чтобы, значит, приспособленного под работу просто пальцами и всяко симпатичнее айфона. Антон предложил начать с оценки «чистого» Framebuffer’а, то есть:

• своя библиотека под FB;
• Direct FB;
• Cairo.

Схема:

Разбираясь с Direct FB вышли на GTK+ поверх DFB — получалось, что не было смысла городить свою библиотеку, когда есть все готовое.

Но, с подачи Юры, с учетом наличия Openembedded, решено было сделать хитрее. Мы собрали образ для B4 — c X-ами на базе Ангстрома, с GTK+/KDrive

Вот KDrive, как известно, работает поверх FB. Это было уже не чистое GTK+DFB, но так было интереснее

ДА!, кстати, в процессе был собран и запущен под QEMU дистрибутив POKY , созданный компанией O-Hand, которую купил интел, который вот, как раз, выпустил таки Moblin beta

Интерфейс платформы Moblin

Moblin Core

Ну а мы зато сделали прототип на GTK+.

Внешний вид прототипа OTDR на B4 на GTK+, GtkPlot

и нарвались на «странность» с отрисовкой GtkEntry — см.блог

смущало также, немного, что в то время как мы уходим c QT на GTK, такие парни как NOKIA и OPENMOKO наоборот, идут в сторону QT от GTK.

А NOKIA так вообще, купила троллтек и, похоже, собирается выпустить новый релиз Маемо на QT4.

Запустили QT Embedded Widgets на B4!

Таки мы решили проверить работу QT4 на B4!

Количество QT вариантов — отдельная тема, но и в этом разобрались.

Сейчас есть:

QT4X11.

QT4Embedded — в молодости QTopia core, QT4 поверх QWS

QT4Extended — ранее QTopia, пакет приложений под QTE.

OE рулит — мы собрали QT Embedded widgets  и запустили его на том самом образе.

В процессе разобравшись с «как же собрать qt4 приложение битбэйком» и глюком TSLib, с патчем от 2007 года.

Всем понравилось и мы сделали прототип на QT4.

Прототип OTDR на B4 под QT Embedded 4.4.3, QWT Plot

А вот видео:

Что в итоге

QT

• «out of the box» приятней GTK
• C++
• легко меняется стиль внешнего вида
• есть QT Creator способствующий разработке (нокиа крепко взялась за кьют)
• QT под X-ами, увы, угнетающе по скорости на B4

GTK

• проще внутри (Владимир со мной не согласен :)
• С
• быстрее процентов на 30 чем QT
• для стилистики нужно применять engines и темы (кстати вот Sato из Poky оказался просто енжином)

Выбираем QT

ps. А Юра знал с самого начала :)

И для затравки ролик из youtube с небольшой демонстрацией Qt Embedded Widgets:

Надо сказать, что на b4 они выглядят точно так же. Похоже, что будем использовать в своём проекте.