Где-то здесь не так давно был пост о нововведених в Qt5. Всё вроде выглядит замечательно, но как же обстоят дела на самом деле в отношении уже имеющихся приложений? В этой статье я рассмотрю пример портирования одного из своих проектов на Qt5 с сохранением совместимости исходников с Qt4.
Итак, как и следовало ожидать мое GUI приложение не собирается. И не собирается оно потому, что я использую стандартные Qt виджеты. После недолгих разбирательств выясняется, что виджеты сейчас в отдельном модуле и должны быть явно включены. Сделаем это совместимым с Qt4 способом — добавим следующий код в наш файл qmake проекта (*.pro|*.pri):
greaterThan(QT_MAJOR_VERSION, 4) {
QT += widgets
DEFINES += HAVE_QT5
}
Также с этого момента благодаря добавленноу дефайну можно в любом месте своего кода вставить #ifdef HAVE_QT5 и далее написать код специфичный для Qt5. Того же эффекта с ifdef можно было добиться создав precompiled header с содержимым:
#define HAVE_QT5 (QT_VERSION >= QT_VERSION_CHECK(5, 0, 0))
И опять мой проект не собирается. На этот раз причина в отсутствующих дефайнах Q_WS_*. С Q_WS_WIN и Q_WS_MAC вроде бы всё предельно ясно, просто меняем их на Q_OS_WIN и Q_OS_MAC соответственно. Но что же делать с Q_WS_X11? Довольно часто Q_WS_X11 используется как просто признак юникс-подобных систем за исключением Mac OS (X), но и бывает так, что под этим дефайном скрывается код специфичный для X11. Но в моем случае это в общем-то одно и тоже, так что можно просто заменить на какой-либо другой дефайн (просто переопределить Q_WS_X11 мы не можем, так как некоторые части Qt всё ещё используют это определение) и объявить его в положенном месте, в файле проекта например:
greaterThan(QT_MAJOR_VERSION, 4):unix:!mac:DEFINES += HAVE_X11
Идем дальше. Проект у меня довольно старый и в нем используется множество устаревших классов или методов классов или чего угодно, что уже выброшено или запрещено в Qt5. Сборка опять не идет. Часть из того, что устарело, можно найти в документации по Qt5. Как правило в той же документации сказано, что надо использовать взамен, хотя есть и исключения, которые я рассмотрю ниже. Если же в документации по Qt5 не найдено устарвших классов и их методов, то вероятно это остатки Qt3 и их можно найти в документации на Qt4. Из того на что я наткнулся стоит отметить: QIconSet, QMenuItem (qt3. меняем на QIcon и QAction соответственно), QAbstractItemModel::reset (используем beginResetModel/endResetModel), QKeySequence больше не кастуется в int (делаем цикл по элементам последовательности), часть QUrl перекочевала в новый класс QUrlQuery, Qt::escape удален (свой inline враппер над Qt::escape и QString::toHtmlEscaped), qInstallMsgHandler(qInstallMessageHandler)…
Далее QPA. Всё бы ничего, но с появлением этой штуки из Qt исчез весьма полезный класс QX11Info, и в документации по этому поводу не сказано ничего вменяемого. Исчез он потому, что был жестко завязан на Xlib. Вместо него в Qt5 появился QPlatformNativeInterface, который, впрочем, вскоре был запрещен и сейчас иммеется только в виде приватного класса/заголовка. В своем проекте, как быстрое решение всё ещё завязанное на Xlib, я просто написал враппер над QX11Info, который в случае Qt5 имеет свою собственную реализаию:
x11info.h
#ifndef X11INFO_H
#define X11INFO_H
typedef struct _XDisplay Display;
class X11Info
{
static Display *_display;
public:
static Display* display();
static unsigned long appRootWindow(int screen = -1);
};
#endif // X11INFO_H
x11info.cpp
#include "x11info.h"
#ifdef HAVE_QT5
# include <X11/Xlib.h>
# include <QtGlobal>
#else
# include <QX11Info>
#endif
Display* X11Info::display()
{
#ifdef HAVE_QT5
if (!_display) {
_display = XOpenDisplay(NULL);
}
return _display;
#else
return QX11Info::display();
#endif
}
unsigned long X11Info::appRootWindow(int screen)
{
#ifdef HAVE_QT5
return screen == -1?
XDefaultRootWindow(display()) :
XRootWindowOfScreen(XScreenOfDisplay(display(), screen));
#else
return QX11Info::appRootWindow(screen);
#endif
}
Display* X11Info::_display = 0;
Не ручаюсь за логическую верность реализации, так как до конца написания статьи код ещё не был протестирован.
Также у меня имеются нативные обработчики событий, такие как QApplication::x11EventFilter например. В Qt5 конечно же их пришлось переписать. Для этого нам понадобится QAbstractNativeEventFilter и немного знаний программирования xcb (Xlib здесь не сработает так как QPA о нем ничего не знает). В Принципе, переход на xcb не слишком сложен ввиду схожести API этих двух библиотек, но мануалами запастись не помешает. В моем случае реализация была довольно тривиальна: в своем классе приложения рядом с x11EventFilter добавил ещё один метод под названием xcbEventFilter и несколько ifdefов для компиляции только нужного метода. Далее создал класс унаследованный от QAbstractNativeEventFilter и из него просто обработку всех xcb событий перенаправил на наш метод:
#ifdef HAVE_X11
# ifdef HAVE_QT5
class XcbEventFiter : public QAbstractNativeEventFilter
{
MyApplication *app;
public:
XcbEventFiter(MyApplication *app) : app(app) {}
virtual bool nativeEventFilter(const QByteArray &eventType, void *message, long *) Q_DECL_OVERRIDE
{
if (eventType == "xcb_generic_event_t") {
return app->xcbEventFilter(message);
}
return false;
}
};
# endif
// ....
#endif
Если душе угодно инициализацию приложением можно заменить кастом сингелтона приложения в nativeEventFilter.
Далее плагины. В Qt5 они загружаются другим, несовместимым способом и объявлены должны быть тоже по-другому. Сделана такая неприятная поломка в целях оптимизации (сейчас необязательно грузить весь плагин как полноценную разделяемую библиотеку, что бы убедиться что это вообще Qt плагин и что бы получить из него какую-либо мета информацию, такую как, например, версия программы, с которой данный плагин совместим. подробнее здесь), но чинить тем не менее её всё равно надо.
Для начала, все макросы экспорта наших плагинов делаем условными примерно так:
#ifndef HAVE_QT5
Q_EXPORT_PLUGIN2(myplugin, MyPlugin);
#endif
Также в классе плагина условно добавляем новый специфичный для Qt5 макрос Q_PLUGIN_METADATA где-нибудь рядом с Q_INTERFACES но после Q_OBJECT:
#ifdef HAVE_QT5
Q_PLUGIN_METADATA(IID "tld.domain.Project.MyPluginInterface" FILE "myplugin.json")
#endif
Часть FILE «myplugin.json» необходима только если нам на самом деле нужны метаданные в плагине, а что касается интерфейса «tld.domain.Project.MyPluginInterface», то это тот же интерфейс, что и в Q_DECLARE_INTERFACE. В моем случае в метаданных будут храниться: версия плагина, минимальная версия самой программы и приоритет загрузки. Также надо не забыть добавить магию с объявлением HAVE_QT5 в файлы проектов плагинов, ну или, как быстрый вариант без магии, использовать #if QT_VERSION >= 0x050000.
В случае же статических плагинов, придется поменять вызов Q_IMPORT_PLUGIN макросов. В качестве параметра они сейчас принимают имя класса плагина, а не то, что было первым параметром в Q_EXPORT_PLUGIN2.
Итак, запуск! И, как следовало ождать, segfault. Мой код ожидает, что QMetaType::Void == 0, но в Qt5 это не так. Отлично, исправляем, запускаем и снова segfault. На этот раз проблема в том, что некоторые типы объявлены в одном месте, а Q_DECLARE_METATYPE для них — в другом. Из-за чего последний, даже при явно включенном хидере с типом, работает неправильно. Я не стал разбираться в чем именно загвоздка, просто перенес Q_DECLARE_METATYPE для типов в их заголовочные файлы. И снова запуск — работает!
Программа запустилась, но работы ещё много. Переход на xcb таки должен быть полноценным, т.е. мой класс X11Info должен быть переписать с использованием xcb. Также надо проверить на работоспособность всё, что было пропатчено, впрочем, как и не пропатченное. Но, я надеюсь, самое сложное уже позади!
Надеюсь мой опыт будет вам полезен. Ниже приведу несколько ссылок, которые мне помогли в решение Qt5 головоломок:
www.kdab.com/porting-from-qt-4-to-qt-5/
xcb.freedesktop.org/tutorial/
qt-project.org/doc/qt-5.0/qtwidgets/tools-plugandpaint.html
google.com
Автор: rionekb
