QT 4: программирование GUI на С++ - Жасмин Бланшет

Такие подклассы QObject неграфического интерфейса, как QTimer, QProcess и сетевые классы, являются реентерабельными. Мы можем использовать их в любом потоке, содержащем цикл обработки событий. Во вторичных потоках цикл обработки событий начинается с вызова QThread::exec() или таких удобных функций, как QProcess::waitForFinished() и QAbstractSocket::waitForDisconnected().

Из-за ограничений, унаследованных от низкоуровневых библиотек, на основе которых построена поддержка графического пользовательского интерфейса в Qt, QWidget и его подклассы нереентерабельны. Одним из следствий этого является невозможность прямого вызова функций виджета из вторичного потока. Если мы, например, хотим изменить текст QLabel из вторичного потока, мы можем генерировать сигнал, связанный с QLabel::setText(), или вызвать из этого потока функцию QMetaObject::invokeMethod(). Например:

void MyThread::run()

{

…

QMetaObject::invokeMethod(label, SLOT(setText(const QString &)),

Q_ARG(QString, "Hello"));

…

}

Многие из классов Qt неграфического интерфейса, включая QImage, QString и классы—контейнеры, применяют оптимизацию неявного совместного использования данных. Хотя такая оптимизация делает класс нереентерабельным, в Qt не возникает проблем, потому что Qt использует атомарные инструкции языка ассемблер для реализации потокозащищенного подсчета ссылок, делая реентерабельными Qt—классы, применяющие неявное совместное использование данных.

Модуль QtSql также может использоваться в многопоточных приложениях, но он имеет свои ограничения, которые отличаются для разных баз данных. Более подробную информацию вы найдете в сети Интернет по адресу http://doc.trolltech.com/4.1/sql-driver.html. Полный список предостережений, относящихся к многопоточной обработке, находится на веб-странице http://doc.trolltech.com/4.1/threads.html.

Глава 19. Создание подключаемых модулей

Динамические библиотеки (называемые также совместно используемыми библиотеками или библиотеками DLL) — это независимые модули, хранимые в отдельном файле на диске, доступ к которым могут получать несколько приложений. Как правило, необходимые для программы динамические библиотеки определяются на этапе сборки, в таких случаях эти библиотеки автоматически загружаются при запуске приложения. При таком подходе обычно в файл приложения .pro добавляются библиотека и, возможно, путь доступа к ней, а в исходные файлы включаются соответствующие заголовочные файлы. Например:

LIBS += -ldb_cxx

INCLUDEPATH += /usr/local/BerkeleyDB.4.2/include

Альтернативный подход заключается в динамической загрузке библиотеки по мере необходимости и затем разрешении ее символов, которые будут нами использоваться. Qt предоставляет класс QLibrary для решения этой задачи независимым от платформы способом. Получая основную часть имени библиотеки, QLibrary выполняет поиск соответствующего файла в стандартном для платформы месте. Например, если задано имя mimetype, будет выполняться поиск файла mimetype.dll в Windows, mimetype.so в Linux и mimetype.dylib в Mac OS X.

Часто можно расширять функциональные возможности современных приложений с графическим пользовательским интерфейсом за счет применения подключаемых модулей. Подключаемый модуль (plugin) — это динамическая библиотека, которая реализует специальный интерфейс для обеспечения дополнительной функциональности. Например, в главе 5 мы создали подключаемый модуль для интеграции пользовательского виджета в Qt Designer.

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

Кроме того, можно создавать подключаемые модули, предназначенные для конкретных Qt—приложений. Писать такие подключаемые модули в Qt достаточно просто с использованием фреймворка Qt для подключаемых модулей, который повышает безопасность и удобство применения класса QLibrary. В последних двух разделах данной главы мы покажем, как обеспечить в приложении поддержку подключаемых модулей и как создавать пользовательские подключаемые модули для приложения.

Расширение Qt с помощью подключаемых модулей

Qt можно расширять, используя различные типы подключаемых модулей, среди которых наиболее распространенными являются драйверы баз данных, форматы изображений, стили и текстовые кодировки. Каждый тип подключаемых модулей обычно требует наличия по крайней мере двух классов: класса—оболочки, который реализует общие функции программного интерфейса подключаемых модулей, и одного или более классов—обработчиков, которые реализуют программный интерфейс для конкретного типа подключаемых модулей. Обработчики вызываются из класса—оболочки.

Ниже приведен список Qt—классов подключаемых модулей и обработчиков, исключая Qtopia Core (рис. 19.1):

• QAccessibleBridgePlugin — QAccessibleBridge,

• QAccessiblePlugin — QAccessibleIntertace,

• QIconEnginePlugin — QIconEngine,

• QImageIOPlugin — QImageIOHandler,

• QInputContextPlugin — QInputContext,

• QPictureFormatPlugin — нет обработчика,

• QSqlDriverPlugin — QSqlDriver,

• QStylePlugin — QStyle,

• QTextCodecPlugin — QTextCodec.

В демонстрационных целях мы реализуем подключаемый модуль, способный считывать в Windows монохромные файлы курсоров (файлы .cur). Эти файлы могут содержать несколько изображений разного размера для одного курсора. После построения и установки этого подключаемого модуля Qt сможет считывать файлы .cur и получать доступ к отдельным курсорам (например, с помощью классов QImage, QImageReader или QMovie); также можно будет преобразовывать эти курсоры в любой другой формат файлов изображений, воспринимаемый Qt (например, BMP, JPEG и PNG). Кроме того, подключаемый модуль может разворачиваться совместно с Qt—приложениями, поскольку они автоматически проверяют стандартные места расположения подключаемых модулей Qt и загружают все найденные модули.

Новые классы—оболочки подключаемых модулей должны быть подклассом QImageIOPlugin и должны обеспечить реализацию нескольких виртуальных функций:

01 class CursorPlugin : public QImageIOPlugin

02 {

03 public:

04 QStringList keys() const;

05 Capabilities capabilities(QIODevice *device,

06 const QByteArray &format) const;

07 QImageIOHandler *create(QIODevice *device,

08 const QByteArray &format) const;

09 };

Функция keys() возвращает список форматов изображений, которые поддерживает подключаемый модуль. Можно считать, что параметр format функций capabilities() и create() имеет значение из этого списка.

01 QStringList CursorPlugin::keys() const

02 {

03 return QStringList() << "cur";

04 }

Наш подключаемый модуль поддерживает один формат изображений, поэтому возвращается список, содержащий только одно название. В идеале это название должно совпадать с расширением файла, используемым данным форматом. Если форматы имеют несколько расширений (например, .jpg и .jpeg для JPEG), мы можем возвращать список с несколькими элементами, относящимися к одному формату, — по одному элементу на каждое расширение.

01 QImageIOPlugin::Capabilities

02 CursorPlugin::capabilities(QIODevice *device,

03 const QByteArray &format) const

04 {

05 if (format == "cur")

06 return CanRead;

07 if (format.isEmpty()) {

08 CursorHandler handler;

09 handler.setDevice(device);

10 if (handler.canRead())

11 return CanRead;

12 }

13 return 0;

14 }

Функция capabilities() возвращает объект, который показывает, что может делать с данным форматом изображений обработчик изображений. Существует три возможных действия (CanRead, CanWrite и CanReadIncremental), а возвращаемое значение объединяет допустимые варианты порязрадной логической операцией ИЛИ.

Если формат «cur», наша реализация возвращает CanRead. Если формат не задан, мы создаем обработчик курсора и проверяем его способность чтения данных с заданного устройства. Функция canRead() только просматривает данные и проверяет возможность распознавания файла, не изменяя указатель файла. Возвращение 0 означает, что данный обработчик не может ни считывать, ни записывать файл.

01 QImageIOHandler *CursorPlugin::create(QIODevice *device,

02 const QByteArray &format) const

03 {

04 CursorHandler *handler = new CursorHandler;