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

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

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

В языке Smalltalk получил популярность гибкий подход к визуальному отображению больших наборов данных: модель—представление—контроллер (model—view—controller — MVC). В подходе MVC модель представляет набор данных и отвечает за обеспечение отображаемых данных и за запись всех изменений в источник данных. Каждый тип набора данных имеет свою собственную модель, однако предоставляемый моделью программный интерфейс отображения элементов одинаков для наборов данных любого типа. Представление отвечает за то, как данные отображаются для пользователя. При использовании любого большого набора данных только ограниченная область данных будет видима в любой момент времени, поэтому только эти данные будут запрашиваться представлением. Контроллер — это посредник между пользователем и представлением; он преобразует действия пользователя в запросы по просмотру или редактированию данных, которые представление по мере необходимости передает в модель.

Рис. 10.1. Архитектура модель/представление в Qt.

В Qt используется вдохновленная подходом MVC архитектура модель/представление. Здесь модель имеет такие же функции, как и в классическом методе MVC. Но вместо контроллера в Qt используется немного другое понятие: делегат (delegate). Делегат обеспечивает более тонкое управление воспроизведением и редактированием элементов. Для каждого типа представления в Qt предусмотрен делегат по умолчанию. Для большинства приложений вполне достаточно пользоваться таким делегатом, поэтому обычно нам не приходится заботиться о нем.

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

Во многих случаях пользователю необходимо работать только с относительно небольшим количеством элементов. В такой ситуации, как правило, мы можем использовать удобные классы Qt по отображению элементов (QListWidget, QTableWidget и QTreeWidget), непосредственно заполняя все элементы значениями. Эти классы работают подобно классам отображения элементов в предыдущих версиях Qt. Они хранят свои данные в «элементах» (например, QTableWidget содержит элементы QTableWidgetltem). При реализации этих удобных классов используются пользовательские модели, обеспечивающие появление требуемых элементов в представлениях.

Рис. 10.2. Одна модель может обслуживать несколько представлений.

При использовании больших наборов данных часто оказывается недопустимым дублирование данных. В этих случаях мы можем применять классы Qt по отображению элементов (QListView, QTableView и QTreeView) в сочетании с моделью данных, которой может быть как пользовательская модель, так и одна из заранее определенных в Qt моделей. Например, если набор данных хранится в базе данных, мы можем использовать QTableView в сочетании с QSqlTableModel.

Удобные Qt—подклассы отображения элементов обычно использовать проще, чем определять пользовательскую модель, и они особенно удобны, когда разделение модели и представления нам не дает преимущества. Мы использовали этот подход в главе 4, когда создавали подклассы QTableWidget и QTableWidgetItem для реализации функциональности электронной таблицы.

В данном разделе мы покажем, как можно применять удобные классы отображения элементов для вывода на экран элементов. В первом примере приводится используемый только для чтения виджет QListWidget, во втором примере — редактируемый QTableWidget и в третьем примере — используемый только для чтения QTreeWidget.

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

Сначала покажем фрагмент заголовочного файла диалогового окна:

01 class FlowChartSymbolPicker : public QDialog {

02 Q_OBJECT

03 public:

04 FlowChartSymbolPicker(const QMap &symbolMap,

05 QWidget *parent = 0);

06 int selectedId() const { return id; }

07 void done(int result);

08 …

09 }

Рис. 10.3. Приложение Выбор символа блок—схемы (Flowchart Symbol Picker).

При создании диалогового окна мы должны передать его конструктору ассоциативный массив QMap, и после выполнения конструктора мы можем получить идентификатор выбранного элемента (или —1, если пользователь ничего не выбрал), вызывая selectedId().

01 FlowChartSymbolPicker::FlowChartSymbolPicker(

02 const QMap &symbolMap, QWidget *parent)