[Следующая: Классы-контейнеры Tulip] Что нового в Qt 4
|
| Библиотека | Описание |
|---|---|
| QtCore | Ядро функциональности, не касающейся ГПИ (графического пользовательского интерфейса) |
| QtGui | Ядро функциональности ГПИ |
| QtNetwork | Модуль работы с сетью |
| QtOpenGL | Модуль OpenGL |
| QtSql | Модуль SQL |
| QtSvg | Классы рендеринга SVG |
| QtXml | Модуль XML |
| Qt3Support | Слой поддержки Qt 3 |
| QAxContainer | Расширение клиента ActiveQt |
| QAxServer | Расширение сервера ActiveQt |
| QtAssistant | Классы для запуска Qt Assistant |
| QtDesigner | Классы для расширения и встраивания Qt Designer |
| QtUiTools | Классы для динамической генерации графического пользовательского интерфейса |
| QtTest | Классы инструментов для тестирования модулей |
QtCore содержит инструментальные классы, такие как QString, QList и QFile, также как и классы ядра, такие как QObject и QTimer. Класс QApplication был подвергнут рефакторингу, так что теперь он может быть использован и в неграфических (non-GUI) приложениях. Он разделен на QCoreApplication (в модуле QtCore) и QApplication (в модуле QtGui).
Это разделение делает возможным разработку серверных приложений с использованием Qt без компоновки с любым ненужным кодом, относящимся к ГПИ, и без необходимости присутствия на целевой машине системных библиотек, связанных с ГПИ (например, Xlib на X11, Carbon на Mac OS X).
Если вы используете qmake для формирования make-файлов, qmake по умолчанию будет компоновать ваши приложения вместе с QtCore и QtGui. Чтобы удалить зависимость от QtGui, добавьте строку
QT -= gui
в ваш .pro-файл. Чтобы подключить другие библиотеки, добавьте строку
QT += network opengl sql qt3support
Еще одно изменение в системе сборки - теперь moc понимает директивы препроцессора. qmake автоматически передает установленные для вашего проекта определения (используя "DEFINES +=") в moc, который имеет собственный встроенный препроцессор C++.
Чтобы скомпилировать код, использующий .ui-файлы, вы должны также добавить в ваш .pro-файл такую строку:
CONFIG += uic3
Синтаксис Include
Синтаксис подключения описаний классов Qt стал таким
#include <QClassName>
Например:
#include <QString> #include <QApplication> #include <QSqlTableModel>
Это гарантированно работает с любыми открытыми классами Qt. Старый синтаксис,
#include <qclassname.h>
по-прежнему работает, но мы предлагаем вам перейти на новый синтаксис.
Если вы попробуете подключить заголовочный файл библиотеки, которая не скомпонована с приложением, это приведет к появлению во время компиляции предупреждения (например, "QSqlQuery: No such file or directory"). Решить эту проблему можно либо удалив проблемную директиву include, либо указав недостающую библиотеку в вашем .pro-файле в записи QT (смотрите Систему сборки выше).
Чтобы включить определения всех классов библиотеки просто укажите имя этой библиотеки. Например:
#include <QtCore>
Пространства имен
В Qt 2 был введен класс с именем Qt для квази-глобальных (global-like) констант (например, Qt::yellow). Конструкция namespace C++ не использовалась, поскольку на тот момент не все компиляторы ее понимали.
Начиная с Qt 4 класс Qt стал пространством имен Qt. Если вы хотите получить доступ к константе, являющейся частью пространства имен Qt, добавьте к ее имени префикс Qt:: (например, Qt::yellow), или добавьте директиву
using namespace Qt;
в ваши файлы с исходным кодом, сразу после директив #include. Если вы используете синтаксис using namespace, то вам не нужно добавлять префикс (например, достаточно yellow).
При переносе приложений с Qt 3 вы можете столкнуться в некоторых исходных кодах с проблемами совместимости, связанными с некоторыми из этих символов. Например, в Qt 3 допустимо было написать QWidget::yellow вместо Qt::yellow, поскольку QWidget унаследован от Qt. Это не будет работать в Qt 4; вы должны написать Qt::yellow или добавить директиву "using namespace" и удалить префикс Qt::.
Инструмент портирования qt3to4 автоматизирует это преобразование.
Конструкторы QObject/QWidget
В Qt 4 мы попытались упростить конструкторы подклассов QObject/QWidget. Это делает создание подклассов легче и в то же время помогает сделать библиотеку Qt более эффективной.
Конструкторы больше не принимают параметр "const char *name". Если вы хотите задать имя для QObject, вы должны вызвать QObject::setObjectName() после создания объекта. Имя объекта теперь является QString. Причины данного изменения:
- Использовавший этот прием код выглядит запутанным, например:
QLabel *label1 = new QLabel("Hello", this); QLabel *label2 = new QLabel(this, "Hello");label1 - это метка QLabel, которая отображает текст "Hello"; label2 - это метка QLabel без текста, но с именем объекта "Hello".
- По результатам проведенных нами опросов выяснилось, что большинство пользователей не используют name, хотя они интуитивно следуют соглашению Qt и предоставляют "const char *name" в своих конструкторах подклассов. Например:
MyWidget::MyWidget(QWidget *parent, const char *name) : QWidget(parent, name) { ... } - Параметр name появился в Qt начиная с версии 1 и он всегда был документирован так: "Он не очень полезен в текущей версии Qt, но он станет значительно более важным в будущем." Десять лет спустя это обещание по-прежнему не выполнено.
Тип данных QWidget'а - WFlags - был разделен на две части: Qt::WindowFlags устанавливает низкоуровневые флаги окна (тип окна и стиль рамки), в то время как Qt::WidgetAttribute задает различные высокоуровневые атрибуты виджета (например, WA_StaticContents). Атрибуты виджета можно установить в любое время, используя QWidget::setAttribute(); низкоуровневые флаги окна можно передать конструктору QWidget или установить позднее, используя QWidget::setParent(). Как результат, конструкторам большинства подклассов QWidget нет необходимости предоставлять параметр WFlags.
Параметр parent во всех классах QObject в Qt по умолчанию равен указателю на 0 (0 pointer), как это было сделано в Qt 1. Это позволяет использовать стиль программирования, когда виджеты создаются без родителей и затем вставлять их в компоновку, где компоновщик автоматически перепривяжет им родителя.
Динамическое приведение
Qt 4 предоставляет функцию qobject_cast<>(), которая выполняет динамическое приведение основанное на мета-информации, генерируемой moc для подклассов QObject. В отличие от стандартной конструкции C++ dynamic_cast<>(), qobject_cast<>() работает даже когда RTTI отключен, и он корректно работает через границы DLL.
Вот стиль Qt 3 приведения типа к подтипу:
// УСТАРЕЛО
if (obj->inherits("QPushButton")) {
QPushButton *pushButton = (QPushButton *)obj;
...
}
Стиль Qt 4 чище и безопаснее, поскольку опечатки всегда будут приводить к ошибкам компилятора:
QPushButton *pushButton = qobject_cast<QPushButton *>(obj);
if (pushButton) {
...
}
QPointer<T>
Класс QPointer<T> предоставляет указатель на тип T (где T унаследован от QObject), который автоматически устанавливается равным 0, когда объект, на который он ссылается, разрушается. Безопасные указатели полезны всякий раз, когда вы хотите сохранить указатель на объект, которым не владеете.
Пример:
QLabel *label = new QLabel;
QPointer<QLabel> safeLabel = label;
safeLabel->setText("Hello world!");
delete label;
// safeLabel теперь равен 0, поскольку label - провисший (dangling) указатель
Класс QPointer<T> примерно соответствует старому классу QGuardedPtr<T>, за исключением того, что он теперь реализован в более легковесной манере, чем до этого. Затраты на один объект QPointer<T> сейчас приблизительно такие же, как и на соединение сигнал-слот.
События рисования
Qt 4 поддерживает двойную буферизацию прозрачности (double buffering transparently) на всех платформах. Эта возможность может быть отключена на уровне отдельного виджета с помощью вызова QWidget::setAttribute(Qt::WA_PaintOnScreen).
Результатом этого является то, что все рисование теперь должно выполняться из функции paintEvent(). Это требуется также для HIView API на Mac OS X. На практике, это редкая проблема, поэтому вы можете вызывать update() в любом месте кода для создания события рисования, с областью для обновления в качестве аргумента.
Чтобы помочь переносу, QWidget поддерживает атрибут Qt::WA_PaintOutsidePaintEvent, который может быть установлен, чтобы сделать возможным рисование вне функции paintEvent() в Windows и X11.
Слой поддержки Qt 3
Приложения, основанные на Qt 3, можно компоновать вместе с предоставляемой в Qt 4 библиотекой расширения - Qt3Support. Это предоставляет большую совместимость, чем до этого, не увеличивая размер Qt.
- Классы, которые были заменены другими классами с такими же именами, например, QListView, и классы, которых больше нет в Qt 4, доступны с указанием цифры 3 в их именах (например, Q3ListView, Q3Accel).
- Остальные классы предоставляют функции совместимости. Многие из них реализованы как встроенный (inline) код, поэтому они не увеличивают размеры библиотеки Qt.
Чтобы включить поддержку классов и функций Qt 3, добавьте строку
QT += qt3support
в ваш .pro-файл.
В Visual C++ 7 и GCC 3.2+ использование функций совместимости часто вызывает предупреждение компилятора (например, "'find' is deprecated"). Если вы хотите отключить такие предупреждения, добавьте строку
DEFINES += QT3_SUPPORT
в ваш .pro-файл.
Если вы хотите использовать функции совместимости, но не хотите компоновать приложение вместе с библиотекой Qt3Support, добавьте строку
DEFINES += QT3_SUPPORT_WARNINGS
или
DEFINES += QT3_SUPPORT
в ваш .pro-файл, в зависимости от того, хотите ли вы чтобы при вызове функций совместимости компилятор генерировал предупреждения или нет.
[Следующая: Классы-контейнеры Tulip]
| Copyright © 2008 Nokia | Торговые марки | Qt 4.4.3 |
|
Попытка перевода Qt документации. Если есть желание присоединиться, или если есть замечания или пожелания, то заходите на форум: Перевод Qt документации на русский язык... Люди внесшие вклад в перевод: Команда переводчиков |